Prevent users abusing private ssh keys

Question

It's my experience that users will sprinkle an infrastructure with both public and private keys. While openssh allows for restricting public keys to a specific directory (which discourages them from generating lots of keys) it does NOT provide a similar mechanism for private keys (you can define a default, but not enforce its use).

In an ideal world, I'd want to be able to access hosts without entering a password or passphrase (apart from an initial passphrase for the ssh-agent).

Although the users at my $WORK start their ssh journeys with putty on MS-Windows I am only concerned with preventing them copying a usable private key to a machine which is acting as an ssh server.

These target hosts require the ability to make ssh connections elsewhere so I can't simply block outgoing ssh connections.

Short of implementing a full privileged access solution, is there a way I can let my users authenticate with key pairs but prevent them from copying their private keys (or generating their own keys and deploying either of the private/public keys)?

Answer 1

No, you cannot. Any user who can read a file on the system can copy it, and that's just the way file systems work. There's no difference between a file copy program reading a file and any other program reading a file.

However, if you tell users that they can achieve their goal of logging into other servers by simply forwarding their agent and give them directions on how to do so when setting up the connection, then they will realize that doing that is far simpler and easier than copying the key. That's what we do at my job: we give users directions (for OpenSSH) to set up access to the shell host and direct them to set the directive to forward their agent (since that's required to get access to other machines) and then they do that. Because they don't need to copy the SSH private key to the shell host, they don't.

As mentioned in the comments, if the user uses an SSH key backed by a hardware security key, then that will effectively nullify this problem. It won't prevent them from copying the private key, but without the hardware security key plugged into the remote machine, the private key won't work, so it disincentivizes this behaviour. However, this requires a relatively new version of OpenSSH for this to work and I'm not sure if the Windows version of OpenSSH supports this. Short of that, though, there's no way to prevent this from happening.

Answer 2

I have a feeling that ssh-agent and a technique named "agent forwarding" may be a way you can prevent your users from putting private keys on your ssh (bastion?) hosts. I haven't used this myself, but here's my understanding of how it works:

• An ssh agent runs on the user's home computer while they have an ssh session open, and the agent caches the user's private key. When they ssh to your server, their ssh client asks the agent to answer the challenge for the key, and they log into your server.
• The local ssh config on your server tells ssh clients to tunnel key challenges back through the ssh connection from their home computer to their ssh client (and then to their agent).
• When they ssh from your ssh host to other servers, the key challenges go back to their home computer and are answered by their agent. No need for private keys on your servers.

I saw a reference to a guide at this URL: https://docs.github.com/en/developers/overview/using-ssh-agent-forwarding, but I've only skimmed through it quickly. There's a link there to a guide by Steve Friedl with good details.

This may not be enough to prevent your people from invoking ssh -i symcbean_hates_this_key_file, but perhaps most of them will stop if they have an automatic way to use their key on your ssh server.