Every decade or so the recommendations on best practices change, so I'm curious on the current best practices around SSH keys stored on a device (eg a laptop).

If we believe that the best practice currently is to have a new private key per client device (ie for each laptop, desktop, or phone) that one connects to a server from, then that opens the question in my mind of what are folks doing for passphrases for these keys.

Obviously the ideal would be very strong, unique passphrases per device, but then if one has 4+ devices, this can get fairly challenging to remember.

Do you use passphrases on per-device keys?
Do you re-use the passphrase across keys?
Do you forgo traditional ssh keys stored on the computer in favor of Yubikeys?
Do you have tools to help you manage which keys are on which hosts so you can retire or revoke them as necessary?

#SSH #InfoSec

I'm going to give some unsolicited thoughts on this beyond my own question in hopes someone tells me why I'm wrong.

I think per client-device keys are the right approach. If your laptop is lost or stolen, then this should make it easy to revoke that keypair.

The problem is we don't seem to have good tooling around revocation. If my laptop is stolen, I want to be able to revoke that key quickly and easily. Similarly I want to be able to quickly and easily introduce a new keypair for a new device, eg "I got a new laptop. Let me run this script where I use existing keys to validate the propagation of my new public key"

1/2

#Infosec

Where I get a little controversial is that I believe SSH key passphrases are almost an anti-pattern. Their function is to decrypt the actual ssh key. Belt and suspenders is great. Having a second factor needed to use your SSH key is a nice idea if your laptop isn't properly screen/keyboard locked, but if it is, then the passphrase doesn't add any additional security. Reusing it shouldn't even be a problem *if you can revoke keys*.

Keys stored on physical hardware (ie Yubikeys) is better, and you can still get that second factor by using a PIN, but they're less convenient in other ways. You must always have two hardware devices in case one is lost or destroyed, and even then you can't just magically plug them into a new computer- you have to set up your SSH client to use the key.

Maybe someone will tell me you should use your phone as a Smartcard?

The key management is the real problem. We don't have good key management tools to help us manage these keys

2/2

#Infosec

@serge and what do you think about storing the key in the password manager? Both Bitwarden and keepassxc have implemented ssh-agent
@naphtali
That effectively becomes a single key shared by all machines that can access the password manager (whether you control those machines or not).
@serge

@naphtali

The real issue here is traceability and revocability.

Instead of SSH keys, let's imagine we just had bearer tokens.

We'd want to separate out the tokens where possible.

The same here.

You could use the password manager to keep track of the passphrase though.

@viq

@serge
Extending on "phone as a smart card", there's solutions like Teleport and I think others, that will be in the middle of the ssh connection, and facilitate it for you only if you pass MFA authentication.
@serge ha, that sounds like you're describing SSH CA ;)

@viq

I don't quite get what this gives me in terms of the challenges I mentioned, specially distribution and revocation.

Are you saying we tell the clients "Trust any key by this CA?"

If I do that, how do I revoke a key?

@serge with CA your key also needs a certificate signed by CA. That certificate can be valid for say 15 minutes. Without key certificate doesn't give you anything. Without certificate key doesn't give you anything.

@viq

Ah! So it's as much a service as a signing authority. Can you point me to a resource on this?

@serge it's somewhat like with TLS - you can use openssl to generate CA key and cert and then sign certificates with it, or you can use one of a myriad of scripts and services that make it easier in various ways.
I know Hashicorp Vault does it, I think Teleport does, smallstep CA has something there as well. There most likely are others.
@serge From a very quick search, https://liw.fi/sshca/ seems to have some basic info and links.
SSH CA host and user certificates

@viq

Thanks! I'm a little unclear on this stuff so will read! I appreciate your help!

@serge feel free to ask :)
@serge if you can, there's now SSH CA, giving you certificates with limited life, and possibly embedded information which hosts it can connect to. This changes from "distribute key(s) to machine(s)" to "get your key signed" - which means you need to secure your CA signing key that much better.
*Personally* I think re-using passphrases across keys is not as bad, because if something is in position to get your key, it probably can sniff your password/phrase too.

@viq

I'll give this a look, but maybe you can help me understand this.

Let's imagine I'm using my ssh private key stored on a Yubikey and then someone steals my Yubikey.

I want to be able to issue some kind of command from another client that says "Revoke access (ie delete the public key) for the Yubikey." - The problem is two fold:

1. I need a simple way to track where the Yubikey public keys are. I need a list of hosts.
2. I need a simple command to revoke the key, ie remove the entry from ~/.ssh/authorized_keys
3. I'd like a way to ensure that if someone tried #2 that they'd need some secondary validation otherwise the attacker that steals my Yubikey also gains the ability to lock me out too easily.

@serge (1) and (2) sound like configuration management, or otherwise central key management (e.g. by hacking something with AuthorizedKeysCommand).

(3) sounds somewhat like multiple approvals (or signatures) or MFA for a code change.

@serge If you're doing per-device SSH keys, https://github.com/Foxboron/ssh-tpm-agent seems like a good idea.
GitHub - Foxboron/ssh-tpm-agent: :computer: ssh-agent for TPMs

:computer: :key: ssh-agent for TPMs. Contribute to Foxboron/ssh-tpm-agent development by creating an account on GitHub.

GitHub

@bodil

Interesting!

So then if I replace my laptop's motherboard, I need to generate new keys for it because now it's a new device.

That's okay (and maybe even good!).

Still have the challenges in key management, but this is a nice thing to check out! Thanks!