This was quite interesting. I didn’t though about implementing the reverse of whoami. :)
However, there is another approachable solution even today with the current ssh implementation: use a unique key for each server (or user-server combination).
For example here is how I’ve configured my ~/.ssh/config:
Match all
IdentityFile ~/.ssh/keys/hosts/%k--%r
IdentityFile ~/.ssh/keys/hosts/%k
IdentitiesOnly yes
The essential bit is IdentitiesOnly yes that makes sure the ssh client won’t try to use any other key than the ones explicitly given (either as -i or the sum of IdentityFile in the matching blocks inside ~/.ssh/config.)
The %k means whatever ssh looks for in ~/.ssh/known_hosts, i.e. the HostKeyAlias or the remote host name.
Then, inside my ~/.ssh/keys/hosts I have symlinks to my public key (yes that works, it makes ssh choose from ssh-agent that particular key), thus I can choose which key is used for which server.
I had this configuration for years now, but not for the reason you’ve found out, but because sshd breaks the connection after a few yeas, and I used to have quite a lot of keys in my ssh-agent.
I wonder if modifying ssh to generate per-server keypairs from a single private key could be a good defense against this. It’d make key management more of a pain in the ass, but maybe it’d be worth it.
I think this sounds worse than it is, assuming you don’t ssh to your servers with your github username.
Case in point, I’m winks on Github and iirc I’ve never ever had an account on a ssh-able machine with that name, so unless you’d be personally targeting me and looking at my github profile, that would be useless.
Incidentally, for some machines where I don’t advertise my name it will be even harder to associate me via my github keys, but I’m not saying it’s impossible. But if root@ works for ssh, it would certainly be easier.
It is not much of a secret that certain metadata happy actors have big ol’ databases for identifying public key reuse – which can come in handy when building a ‘social graph’ of sorts. I’ve personally seen it used tactically on BigCo™ levels.
The current/default keystore in arcan-net/a12 had this and the ‘keypair reuse default’ in ssh as part of the threat model. Since we attempt to consolidate all forms of remote desktop; text-dominant (ssh); segmented (x11) or bad ol’ prematurely composed pixels (vnc) – into one protocol, such detail matter. The constraints are kind of fun to work within, especially when considering live migration and crash/disconnect recovery.
The best I could come up with at the time (some 3 years ago, these things cook very slowly) was to:
Default to sacrifice a roundtrip for CurveCP like ‘ephemeral pK DH exchange’ to force active MitM to actually get the Kpb in use (substantially more expensive than just grepping pcaps).
Default to petnames at user interfaces, not keyfiles and host|ip. The names represents a pair, and you explicitly attach n hosts to it. In naive (filesystem) storage, they are also differentiated per file as every inclusion vuln ever is hit with $HOME/.ssh/id_rsa and friends. In my experience, all the my first python projects out there give out way fewer glob/traversal primitives than inclusion ones.
… and some other things that would make this even more wall of text-y. I go a little more into it in this old release post, but there will be a more approachable writeup one day.
There is another side to the ‘public in public keys might be too public’ coin and that is for service discovery. Take the idea ‘Which of the hosts that my public key may access are available now or tell me when they become available’ (locally or globally). How can this be done zero-knowledge style with low to no amplification (DDoS), not leak the Kpub or make explicit the network relationship between lock and key? I have some ideas and a playing around with prototyping, but would love for more references/papers/DMs on the matter.
Of course SSH has ‘better’ authentication setups and you can do this manually, but the ‘simple default’ must be safer and more private as it will inevitable see large scale use due to ‘simple’ and ‘default’.
This was quite interesting. I didn’t though about implementing the reverse of
whoami. :)However, there is another approachable solution even today with the current
sshimplementation: use a unique key for each server (or user-server combination).For example here is how I’ve configured my
~/.ssh/config:The essential bit is
IdentitiesOnly yesthat makes sure thesshclient won’t try to use any other key than the ones explicitly given (either as-ior the sum ofIdentityFilein the matching blocks inside~/.ssh/config.)The
%kmeans whateversshlooks for in~/.ssh/known_hosts, i.e. theHostKeyAliasor the remote host name.Then, inside my
~/.ssh/keys/hostsI have symlinks to my public key (yes that works, it makessshchoose fromssh-agentthat particular key), thus I can choose which key is used for which server.I had this configuration for years now, but not for the reason you’ve found out, but because
sshdbreaks the connection after a few yeas, and I used to have quite a lot of keys in myssh-agent.Wow, that’s actually a bit spooky.
I wonder if modifying ssh to generate per-server keypairs from a single private key could be a good defense against this. It’d make key management more of a pain in the ass, but maybe it’d be worth it.
I think this sounds worse than it is, assuming you don’t ssh to your servers with your github username.
Case in point, I’m
winkson Github and iirc I’ve never ever had an account on a ssh-able machine with that name, so unless you’d be personally targeting me and looking at my github profile, that would be useless.Incidentally, for some machines where I don’t advertise my name it will be even harder to associate me via my github keys, but I’m not saying it’s impossible. But if
root@works for ssh, it would certainly be easier.That’s a bummer. Can it be disabled?
You can have a github specific key and not use it for other things.
Of course, many ssh implementations will send the key anyways, unless you store it somewhere nonstandard or something.
It is not much of a secret that certain metadata happy actors have big ol’ databases for identifying public key reuse – which can come in handy when building a ‘social graph’ of sorts. I’ve personally seen it used tactically on BigCo™ levels.
The current/default keystore in arcan-net/a12 had this and the ‘keypair reuse default’ in ssh as part of the threat model. Since we attempt to consolidate all forms of remote desktop; text-dominant (ssh); segmented (x11) or bad ol’ prematurely composed pixels (vnc) – into one protocol, such detail matter. The constraints are kind of fun to work within, especially when considering live migration and crash/disconnect recovery.
The best I could come up with at the time (some 3 years ago, these things cook very slowly) was to:
Default to sacrifice a roundtrip for CurveCP like ‘ephemeral pK DH exchange’ to force active MitM to actually get the Kpb in use (substantially more expensive than just grepping pcaps).
Default to petnames at user interfaces, not keyfiles and host|ip. The names represents a pair, and you explicitly attach n hosts to it. In naive (filesystem) storage, they are also differentiated per file as every inclusion vuln ever is hit with $HOME/.ssh/id_rsa and friends. In my experience, all the my first python projects out there give out way fewer glob/traversal primitives than inclusion ones.
… and some other things that would make this even more wall of text-y. I go a little more into it in this old release post, but there will be a more approachable writeup one day.
There is another side to the ‘public in public keys might be too public’ coin and that is for service discovery. Take the idea ‘Which of the hosts that my public key may access are available now or tell me when they become available’ (locally or globally). How can this be done zero-knowledge style with low to no amplification (DDoS), not leak the Kpub or make explicit the network relationship between lock and key? I have some ideas and a playing around with prototyping, but would love for more references/papers/DMs on the matter.
Of course SSH has ‘better’ authentication setups and you can do this manually, but the ‘simple default’ must be safer and more private as it will inevitable see large scale use due to ‘simple’ and ‘default’.