Question

I have a machine for a developer and I set up SSH key to allow them to access a server. The public and private keys in .ssh are obviously visible to the person.

Is there a way to protect these keys? If I do not want the possibility of those keys being copied over to another server, can I do anything?

The ssh-agent by default runs under the logged in user, so I probably cannot take away the user’s access rights to the ~/.ssh folder.

Thanks,
Tabrez

Answer 1

You wish to allow the developer to USE the key but not COPY it.

To do that, you could store the key on a server that the developer doesn’t have full access to. One way to implement this is like this:

• Developer logs in to a special “key custodian” server where the key is stored. They could log in to this server using a different SSH key (not the one you are trying to control), a password, some form of 2-factor authentication, or anything else you choose which SSH supports.
• The developer’s account on this server is configured with a forced command or a restricted shell which continues the process by carrying out these actions:
  • starts a new SSH agent (running on the key custodian server, of course)
  • loads the controlled key into that agent
  • launches an ssh connection to some other server with agent forwarding enabled.
• The developer logs in to this second server (on which they must have an account). This second server is perhaps a general purpose server you already operate.

The developer can now log in to other places from this second server by making use of the agent running on the key custodian server, but they never got access to any shell or opportunity to examine/copy files on the key custodian server.

This solution suffers from the fact that all of the developer’s sessions are channeled through the key custodian server and also through the second shared server. This may be a disadvantage if the key custodian server is remote. It is also difficult and unintuitive for the developer to use this to transfer files (SCP or SFTP) back to their local machine.

An alternate solution would involve writing software to create a stub SSH agent server locally on the developer’s machine that forwards SSH agent requests over a dedicated connection to the a real agent on the key custodian server. With a little work you can set up the dedicated connection to the key custodian server (itself an SSH connection, I recommend) automatically launch a simple subshell on the developer’s machine that has the stub ssh agent’s socket in its environment so they can “just use it”, and this solution can be really quite functional and user friendly. I have done this myself, but it’s way beyond the scope of a Stackoverflow answer.