I’d like to share an idea I’ve been having for quite a while and that AWS implemented recently. I’d like to gather some feedback on the matter.
sshd allows an admin to specify the AuthorizedKeysCommand. This can point to a script that returns all ssh public keys that should be allowed to login to a server. We’ve been using this with a separate application to allow our users to store the ssh keys that they want to use to login to servers.
Foreman allows users to store ssh keys for their user. We could easily provide an API endpoint that lists the ssh keys for a user so that these keys can be used for logging in to a server.
We could go even further by providing an option for hammer to upload the user’s public key to Foreman when it’s not present there and then executing ssh.
Opening an ssh session to a server could be as simple as:
hammer ssh my-server-01.example.com
This mechanism could also be used by rex. We could provide an rpm that needs to be installed on the server that sets up a foreman-user-user and sets up sshd to ask Foreman for authorized ssh keys.
Foreman can then return the ssh key that rex needs to login to the machine.
AWS also allows the public ssh keys to expire, so you can get temporary access to a server by issuing a aws cli command. We could have a button in the UI labeled Allow temporary login to this host and then a modal shows you the ssh command required to login.
AWS also has a wrapper for ssh available.
As a user that sounds awesome! We would need to be careful to ensure that the request happens via foreman-proxy where applicable, a lot of Foreman installs have security zones that are served by that foreman-proxy and have no direct access to Foreman.
One concern I have is Foreman traditionally has been all about systems management and provisioning, does this move Foreman more into the authentication and authorization space? I think we’d need to be careful as for most use cases, there are projects purely dedicated to this that can generally do a better job to solve the problem than we could.
It doesn’t hurt to expose this via an API. Github also does this (https://github.com/$USERNAME.keys).
How do you see the authorization part? Which user is allowed to connect to which server.
This is a good feature in itself.
We have an ancient plugin for this:
This means you want multiple users to share a single login? You then probably also want do auditing to figure out which Foreman user logged in using which key.
I think I’d handle this via separate permission on the host object, similar to power_hosts there would be a permission login_hosts. I’m just not sure how to allow the login just as a specific user.
I didn’t know about that one, but “my” command would just open an interactive ssh session to the host.
An internal alarm went off when I first thought about this, but all the cloud service providers to it this way. As you said, auditing is key here. You could argue that when the auditing is done in Foreman it’s more secure than done locally on the host (as it’s easier to manipulate audit records on the host).
Just wanted to let you know there’s prior work that maybe could be revived
Could we build this in a modular way. We provide the API as a core supported feature. Then we have a generic helper script and a reference implementation. If user have other needs they can use the generic helper script or even write something from scratch.
Well, the way I imaging it is that you have a table in the database that has these fields:
host_id | ssh_key_id | username | valid_from | valid_to
A host would then only get the ssh keys that are valid for a specific os user. The user must exist on the system, though. We do have a username available for hosts that were built from an image. We don’t have this for pxe built hosts, though. But we could provide a snippet that creates the user similar to rex.
We have the concept of host owner. Would they be copied into this table or would they be implicitly part of it? Does it make sense to generalize the whole owner concept?
We do. They could be allowed access to a host automatically (we actually do it like this at work), but they don’t tell me which users exist on a system (unless puppet/kickstart/ansible creates them).
We should explore this more, what do you have in mind?
