birmingham.io

One ssh key to rule them all?

#1

What’s the general advice when it comes to ssh keys across multiple machines?

Thus far, any time I’ve needed an ssh key on a new machine, I’ve simply gone to the GitHub help pages and followed the instructions for creating a new one.

The outcome of this is a bunch of different keys across a bunch of different machines, with their public key siblings littering the multiple places they’re required (such as GitHub, authorized_keys files, etc…).

Its this the right approach, or should I instead create a single key for use across the different machines?

Additionally, especially if I’m using a single key for everything, should I put a pass phrase on it, and what can I do to avoid having to type it in for each git push I do? And what is the best way of safely backing up the key?

#2

(On work mobile, apologies for brevity)

Multiple SSH keys are okay, but personally I’ve been using just the one for everything for the last 12 years or so!

Always have a passphrase on SSH keys, otherwise they’re potentially less secure than using a password.

Google for “SSH agent” to avoid entering the passphrase every time. Don’t use the agent on a machine that you don’t trust (viz. any machine that you’re not the sole user of). Agent forwarding can be useful, but once again, not through machines you don’t entirely trust.

KEEP YOUR PRIVATE KEY(S) SAFE! A passphrase should just be considered a last resort, a method to delay someone abusing a stolen private key long enough for you to make sure it’s removed from use. I keep my private key on an encrypted keydrive, which is only plugged in and mounted when I need it, so there’s very little opportunity for it to be stolen. A printed copy of the key is being kept safe for me, so if the keydrive was to fail I could recreate the private key file.

1 Like
#3

Just so I understand this… you plug in your usb stick every time you need to ssh anywhere? Or does ssh-agent keep the actual key in memory too, so you only need to plug it on on every boot?

#4

The agent keeps it in memory, so you only need to add it to the agent once. There are security issues about that, hence only using the agent on computers you trust.

Depending on how often I think I’m going to need the key, I may not bother with the agent, in the interest of security. No point having even the potential for key theft if I’m only going to need it once every couple of hours. :slight_smile:

1 Like
#5

It’s a public key, so using the same one is fine and dandy. It’s of no use to anyone else.

I would, and do, keep keys strictly per machine. It had never occurred to me to share them. Seems like more work and less security.

I only use passwords on keys for things that need a higher degree of security. I presume that your machines require a login, otherwise all bets are off.

1 Like
#6

Semi-related, what do you all think about keybase.io ?

1 Like
#7

I know I have an account, and have linked it to my various online identities - beyond this, I don’t really understand what it is.

#8

Having a key that logs you straight in pushes security back to your computer. Therefore you computer should have a strong security (e.g. long password,kept in locked room, security case, BIOS password, encrypted drive etc.) otherwise it’s the weak point into your server or repo. Also you might want to check the private key doesn’t get backed up.

One risk is that your private key could be copied from you computer and you wouldn’t know. If you know where you will be using a key from, you can restrict a key to particular IP addresses: https://blog.tinned-software.net/restrict-ssh-logins-using-ssh-keys-to-a-particular-ip-address/ which limits it’s usefulness if copied.

To your original question, I’d use one key per machine and use a password on them (with ssh-agent/ssh-add). I’d update these keys periodically to make sure you are using the latest key algorithms such as ed25519 rather than older RSA ones.

1 Like
#9

@rythie, as you’d expect given the topic, makes a bunch of great points. Basically, the level of security you give to your keys should be proportional to the impact of a break-in. If you don’t know, follow Richard’s advice. All of it.

Now, since, hijacking threads here isn’t completely verboten, I read this today which, while somewhat connected to the Apple/FBI fracas, is a great exposition of the current issues we have in deployed systems wrt keys and single points of failure. So, while you can do everything in your power to protect your systems, there are still gaping holes that could be exploited, and you might never know.

As the Apple case has highlighted, there is still work to be done, and I’m grateful for Tim Cook for holding the line on this and highlighting issues that have long been ignored by the software community.

#10

Erm. System updates are not downloaded and installed while the phone is locked, though. Installing the update needs user approval, which can’t be given while the phone is locked, and therefore that can’t be used to bypass such a lock.

#11

I don’t think that’s correct. As I understand the San Bernardino case

  1. The shooter’s iPhone is locked/encrypted with a PIN.
  2. The PIN check & timeouts are done by iOS.
  3. The FBI have asked/required Apple to make/sign an update that negates (2). Then apply it while the phone is locked.
  4. Apple contest the request, on grounds of proliferation risk. They say it shouldn’t be done.
  5. Apple (to my knowledge) don’t say it can’t be done.

I’m basing this on Decrypting an iPhone for the FBI by Schneier. Specifically

It turns out that all iPhones have this security vulnerability: all can have their software updated without knowing the password. The updated code has to be signed with Apple’s key, of course, which adds a major difficulty to the attack.

No doubt Apple are making damn sure it will be fixed in future iPhones and/or iOS versions.

#12

Ooh! Interesting. I wonder how that works then? If I had to guess I’d say this is because the software update stuff is tied in with the app updater, which needs to be able to remove malicious apps without user approval, and someone said, hey, let’s allow that for OS updates too, because some day we might need it. Thank you for the correction!

#13

I don’t know. Speculating: You may have been partially right e.g. Installing iOS updates over the air needs user approval. Maybe installing the requested FBiOS update would require direct hardware access e.g. DFU recovery mode, or something even lower level like JTAG.

#14

I believe that it’s generally recommended that, ideally, a private key should never leave the machine it is generated on, making it harder to leak, and less painful to revoke if it does. This implies using a different keypair per client. Notice that your SSH key generator encourages this pattern by putting the hostname in the comment field.

I’d go further, and suggest using a different keypair per client/service pair. My ~/.ssh/config looks something like:

Host    bitbucket.org
        IdentityFile    ~/.ssh/id_rsa_bitbucket

Host    github.com
        IdentityFile    ~/.ssh/id_ed25519_github
...

This means I can perform key rollover one service at a time, meaning I’m much more likely to actually do it (SSH expects you do your key management almost entirely yourself, and I believe this is a significant security weakness. X.509 certificates expire regularly, but SSH private keys do not).

What OS are you using? Fedora Workstation (Gnome 3) takes care of this for you, and I’d expect other Linux desktops to do the same. On Windows, use the PuTTY agent, Pageant. If you need to do this from the Unix command line, then:

eval `ssh-agent -t 28800`
ssh-add

If your SSH client is not the local machine, consider running the agent locally and using the ForwardAgent option (or similar for your client).

#15

If this seems like overkill to you, consider the case of a system account that chugs away running a release system or monitoring system or something like that. Will you remember to change the private key every time a colleague leaves the company? Tying a key down to a particular client hostname make it much harder to exploit.

Proudly sponsored by Bytemark