IMO, an ssh public key is not a password and shouldn't need to be treated as such. The public key portion is public. When you generate an ssh key pair, its like making both a lock and a key, then giving the lock to a server and saying "use this lock on my door". This lock can only be opened with your key, and can only be picked when your encryption algo of choice (ed25519 for me) gets obsoleted.

Sprinkle in a passphrase and now you have good MFA: something you know (the passphrase) and something you have (the private key).

Personally, I don't see a problem with re-using a key pair across multiple servers. I like to do one key pair per client device. This lets you manage server access per device. You can single out and remove just the key from a lost or compromised device without affecting the others.

OTOH, one key pair for all devices fails at this, plus you also have to worry about protecting the private key during distribution to multiple devices. A private key is best left on the client that generated it. Of course, once you hit enterprise, all this goes out the window. As they will probably have systems in place and compliance rules to follow.

I use a handful of keys. Thing is, your secret is never shared with the server. Just the public key bits. Passwords are stored (hashed) on the services. Totally different threat models. With your public key the biggest risk is someone tracking what you are up to if they compromised multiple services/servers you use.

Not really. Do you think the ssh client machine is easier to secure than the ssh server? (It isn't.)

It objectively is since I never transmit the private key bits to the server. Passwords usually require the whole secret be blasted about the Internet (albeit encapsulated in TLS, usually).

Hint, the server won't be the hostile party stealing your keys here. Neither will be your ISP.

Why be obtuse? Are you talking about compromising the client machine? In which case, you’ve already lost all your keys, and you’re relying on their passphrases being set.

I'm saying private keys are not more secure by default. If your development machine is compromised (which is really easy to do, BTW) they'll steal your keys and probably will have root on your servers and access to your github accounts.

Stealing passwords is much harder in comparison.

As an attacker, maybe true depending on your target. As a user I have had my passwords compromised many times. My SSH keys never have and I don’t know of any prominent evidence this happens much at all. I have been doing reversing, netsec, and appsec for 15 years now, so my memory goes back a ways. Plus, for example, my main system a Linux desktop. You can and should password protect your SSH keys, which further eliminates a number of key compromise scenarios.

I'd love to, but I keep keys on my Yubikey - which only supports 1 auth key. Even using U2F for SSH keeps the same restrictions. And using a different yubikey for various services isn't ideal either.

I have considered keeping encrypted keys in my password manager per-service, and decrypt+add them to my SSH agent when they're used to offer almost the same guarantees.

> Even using U2F for SSH keeps the same restrictions

Er, what? The SSH keys are being generated the same way keys for web sites are under FIDO, which is to say they're random - your physical device has no idea how many keys you have, it couldn't mandate that there's only one key if it tried. It only knows how to tell if these are keys it made (otherwise presumably a different FIDO authenticator made them) and if so use them to sign you in once somebody touches the contact.

That makes sense. I need to try U2F for SSH more thoroughly I guess.

I treat them as identities. Each identity gets it's own key and each identity may have access to numerous accounts. It's bad opsec to share keys between identities.

I do one per machine, usually. That way if the machine is lost, it’s easy to revoke the keys.

A mix. Typically I'll use one key per machine and add those keys in the places they need to be. This is good as you're reasonably well protected if that machine gets lost or stolen. The nature of public key cryptography means there's no risk associated with handing over your public key to many different places.

However sometimes it's practical to use the same (private) key in multiple places. I do this for access to low-risk stuff like ssh access to my raspberry pis. I wouldn't ever move a private key around for anything remotely dangerous though.

Public keys are identity, so, a remote server can (and a famous one does: https://github.com/FiloSottile/whoami.filippo.io) tell you if e.g. you connect to it while offering to prove your identity with keys github knows about, because github provides a list of those keys. That's the extent of the interesting consequences of knowing your public keys.

You can't realistically MITM SSH because you will have a session mismatch. You may be able to convince a naive visitor (coming to some.machine.example with no prior contact, and not using either certificates, or secure DNS protected credentials to verify the identity of the machine) that you're some.machine.example but you can't successfully splice this to a connection with the real some.machine.example if they use public key login.

The reason is, during connection you persuaded the client that you are some.machine.example, but to do that you needed to make up keys since you don't know the real keys for some.machine.example. However the real some.machine.example does know its keys and they're different. The credentials the victim client gives you only work for your keys, they won't work for the real some.machine.example keys, and the client has no reason to present you with credentials that would work for the real some.machine.example, so you can't authenticate to the real some.machine.example as them.

Well, there is a non-negligible chance that the client has agent forwarding turned on, in which case the MiTM box could splice the connection to the real some.machine.example.

This shouldn't be possible for any server you've previously connected to. Each machine should have a unique "host key" and OpenSSH prints a very loud message and refuses to connect if it ever changes.

Well they don't need your public key as well to do that kind of MITM so not sure thats really relevant.

I'm reusing the same key per machine - but it's mostly just due to convenience and laziness.

I use use a security key to login to personal ssh services, which uses a single key. The key requires a physical touch in order to log in to devices though.

If something more robust is needed, ssh certs and principals can be used.

Some use Pam modules to require 2nd factor too.

default SSH key is the same one for GitHub (since they leak users’ pubkeys anyway), and private repos (eg. hosted GitLab instances) get their own keys. not really sure if it buys any privacy though.

Uh, "leak" is a strong word. They are PUBLIC keys, to think of them as anything other than public is your mental block. If you share your public key with someone, expect them to publish it publicly.

Try thinking of SSH pub keys as identities or usernames and you are more on the right track.

I tend to have 1 pubkey per thing I care about, so 1 per github account, 1 per gitlab account, 1 for work, etc.