Stop sharing keys!
Necessary background
When considering whether a given person should have access to a testing or production machine, we make a determination about:
If that person should have access at all
What rights that person should have on that machine
From that, we apply some changes to that machine:
Set up an account on that machine (something like
ahowden)Set up access control mechanisms to limit what that user can do on that machine
Set up 1 or more keys to function as mechanisms to allow one to prove who they are to gain access to that machine
However, sometimes those assumptions can break down.
When you’re you. And also the other you. And the third who is not you at all.
The problem lies when some of the guarantees that are normally provided by using SSH keys are broken. In my mind, an SSH key should be allocated with the unique combination of:
A single user on a single computer
Given this model, we can assign a level of trust to the combination of you and your computer. We can say:
If we find you doing nefarious things, we can remove all of your keys
If we find your computer doing nefarious things (much more common), we remove that single key
However, this breaks down if keys are shared. There’s a couple of ways this happens:
Sharing between machines
Most commonly, when keys are shared between machines we’re no longer able to make an assertion or revoke access to a particular machine. That means when a given machine is “poisoned” (it gets some sort of malware on it) we have to consider all connections from that user poisoned.
The user must reissue and re copy that key back onto all machines. Then, if it happens again, rest and repeat.
It additionally means we can never really “retire" machine access. If we don’t know which machine is responsible for which key, we don’t know which key to revoke when machines are decommissioned due to EOL or hardware refresh. We rely on the machine owner to safely destroy this key material; traditionally a difficult task indeed.
Sharing between people
Though I see far less of this now than I used to, I still occasionally see people share keys. This violates our ability to determine who accessed a machine, as well as our ability to revoke access to a single person. As before, when one person is poisoned we have to consider all people who have access to that key poisoned.
For organisations that are unprepared for this, this can mean weeks of pain.
Increased risk of exposure
Regardless of how keys are shared, as keys are shared across each trust boundary (person or machine) the risk of that key gets exposed increases by the number of users who have access to this key.
Additionally, sharing tends to happen at an exponential rate; 1 to 2, 2 to 4 and so on until the guarantee of identity is essentially meaningless.
Some advice to keep things simple
Simple identities
In may cases it’s super simple to generate a keypair per user. Simply run:
ssh-keygenHit enter a few times, and you have a new key (only do this once, otherwise you’ll overwrite your new shiny key!) Once you have your key, leave it at just that one key. Don’t have different keys per machine, or connection, or other stuff — simply one key per identity; that is, you + your machine
Foolproof identities
For the more technically sophisticated, GPG smart cards (popularised by products such as Yubikey) can be used as SSH identities. One must simply configure the GPG agent to function as an SSH agent. As a bonus, users can look up your public key ahead of time in keyservers and the like.
For some detailed notes on this topic check the following guides.
I count a yubikey as a single hardware device no matter which computer it’s plugged into, as you cannot read the key back off the device. If the computer is compromised, the device is still fine .
In Summary
SSH is an extremely powerful tool, and fundamental to the administration of Linux systems. However, handling the authentication aspect needs to be taken seriously, and we need to be sure it’s easy to tell who we are, and what we’re trusted with.