Item — HN Reader

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.

1 comments

There is a slight risk - if someone has your public key they can setup a MITM server and pretend to be the one you’re expecting - and watch what you’re doing, or redirect test to production or similar.

It’s really very minor and ssh itself should warn that the servers fingerprint changed.

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.