10 ms·
FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries
by chrisfosterelli 11y ago
FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does)
If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.
In your .ssh/config, something like:
# Ignore SSH keys unless specified in Host subsection
IdentitiesOnly yes
# Send your public key to github only
Host github.com
IdentityFile ~/.ssh/id_rsa
This is also handy if you're security conscious and like to use a different private/public key pair for each host you have an account with!
- ipozgaj 11y agoI do the same thing, plus I maintain a separate public/private key pair for every host where I need the pubkey auth.
- FiloSottile 11y agoExactly! Once I get the keys I just check them against a scraped database of GitHub keys and ask the API for your name. (And if you have agent forwarding active I show you a big WARNING [0].) There's an explanation in the README [1] but the actually interesting stuff is in server.go [2]. Finally I mentioned a few reasons it might not work for you below [3]. [0] http://git.io/vOVYm http://git.io/vOVYm [1] https://github.com/FiloSottile/whosthere https://github.com/FiloSottile/whosthere [2] https://github.com/FiloSottile/whosthere/blob/master/src/ssherver/server.go https://github.com/FiloSottile/whosthere/blob/master/src/ssh... [3] https://news.ycombinator.com/item?id=10005169 https://news.ycombinator.com/item?id=10005169
- songgao 11y agoThis might be more obvious than I thought, but could you explain how you scraped all of GitHub keys throughout the entire user-base?
- rmetzler 11y agoThere is a URL for the keys of a user. And phillipo used the dataset benjojo published a few month ago when he scraped all the keys: https://blog.benjojo.co.uk/post/auditing-github-users-keys https://blog.benjojo.co.uk/post/auditing-github-users-keys
- jvehent 11y agoIt's a cool awareness experiment. Ultimately, public keys are public and people shouldn't be afraid of sharing them. Agent forwarding sharing is a big one though. Getting people to stop doing that automatically takes a lot of education. https://wiki.mozilla.org/Security/Guidelines/OpenSSH#SSH_agent_forwarding https://wiki.mozilla.org/Security/Guidelines/OpenSSH#SSH_age...
- marcosdumay 11y agoThe public keys should be ok. But the comment on them may be a problem.
- kpcyrd 11y agoThe comment isn't sent to the server during the authentication
- JoshTriplett 11y ago> (And if you have agent forwarding active I show you a big WARNING [0].) It amazes me that people enable that for random servers. Seems like SSH should make that harder. Enabling it for a specific server you trust makes sense; enabling it for all servers doesn't. SSH could reject "ForwardAgent" outside a Host block, for instance, and force you to at least write a "Host *" block. EDIT: Check out this search: https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type=Code&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type...
- skarap 11y ago> EDIT: Check out this search: https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type.. https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type.... Holy mother of god, can we somehow return to the time when almost nobody used *nix and Microsoft was the one struggling to keep systems of these people secure?
- riffraff 11y agoI don't think this time ever existed, I remember some fifteen years ago using google to search for unshadowed /etc/passwd and vulnerable cgi scripts, and there were tons of results.
- phamilton 11y agoFor those who don't get why this is terrible, imagine if GitHub were compromised and their ssh agent tampered with. When you clone a repo, they could use your forwarded agent to log into your production hosts. That's pretty bad.
- javajosh 11y agoI don't fully understand how this would work - the key being "forwarded agent". My (poor) understanding is that in order for compromised github to get to a host I'm connected to they would somehow need to invoke ssh on my host, somehow. The only way that would not be the case is if ssh maintains an in-memory persistent thing that a) maintains connections to foreign hosts, and b) can somehow be signaled from active connections. If that's true, then a) I didn't realize it could do that, and b) it would be quite handy sometimes, although the security implications are rather serious.
- brandonbloom 11y agoAnd now I've rotated my keys and fixed my ssh config file. Thanks :-)
- umangd 11y agowhy rotate them? They're just public keys anyways. Useless on their own.
- leni536 11y agoNote that -X is similarly bad on untrusted servers [1]. While it's an old article, it's still valid. [1] http://www.hackinglinuxexposed.com/articles/20040705.html http://www.hackinglinuxexposed.com/articles/20040705.html
- FiloSottile 11y agoThanks for the link, adding a warning for that, too.
- rhino42 11y agoThanks for the warning by the way! Moved forwardagent to specific servers. I almost always log into trusted servers, but it's good to be preemptive ;-)
- ars 11y agoIs there a way to set that in bulk so all hosts in your config send identities, but those not specified don't, without putting IdentityFile for every one?
- azernik 11y agoYou can create a host block that matches multiple hosts: IdentitiesOnly yes Host first second third fourth IdentitiesOnly no If you then wanted to have per-host configs you'd have to create more host blocks, but at least this way the added overhead of "IdentitesOnly yes" doesn't grow too fast with the number of hosts involved.
- jlgaddis 11y agoUntested but you should also be able to use "Match" directives as well, assuming there's something in common you can match on, e.g.: Match Host *.example.com, 192.0.2.* IdentitiesOnly no
- c22 11y agoThis only worked for me after I renamed id_rsa (and id_rsa.pub).
- RexRollman 11y agoI never realized that SSH does this. Thank you.
- deleted 11y ago[deleted]
- jpmattia 11y agoThis really need to be better known.
- mirimir 11y agoThanks!
- leepowers 11y agoI added IdentitiesOnly to my config recently. Partially for security. But also because an non-Github git service would bail whenever too many incorrect identity files were attempted. I've also had SSH servers bail when trying too many keys/identities.
- scintill76 11y agoYeah, IIRC the error with too many identities is hard to diagnose (something generic like "too many authentication failures"), until you add -v and see all your keys being presented.
- 616c 11y agoI am one of these people with a newfound attention to security (I would not call it detail). I was unaware of the ~/.ssh/config param you mention. Very cool, people like keep me hooked to HN. Keep it up!
- rogeryu 11y ago> If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does) If you have five keys, and the second is the one that's needed, doesn't that mean that only the first two keys are sent? Anyway, this is very good to know, and I'm going to take action to make this more secure.
- chrisfosterelli 11y agoYes, provided that the server accepted the second key the rest would not be sent. However, the server can simply respond that each key is incorrect (regardless of if it is or not), and then get all five keys. Once SSH has ran out of keys to try, it tries to move on to other authentication methods. The go app he has written then automatically accepts the connection at that point, once it knows it has seen all of your keys.
- FiloSottile 11y agoDouble-reading the man page I noticed that IdentitiesOnly makes ssh only send IdentityFile keys, however IdentityFile has a default of "~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa". The result is that with this configuration you would still send id_rsa to unknown hosts. You also need to add "PubkeyAuthentication no" to your global stanza, and re-enable it for good hosts. # Ignore ssh-agent keys IdentitiesOnly yes # Disable public key authentication PubkeyAuthentication no # Send your public key to github only Host github.com PubkeyAuthentication yes IdentityFile ~/.ssh/id_rsa More instructions: https://github.com/FiloSottile/whosthere#how-do-i-stop-it https://github.com/FiloSottile/whosthere#how-do-i-stop-it
- chrisfosterelli 11y agoAh, good catch! I don't normally name my keys after the default "id_rsa" so I didn't notice that. You will need that configuration you showed if you have keys that use the default value.
- toyg 11y agoDoesn't seem to work for me, the global option is not overridden. Bog standard osx OpenSSH_6.2p2. Ah well, I don't have any default key anyway.
- blfr 11y agoYou also need to add "PubkeyAuthentication no" to your global stanza, and re-enable it for good hosts. Or rename the id_* keys to something else. If you're using multiple key pairs will want more descriptive names anyway.
- nestorp 11y agoF
- gioele 11y ago> This is also handy if you're security conscious and like to use a different private/public key pair for each host you have an account with! This is a tiny tutorial I wrote ages ago: http://retrieve.tumblr.com/post/228790418/create-ssh-key-for-a-single-purpose http://retrieve.tumblr.com/post/228790418/create-ssh-key-for...
- dlitz 11y ago> This is also handy if you're security conscious and like to use a different private/public key pair for each host you have an account with! That's an odd definition of "security conscious". This looks more like a key management nightmare. You're still sending the same default username to every host anyway, so what's the point?
- scintill76 11y agoIt allows you to do things like have varying passphrase strength on your encrypted keys, depending on how much you care about keeping each one safe; or putting only the private keys you usually need on each device, rather than one/few keys that will get all your systems pwned if it's compromised.
- chrisfosterelli 11y agoExactly. Additionally, if I associate a new key pair with each host then I know I can discard + regenerate that key and it only affects that host. Each machine can have their own pairs as well. If a key is compromised, it only provides access to a single host, not _all_ of them. This allows much more fine-tuned key management and reduces the scope of a key compromise. Plus, it's not really that much more work. Just name your key after the host it's for, and then add an IdentityFile directive in your SSH config. I never have to worry about it, and get all the benefits.