0

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)?

3
  • 2
    Unless you somehow manage to store their keys in the windows certificate store as "not exportable", I don't think this is easily possible. You would have to prevent them from reading the private key, as it's really just copy & paste.
    – Panki
    Commented Jul 19, 2022 at 11:16
  • Hardware key maybe? (yubikey or similar....)
    – K-attila-
    Commented Jul 19, 2022 at 13:27
  • Interesting, but not very convenient when most of my users are using VDI. And do any of these provide direct integration with PuTTy rather than just being a thumb drive?
    – symcbean
    Commented Jul 19, 2022 at 13:33

2 Answers 2

0

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.

1
  • We also tell users to log tickets instead of turning up at our desks. We tell them not to share passwords. We tell them to not deploy code without going through the change process. We tell them not to download random crap from the internet and run it on their PC, nevermind the servers. We tell them to put their code into version control. In most organiations failure to comply with these basic rules would result in a disciplinary process. Here it's BAU.
    – symcbean
    Commented Jul 20, 2022 at 20:00
0

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.

2
  • Already aware of agent forwarding (and ssh tunneling). This does not solve the problem. When your users only have hammers every problem is a nail.
    – symcbean
    Commented Jul 20, 2022 at 19:56
  • True. When I suggested this, I envisioned a cron script that would seek out and report private key files created by users. The script would be part of the enforcement of your "don't create local keys" policy, and agent forwarding would be the workable alternative. But if that won't work, it won't work.
    – Sotto Voce
    Commented Jul 20, 2022 at 20:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .