16 ms·

Show HN: My SSH server knows who you are

836 points by FiloSottile 11y ago

Raed667 11y ago
Would be interesting to see what can also be done with Keybase API.
simme_ 11y ago
Neat. I wonder how many "attackers" that scan ssh etc. could be identified by this.
- shanemhansen 11y ago
  There are probably some morons out there, but I'd be surprised if most automated ssh scanners were offering up a private/public keypair.
  - kaybe 11y ago
    The best moron I ever saw had his full name as computer name and we gave him a phone call at his house - his mother answered first, it was awesome!
    - simme_ 11y ago
      You don't happen to have recordings of it, by chance?
      - kaybe 11y ago
        No, sadly. It was a long time ago.
cmadan 11y ago
Good thing I use HTTP to push to Github (or not?)
- badmadrad 11y ago
  no. you should use an ssh key w/ password. more secure and easier. your public key is designed to be public.
- aw3c2 11y ago
  Just use another key. I have like 20. It sucks that doing this is pretty complicated though. Separation of identities is crucial on the internet.
- justizin 11y ago
  SSH with a keypair should be much more secure than user/pass over TLS.
scosman 11y ago
"don't worry, I don't have any OpenSSH 0day" > That's exactly what someone with a 0 day would say!
- kazinator 11y ago
  Someone with an OpenSSH client 0day would just quietly open an SSH port and wait about five minutes for the next sucker. You don't have to phish on HN to get people to connect to an SSH port.
  - FiloSottile 11y ago
    But I wouldn't get access to all these "DevOps-style" startups backends... Oh. Oh, I shouldn't have said that. ;)
deleted 11y ago
[deleted]
tacone 11y ago
> Did you know that ssh sends all your public keys to any server it tries to authenticate to? You can see yours echoed below. > We tried to use that to find your GitHub username, but we couldn't :( maybe you don't even have GitHub ssh keys, do you? > By the way, did you know that GitHub publishes all users' ssh public keys and Ben (benjojo.co.uk) grabbed them all? > That's pretty handy at times :) But not this time :( Better luck next time, I guess :)
- mhurron 11y ago
  > By the way, did you know that GitHub publishes all users' ssh public keys and Ben (benjojo.co.uk) grabbed them all? > That's pretty handy at times :) But not this time :( >Better luck next time, I guess :) Who cares if they publish Public Keys. They're meant to be public, it's one of the few well named things in computer science. They are basically meant to be spewn everywhere.
  - gmalette 11y ago
    You may be interested in knowing that you can DOS someone if you know only their public keys. https://medium.com/@gmalette/mistaking-authentication-for-identification-983447739eee https://medium.com/@gmalette/mistaking-authentication-for-id...
    - marcosdumay 11y ago
      You can DOS anyone at any time, just by knowing how to contact them. DOS is the one attack one can not defend against, only attenuate.
      - eru 11y ago
        A DOS is especially annoying, if the attacker needs to burn less resources than the defender.
    - barkingcat 11y ago
      You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace. Public keys are supposed to be public.
yesco 11y ago
Forgive me ignorance here but what steps should I take to avoid someone from getting my public key off github and then using it to screw with my repos? Was there a major step I missed here when I made these keys?
- kevinastone 11y ago
  It's a public key for a reason. You need to the private key to authenticate, so you're safe having everyone know your public key.
  - nly 11y ago
    It's fairly pointless of github to publish your public key though. Nobody can trust that it's actually yours.
    - chrisfosterelli 11y ago
      If you trust your connection to Github and trust that the person in control of the account is the person the account represents, then why not trust that key?
    - the8472 11y ago
      > It's fairly pointless If it enables security research it's already a win in my eyes. Might expose classes of weak keys in the future for example.
      - chrisfosterelli 11y ago
        Great point. That's already happened, and a lot of weak keys were found [0]. [0] https://blog.benjojo.co.uk/post/auditing-github-users-keys https://blog.benjojo.co.uk/post/auditing-github-users-keys
  - RaleyField 11y ago
    > It's a public key for a reason It's public key because it's named such in the context of public key cryptography. But not all public keys should be available to public. Ideally by default ssh client should use a different key pair for each server('s public key) it connects to. Some people want to hide their identity, for example Tox people chose to be anonymous, what SSH does goes against expectations so it has the ability to betray their choice.
jonbwhite 11y ago
The connection gets closed immediately for me, what is it supposed to do?
- swah 11y ago
  For those who couldn't make it work: +---------------------------------------------------------------------+ | | | _o/ Hello! | | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? You can see yours echoed below. | | | | We tried to use that to find your GitHub username, but we | | couldn't :( maybe you don't even have GitHub ssh keys, do you? | | | | By the way, did you know that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all? | | | | That's pretty handy at times :) But not this time :( | | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+
  - tschuy 11y ago
    And for those that want to see what a successful key check looks like: +---------------------------------------------------------------------+ | | | _o/ Hello Evan Tschuy! | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? | | | | That's how we know you are @tschuy on GitHub! | | | Ah, maybe what you did't know is that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all. | | | | That's pretty handy at times :) for example your key is at | | https://github.com/tschuy.keys | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+ Connection to whoami.filippo.io closed.
jonathonf 11y ago
ssh_dispatch_run_fatal: Connection to 178.32.139.168: no matching key exchange method found Hm. kex: client->server aes128-gcm@openssh.com Meh.
- LeonidasXIV 11y ago
  Same. Apparently this server does not support any modern day crypto.
swah 11y ago
I use putty, this failed.
- Zikes 11y ago
  It prints a message and immediately boots you out. By default, Putty will close the window when the connection terminates. Here is the message I got: $ ssh whoami.filippo.io The authenticity of host 'whoami.filippo.io (178.32.139.168)' can't be established. RSA key fingerprint is c8:9a:b0:9d:59:96:24:37:70:4c:ef:eb:31:47:68:40. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'whoami.filippo.io,178.32.139.168' (RSA) to the list of known hosts. +---------------------------------------------------------------------+ | | | _o/ Hello Jason Hutchinson! | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? | | | | That's how we know you are @zikes on GitHub! | | | Ah, maybe what you did't know is that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all. | | | | That's pretty handy at times :) for example your key is at | | https://github.com/zikes.keys | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+ Connection to whoami.filippo.io closed.
- morganvachon 11y ago
  Strictly speaking, it didn't fail; PuTTY on Windows works a bit differently from command-line ssh on OS X/Linux, and doesn't show you everything. It brings you directly to a "login as:" prompt after throwing up a dialog about missing/unknown keys. What you were supposed to see never made it to the screen.
acomjean 11y ago
Didn't work for me. Here's what I got. I cleaned out .ssh/knownhosts after connecting. +---------------------------------------------------------------------+ | | | _o/ Hello! | | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? You can see yours echoed below. | | | | We tried to use that to find your GitHub username, but we | | couldn't :( maybe you don't even have GitHub ssh keys, do you? | | | | By the way, did you know that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all? | | | | That's pretty handy at times :) But not this time :( | | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+ Connection to whoami.filippo.io closed. Arams-MacBook-Pro:~ acomjean$ emacs .ssh/known_hosts
- joeblau 11y ago
  Didn't work for me either. It seems like it fails more than it succeeds based on the results posted in this thread.
  - riffraff 11y ago
    presumably, those for which it worked are less likely to post? FWIW, it worked for me.
fortytw2 11y ago
Neat stuff. You could use this to let users identify themselves to services/ssh services via pubkey as their GitHub username - like https://github.com/shazow/ssh-chat https://github.com/shazow/ssh-chat - but with users automatically unique and identified by GitHub.
- publysher 11y ago
  CoreOS used to do this, but stopped doing it: https://github.com/coreos/coreos-cloudinit/issues/334 https://github.com/coreos/coreos-cloudinit/issues/334 Basically, they don't want server provisioning to depend on Github being up.
deleted 11y ago
[deleted]
samps 11y ago
In all seriousity, I would love a similar SSH server that automatically uses keys from GitHub for authentication. Great for setting up a little private git server without fiddling with keys.
- delinka 11y ago
  Just keep in mind that you're now at the mercy of github. Or whomever pwns their servers.
  - eru 11y ago
    You can salvage something from that idea: github is in the public eye. If they do something fishy, you'll probably now about it a month later. So, for your login service you scrap github periodically, and only trust things that have been there a month ago already. (A bit like ssh being vulnerable to MitM attack on the very first connection, but not afterwards.)
pmatev 11y ago
Pretty interesting. Although it couldn't find my github ssh keys for some reason. Maybe the database has some stale entries? I imagine it's quite a lot of user data to go through and process.
ambrop7 11y ago
Does the server get the client's public key before or after the client has identified the server? I suspect it's after - which would imply that this is much less harmful than it looks like, since by then you've already confirmed the identity of the server. So if my assumption is correct (some quick googling for images of the ssh key exchange suggests it is), then the reason it "works" in this case is because people intentionally say "yes" when presented with the fingerprint, just to see what would happen. If you were ssh-ing to a server that you've used before, there is little to worry about because the ssh client first authenticates the server, and the server presumably needs to know who you are anyway.
- icebraining 11y ago
  The server only gets the key after it has been identified; you can see that by using "ssh -v".
- taejo 11y ago
  It should be safe to say "yes" to any fingerprint from any server you don't trust (as long as you don't send any sensitive information over the connection, or trust information coming from it). The risk is that you accept a fingerprint for a server you do trust, allowing some other server to steal that trust.
duggan 11y ago
If this surprises people, it's definitely doing some good. Nicely presented, Filippo!
- roozbeh18 11y ago
  surprise to me. added IdentitiesOnly yes to my config file.
pdq 11y ago
Found me; very nice. I wouldn't have guessed how you did it without the explanation about GitHub. I wonder if this means we should be rotating keys periodically? I know most companies require users to rotate their password every X days. Also, does GitHub have a setting to disable public key publishing?
- delinka 11y ago
  You should be using different key pairs on each client machine you log into. You should also be using different key pairs for each host to which you connect (and using ~/.ssh/config to specify which keys are sent to which hosts.) Not only will this limit correlation as demonstrated here, but also make it much easier to revoke access via keys that may have been compromised.
- latortuga 11y ago
  They're public keys, they're intended to be public. What are you trying to hide by hiding your public key?
  - justizin 11y ago
    Though it may be incredibly impractical or theoretically impossible, depending on the key and time of day, there is always a possibility that a public key can be used as an attack vector to guess a private key.
    - gmalette 11y ago
      Or simply to DOS you out of your other accounts. https://news.ycombinator.com/item?id=10005358 https://news.ycombinator.com/item?id=10005358
  - bartbes 11y ago
    As much as the keys contain public data, I wouldn't consider (but it apparently is) the list of keys with access to my github account public data. Github willingly reveals information about pseudonyms, etc. This is a data vs metadata thing, the data is public, but who it belongs to, and what one can do with it need not be.
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 ago
  I do the same thing, plus I maintain a separate public/private key pair for every host where I need the pubkey auth.
- FiloSottile 11y ago
  Exactly! 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 ago
    This 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 ago
_wmd 11y ago
Didn't work for me, not because I don't have a Github key, but because I use separate keys for everything, and don't have a default key (requires plenty of ~/.ssh/config muckery). I had been doing this because I'm paranoid, and because I have a tendency to copy keys for my colo boxes to work computers, and my Git keys to the colo boxes. Now I have a new reason -- public keys basically act like a giant supercookie for SSH.
- toxicFork 11y ago
  Same here. Here's my ~/.ssh/config for anyone interested in what it looks like: Host github.com User toxicFork IdentityFile ~/.ssh/github-toxicFork Host bitbucket.org User toxicFork IdentityFile ~/.ssh/bitbucket-toxicFork And my personal security policy: - Once I want to use a device for development, I create separate key pairs for all of the services I want to use, register it on that server's account config and then add it to my config file by hand ( I should find or write a script to do these automatically :D ) - Once I want to retire a device (or if it gets lost) I just remove the public keys from the services - NEVER move or copy private keys, I'd rather create a new private key and remove the references for the old public keys instead
  - ultramancool 11y ago
    Good policies, the mere presence of an id_<ciphername> key in .ssh means you can be identified between multiple ssh servers. I identified this in the OpenSSH source a while ago and posted it on reddit at one point, but few people understood. Glad someone made a practical attack out of it now. IP correlation may seem a more obvious attack, but such an attack could be used to identify for example, someone running a darknet operation or using VPNs for privacy or simply to tie an IP to a name using a public key service like in this example.
sp4ke 11y ago
It didn't work for me even though I have a github account and ssh key installed from the same machine. Maybe related to the fact I use several keys and keychain to manage keys.
deleted 11y ago
[deleted]
aw3c2 11y ago
A great reminder that public key identity management is quite the unsolved annoyance. Why should you use the same key everywhere, allowing others to track you? Ideally you would have one key per service.
- mirimir 11y ago
  Yes. And all of my machines are named "host", with user "user" :)
arturhoo 11y ago
Nice idea, but don't run the command if you have Host * ForwardAgent yes On your ~/.ssh/config
- chmike 11y ago
  What is the effect of ForwardAgent ?
  - arturhoo 11y ago
    The host you're connecting to could be able to, force write/destroy your public repos or clone your (and your employer's) private repos given that he knows their paths, eg: github/github. I'd assume that a few companies have a */secrets repo of some sort.
  - rmetzler 11y ago
    Forwarding your keys basically. It's like giving someone you don't know a handshake AND all your keys.
    - deleted 11y ago
      [deleted]
    - lcswi 11y ago
      public keys I hope?!
      - rmetzler 11y ago
        I worded it the wrong way I guess. Edit: I don't really know how do say this short and concise, but you should only do this with servers you trust. * http://rabexc.org/posts/pitfalls-of-ssh-agents http://rabexc.org/posts/pitfalls-of-ssh-agents * http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-cons...
      - ewindisch 11y ago
        No, it gives the remote server use of your private keys during the lifetime of your connection through connection to your local agent. Yes, it's really stupid to enable AgentForwarding.
omarforgotpwd 11y ago
weird idea: server that hosts open source git repos, but won't let you ssh in to clone unless your GitHub account has contributed to an open source project this year.
- golergka 11y ago
  This would make this repos not open source, unless they are replicated elsewhere as well.
- cortesoft 11y ago
  Until someone forks it
dadrian 11y ago
A good reminder that your public keys are, in fact, public. For most people, this is probably a good thing, unless you're specifically trying to hide your identity.
- gurkendoktor 11y ago
  But I wish anonymity was the default, not something I have to enable as a special case... :(
rtz12 11y ago
We tried to use that to find your GitHub username, but we couldn't :( maybe you don't even have GitHub ssh keys, do you? You just need to properly configure your SSH.
hamandcheese 11y ago
Go has a great SSH library from what I can tell. I'm currently working on a project that is based around SSH, and Go seemed to be the only real option.
gcb0 11y ago
tl;dr: 1. ssh sends the pubkey you use on github ^1 2. his server compare with the publicly ^2 available pub key you uploaded to github.com ^1 (not mine, i set keys per domain) ^2 news to me!
sarciszewski 11y ago
It just closes my connection. root@paragonie:~# ssh whoami.filippo.io Connection to whoami.filippo.io closed. I'm not sure what I'm supposed to be seeing.
- bmohlenhoff 11y ago
  ...presumably it doesn't allow root logins via SSH
  - sarciszewski 11y ago
    Oh, duh, username!
    - woof 11y ago
      Why on earth are you logged in as root? man sudo
      - uniformlyrandom 11y ago
        sometimes you just sudo -s
        lottin 11y ago
        I prefer su -
        uniformlyrandom 11y ago
        You need a root password for that one.
      - sarciszewski 11y ago
        Virtual machine :P
  - bonif 11y ago
    Same for me with non-root user iMac:~ bonf$ ssh whoami.filippo.io Connection to whoami.filippo.io closed.
parshimers 11y ago
That's actually super handy. Next time I have to add someone to a shell account, I'll probably just look them up on GitHub first to find their public key instead of asking.
- beagle3 11y ago
  ... thereby making any successful manipulation of the github key database (by the github people or by an attacker, as has happened before - google e.g. http://egorhomakov.com/ http://egorhomakov.com/ ) a successful penetration of YOUR system. Security and convenience unfortunately conflict often.
derefr 11y ago
It occurs to me that you could use this same mechanism to reduce the configuration load on machines that provision users using cloud-init(8). Right now, cloud-init accepts a list of GitHub usernames that should be allowed to log into the machine (which is pretty clever in-and-of-itself), and then creates users for them and sets their authorized_keys to whatever values the GitHub public-SSH-key API returns. But, rather than "burning in" a set of allowed users, you could do something much more interesting: allow any key to authenticate, and then map it back to a user and find out if that user has write-access to the GitHub project!
- eru 11y ago
  It will probably work. But it seems like you are increasing the attack surface here: the current method gets the list of keys once, and if github isn't compromised at that very instant in time, you are safe. Your proposed method relies on trust in github at all times.
rdl 11y ago
I use different keypairs for different trust domains. (also makes it easier to hand over access when you quit a job.) SSH keys are actually pretty horrible from a security perspective; no expiration, generally held in software, etc. And without a lot of work, single-factor. I love the ssh security model of being pretty good and better than telnet for everything (which it ~fully displaced, unlike https vs. http), but client keys are one of the weak points.
- eru 11y ago
  > And without a lot of work, single-factor. Wouldn't a passphrase be a second factor? By the way, we use a security fob at work for that. Seems to work fairly well. The private key never leaves the fob, you have to press a button to sign anything, and every once in a while you have to enter your passphrase.
  - rdl 11y ago
    passphrase is set/unset locally and not communicated to the server if it is present/used/etc. Could be disabled. along with various other things. HW token with ssh key inside is probably the best. The annoying thing is devices w/o USB. For iOS devices and android devices which support it it's probably better to just use the HW sec features. Something which did bt 4.0le and maybe had a single local LED and button would be better still.
    - eru 11y ago
      > The annoying thing is devices w/o USB. Some new tokens use NFC.
      - rdl 11y ago
        Yeah, but sadly closed iOS sometimes oddly security hostile ecosystem bullshit. Bluetooth would be vastly better for interop.
  - ersii 11y ago
    What hardware token (security fob) are you guys using? And is it working well?
georgerobinson 11y ago
This is clever, and very sneaky! Let's say I downloaded every public key from GitHub to ~/.ssh. Would this identify me as everyone on GitHub, or just the owner of the first public key to match? Furthermore, I wonder how Go channels compare to libevent (more specifically, epoll/queue) for high-performance network software. Is there any previous work which compares the two?
- ParadoxOryx 11y ago
  Adding those public keys would not identify you as everyone, as you do not have all the matching private keys.
  - georgerobinson 11y ago
    Someone else commented on here that: > 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) Therefore, even though I can't authenticate as Linus Torvalds, an SSH server can see me present his public key and hence, log that public key for future use, like sending a message? Is that not correct?
skarap 11y ago
Nice trick! Also - everybody should probably be aware that SSH zero-day isn't the only bad thing which can happen to you if you connect to a malicious SSH server. Your terminal emulator has a higher chance of being vulnerable (e.g. take a look here: https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/ https://www.proteansec.com/linux/blast-past-executing-code-t...) than openssh does. P.s. "(And written in Go!)" - the trick would still be very cool if it was written in C, JavaScript, PHP, COBOL or any other language (and it would be freaking awesome if written in brainfuck!).
vinceguidry 11y ago
I simply got a "Connection to whoami.filippo.io closed."
- argc 11y ago
  Same here...
dmytrish 11y ago
At first, I thought that this is pretty harmless, but now I suspect that there may be a way to exploit a dump of public keys tied to personal information: let's say that some powerful adversary (like NSA) uses some kind of rainbow tables to associate public keys with private. Having a lot of public keys, they are likely to know some private ones and identities behind them. This hypothesis requires some mathematical ground, though. It may be that probability of guessing a private key is still negligible.
- craigds 11y ago
  Not exactly a cryptography guy, but I don't think PKC quite works like that. Rainbow tables rely on people using the same password as each other. This happens a lot with passwords, but it's unlikely to happen with key pairs, assuming they're generated with proper CSPRNGs.
- baby 11y ago
  > rainbow tables There is no such thing in public key crypto. The only thing that comes close to it that I can think of is the problem where weak public parameters were hard coded in a library (Apache) and were used by many many many person. Look at the logjam paper.
ambicapter 11y ago
Doesn't work on OS X 10.10.4?
scintill76 11y ago
Ooh goodie, we get to re-open the argument about whether it was bad of GitHub to publish the public keys![1] Pick your talking points: "They're called public for a reason.", "This could enable identity tracking.", "If your security model prefers public keys to be kept secret, it's absurd -- security by obscurity.", "This could enable factoring weak keys.", "This is good for security research.", "It's wrong to reveal metadata without consent, even if it doesn't break the crypto." You could build in another PoC by doing the trick where you hide a command inside the copy-paste version of the ssh command line you gave.[2] [1] https://news.ycombinator.com/item?id=9645703 https://news.ycombinator.com/item?id=9645703 [2] https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste
therealmarv 11y ago
After the question of adding this server to known hosts OS X asked me for the passoword of my private key. Is this normal? Of course I refused and got the message like displayed in other comments.
barkingcat 11y ago
Isn't this just ssh functioning as usual? You can specify which public key ssh should use by updating .ssh/config Otherwise, what's the harm in other people knowing your public key?
- taejo 11y ago
  Yes, but it's also ssh functioning in a way people don't know about.
enaasen 11y ago
Ok, as a total noob, what does this this suppose to demonstrate?
- digital-rubber 11y ago
  That if you have your public key on github and you ssh to a random machine, you leak information that can be correlated with github data, and if you filled in your details nicely at github, he can fetch your 'real name' based on the ssh announced key upon connect. This is a stupid post, more critical would be why the fop people host shit at github in the first place. Talking to _you_ paid subscription people with 'private' projects. If you can't even store your own data, why people even create it.
rhinoceraptor 11y ago
Interesting, it didn't work for me because I use a Yubikey Neo with PKCS11 for my SSH keys.
uniformlyrandom 11y ago
Luckily, putty/kitty does not send anything to unknown hosts. Good try though. Please accept a record of my IP address connecting to your honeypot as a token of gratitude.
- eru 11y ago
  The standard linux ssh client also asks for confirmation before sending anything interesting to a new server.
drinchev 11y ago
I don't see what's wrong with that.
ultramancool 11y ago
I brought this attack up on reddit 3 years ago. http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers_your_public_keys_to_all_servers/ http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers... Glad to see someone implemented an attack and can demonstrate it well now. Cheers Filippo.
- baby 11y ago
  "attack"
  - eru 11y ago
    It's an attack on privacy expectations. There are at least two ways to escalate from here: - One if agent forwarding is enabled. - Another: learning details like people's names is often a first step in social engineering.
    - ultramancool 11y ago
      There's also another leak which isn't really shown here and that leak is that, with just a public key, you can offer to servers and they'll tell you if it's present or not. Using this you could scan the internet (given 6-12 hours and a shitty VPS that you can throw away this is quite possible) for someone's public key to find all of their servers, which could lead to a bypass of DDoS protection, identification of a Tor hidden service, etc.
      - versteegen 11y ago
        Yep, see also Rachelbythebay's comment in this thread (in particular the second post she links to); this is definitely exploitable. https://news.ycombinator.com/item?id=10008012 https://news.ycombinator.com/item?id=10008012
    - baby 11y ago
      > It's an attack on privacy expectations. It's a misunderstanding of the word "public"
GauntletWizard 11y ago
The last time this came up, I wrote a little script to update your authorized_keys file with your github keys. https://github.com/GauntletWizard/pamgithub https://github.com/GauntletWizard/pamgithub
petrsnd 11y ago
There may be some people concerned with GitHub publishing their identity to everyone, but it is pretty easy to use a separate key for GitHub (they'll even generate it for you) if you configure your ssh client appropriately with Host sections. Also, the same technique works if you want to use two different accounts on GitHub (one for work & one for personal). http://stackoverflow.com/questions/19310368/using-two-ssh-keys-with-github-along-with-connection-multiplexing http://stackoverflow.com/questions/19310368/using-two-ssh-ke...
ernsheong 11y ago
"Public keys" are supposed to be public anyway, isn't that what it's designed for? I see no harm
- userbinator 11y ago
  Using the same public key on two sites is like using the same username - something that you would do only if you want your identity linked between those sites. It's also a much stronger proof of identity than having the same username, because that's what they were designed for.
  - baby 11y ago
    So don't use the same public key on two different site
- gojomo 11y ago
  Not necessarily. The "public" in "public key" is not an announcement of intended global availability, but rather role in contrast to "private key". There are many reasons people or systems might want to keep "public keys" obscured or pseudonymous. Still, many probably don't mind the public disclosure of Github account public keys. But, the more serious issue here goes beyond that. In an unexpected and likely unintended way, one's Github identity is revealed to a third party, along with your origin IP and quite possibly other SSH keys used with other systems. It's that set of mappings – IP <-> Github identity <-> other identities – that violates expectations.
robryk 11y ago
It seems that I get no output because I have an SSH certificate: robryk@sharya-rana ~> ssh -v whoami.filippo.io <...> debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/robryk/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering RSA-CERT public key: /home/robryk/.ssh/id_rsa Connection closed by 178.32.139.168
cmdrfred 11y ago
Just kicked me off after I accepted it's fingerprint, maybe it's down? I have a 8192 bit RSA key.
rachelbythebay 11y ago
Hey, cool, someone did part one with the GitHub public keys. http://rachelbythebay.com/w/2013/04/07/ssh/ http://rachelbythebay.com/w/2013/04/07/ssh/ Now, someone, do part two. http://rachelbythebay.com/w/2013/07/20/ssh/ http://rachelbythebay.com/w/2013/07/20/ssh/
- INTPenis 11y ago
  Wow after both of those blog posts, TWO years ago, I'm surprised github hasn't stopped exposing this identity information and us HN users haven't started being more paranoid about our ssh_configs.
  - nindalf 11y ago
    Public keys are meant to be public, so is it a problem if everyone knows your public key? How often do you want to SSH into a remote server while wanting to remain private? And supposing you really want to, can't you maintain separate keys for separate hosts as other commenters have suggested? Perhaps I'm missing something here.
  - misterjinx 11y ago
    why would they? after all they are public keys, they are supposed to be public. if you really are afraid of github exposing your public key, I think you can always create a separate pair to use only with github.
    - eru 11y ago
      And in some sense github is doing as a favour, by partially solving the key distribution problem. If you send me your public key via email, I don't know whether you are who you claim you are. If I get your public key via github, at least I know that you are the person contributing to all those open source projects.
username 11y ago
Wow, thanks for demonstrating this. A dead simple technique like this could have compromised me when trying to use SSH pseudonymously.
INTPenis 11y ago
I see most people acting like this was obvious but I gotta believe that a clear majority of ssh users had no idea about this. Yet it's extremely obvious when you think about it. This, this is true hacking. This is so elegant. I love you Filippo. Keep being awesome!
senthilnayagam 11y ago
like google analytics cookies track your every activity on every website, sending public keys feel the same way. now I have to re-evaluate my ssh usage after discovering ssh sends all my public keys. need to setup per server identities, without too much usage hassle . hope github will stop publishing public keys.
hitlin37 11y ago
i know what you did last summer on my server, would have been better title.
emmelaich 11y ago
Didn't work for me because I use a separate key for each "class" of machines, where class is github, bitbucket, work, home, ... You can reduce the maintenance load by using the %h (remote hostname) and %r (remote username) substitutions in IdentityFile. I make a symlink from the key I want to e.g. id-rsa-<remoteuser>@<remotehostname>.key and use IdentitiesOnly. See 'man ssh_config' Use %u (local user) and %l (local hostname) for extra control. It doesn't have %p (port) but the Host parameter in future versions of openssh will let you match on that too.
sengork 11y ago
From http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html http://www.cisco.com/web/about/ac123/ac147/archived_issues/i... "publickey: The details of this method depend on the public-key algorithm chosen. In essence, the client sends a message to the server that contains the client's public key, with the message signed by the client's private key. When the server receives this message, it checks to see whether the supplied key is acceptable for authentication and, if so, it checks to see whether the signature is correct."
olorundaglory 11y ago
VEHICLES FOR SALE AT AFFORDABLE PRICES AND IN GOOD CONDITION, CALL OFFICER custom glory 08067834923
anilshanbhag 11y ago
I first thought this was something new but wait he just gets public ssh keys. It is public for a reason, meaning anyone can have it and they are frankly useless. Can't find any comment below saying why this is dangerous ?
jakeogh 11y ago
I wish there was a way to have ssh automatically ssh-add keys you use... with a expiration date. I've tried to get this to work a few times, but I use a unique key for every login, so I need something to parse ~/.ssh/config to find the right Host def and ssh-add it. The code is obviously in ssh, but it's not exposed to the command line as far as I can tell.
digital-rubber 11y ago
So… the fact ssh leaks some information you find more worrying then people storing their source code at github? interesting...
fasteo 11y ago
No sure if I am missing something here, but that's the idea behind PKI infrastructure: You can share your public keys without putting your identity at risk. The "server knows who you are" or rather, I "tell the server who I am" Interesting experiment though.
RoryH 11y ago
Eh, I only forward my github ssh key to the host github.com so you don't know who I am ;-)
131hn 11y ago
I dont want to "play" with ssh_config file. My concern here is how pageant/ssh-agent behave, i think i'll try to fix/find a way around that (e.g. attended calls to agent signing api / configurable calls to agent keys listing). I think i'll drive a node-webkit/systray project being an alternative to pageant (#nwagent on freenode)
kragen 11y ago
I’d noticed before that ssh was rather aggressive about offering public keys to servers, but I didn't know Github published my public keys, and so this totally surprised me.
ausjke 11y ago
so what does this imply, security wise? Isn't public key a give-away anyways? which is what public means? Or I'm going to ssh-keygen a new one once a while.
Wisqnet 11y ago
Cripes, people. WHO CARES? So I SSHed in. I got the message. Then I saw all the people freaking out here and couldn't believe my eyes. Ask yourself this: How often do you SSH in to arbitrary hosts? Ones that you don't control, or work for, or trust with your source code? Did you really expect that you could give the same long unique base64 string to a bunch of different hosts and NOT have them connect your identity between them? Do you not understand that the whole point of public keys is to uniquely and reliably identify yourself to an arbitrarily large number of parties? Honestly, the only real eye-opener here is that Github gives out your public keys and can be scraped to collect all of them. But some of us have been using that functionality to share / snag each other's public keys for a long time now anyway.

836 points by FiloSottile 11y ago

Raed667 11y ago

Would be interesting to see what can also be done with Keybase API.

simme_ 11y ago

Neat. I wonder how many "attackers" that scan ssh etc. could be identified by this.

shanemhansen 11y ago
There are probably some morons out there, but I'd be surprised if most automated ssh scanners were offering up a private/public keypair.
- kaybe 11y ago
  The best moron I ever saw had his full name as computer name and we gave him a phone call at his house - his mother answered first, it was awesome!
  - simme_ 11y ago
    You don't happen to have recordings of it, by chance?
    - kaybe 11y ago
      No, sadly. It was a long time ago.

cmadan 11y ago

Good thing I use HTTP to push to Github (or not?)

badmadrad 11y ago
no. you should use an ssh key w/ password. more secure and easier. your public key is designed to be public.
aw3c2 11y ago
Just use another key. I have like 20. It sucks that doing this is pretty complicated though. Separation of identities is crucial on the internet.
justizin 11y ago
SSH with a keypair should be much more secure than user/pass over TLS.

scosman 11y ago

"don't worry, I don't have any OpenSSH 0day" > That's exactly what someone with a 0 day would say!

kazinator 11y ago
Someone with an OpenSSH client 0day would just quietly open an SSH port and wait about five minutes for the next sucker. You don't have to phish on HN to get people to connect to an SSH port.
- FiloSottile 11y ago
  But I wouldn't get access to all these "DevOps-style" startups backends... Oh. Oh, I shouldn't have said that. ;)

deleted 11y ago

[deleted]

tacone 11y ago

> Did you know that ssh sends all your public keys to any server it tries to authenticate to? You can see yours echoed below. > We tried to use that to find your GitHub username, but we couldn't :( maybe you don't even have GitHub ssh keys, do you? > By the way, did you know that GitHub publishes all users' ssh public keys and Ben (benjojo.co.uk) grabbed them all? > That's pretty handy at times :) But not this time :( Better luck next time, I guess :)

mhurron 11y ago
> By the way, did you know that GitHub publishes all users' ssh public keys and Ben (benjojo.co.uk) grabbed them all? > That's pretty handy at times :) But not this time :( >Better luck next time, I guess :) Who cares if they publish Public Keys. They're meant to be public, it's one of the few well named things in computer science. They are basically meant to be spewn everywhere.
- gmalette 11y ago
  You may be interested in knowing that you can DOS someone if you know only their public keys. https://medium.com/@gmalette/mistaking-authentication-for-identification-983447739eee https://medium.com/@gmalette/mistaking-authentication-for-id...
  - marcosdumay 11y ago
    You can DOS anyone at any time, just by knowing how to contact them. DOS is the one attack one can not defend against, only attenuate.
    - eru 11y ago
      A DOS is especially annoying, if the attacker needs to burn less resources than the defender.
  - barkingcat 11y ago
    You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace. Public keys are supposed to be public.

yesco 11y ago

Forgive me ignorance here but what steps should I take to avoid someone from getting my public key off github and then using it to screw with my repos? Was there a major step I missed here when I made these keys?

kevinastone 11y ago
It's a public key for a reason. You need to the private key to authenticate, so you're safe having everyone know your public key.
- nly 11y ago
  It's fairly pointless of github to publish your public key though. Nobody can trust that it's actually yours.
  - chrisfosterelli 11y ago
    If you trust your connection to Github and trust that the person in control of the account is the person the account represents, then why not trust that key?
  - the8472 11y ago
    > It's fairly pointless If it enables security research it's already a win in my eyes. Might expose classes of weak keys in the future for example.
    - chrisfosterelli 11y ago
      Great point. That's already happened, and a lot of weak keys were found [0]. [0] https://blog.benjojo.co.uk/post/auditing-github-users-keys https://blog.benjojo.co.uk/post/auditing-github-users-keys
- RaleyField 11y ago
  > It's a public key for a reason It's public key because it's named such in the context of public key cryptography. But not all public keys should be available to public. Ideally by default ssh client should use a different key pair for each server('s public key) it connects to. Some people want to hide their identity, for example Tox people chose to be anonymous, what SSH does goes against expectations so it has the ability to betray their choice.

jonbwhite 11y ago

The connection gets closed immediately for me, what is it supposed to do?

swah 11y ago
For those who couldn't make it work: +---------------------------------------------------------------------+ | | | _o/ Hello! | | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? You can see yours echoed below. | | | | We tried to use that to find your GitHub username, but we | | couldn't :( maybe you don't even have GitHub ssh keys, do you? | | | | By the way, did you know that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all? | | | | That's pretty handy at times :) But not this time :( | | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+
- tschuy 11y ago
  And for those that want to see what a successful key check looks like: +---------------------------------------------------------------------+ | | | _o/ Hello Evan Tschuy! | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? | | | | That's how we know you are @tschuy on GitHub! | | | Ah, maybe what you did't know is that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all. | | | | That's pretty handy at times :) for example your key is at | | https://github.com/tschuy.keys | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+ Connection to whoami.filippo.io closed.

jonathonf 11y ago

ssh_dispatch_run_fatal: Connection to 178.32.139.168: no matching key exchange method found Hm. kex: client->server aes128-gcm@openssh.com Meh.

LeonidasXIV 11y ago
Same. Apparently this server does not support any modern day crypto.

swah 11y ago

I use putty, this failed.

Zikes 11y ago
It prints a message and immediately boots you out. By default, Putty will close the window when the connection terminates. Here is the message I got: $ ssh whoami.filippo.io The authenticity of host 'whoami.filippo.io (178.32.139.168)' can't be established. RSA key fingerprint is c8:9a:b0:9d:59:96:24:37:70:4c:ef:eb:31:47:68:40. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'whoami.filippo.io,178.32.139.168' (RSA) to the list of known hosts. +---------------------------------------------------------------------+ | | | _o/ Hello Jason Hutchinson! | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? | | | | That's how we know you are @zikes on GitHub! | | | Ah, maybe what you did't know is that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all. | | | | That's pretty handy at times :) for example your key is at | | https://github.com/zikes.keys | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+ Connection to whoami.filippo.io closed.
morganvachon 11y ago
Strictly speaking, it didn't fail; PuTTY on Windows works a bit differently from command-line ssh on OS X/Linux, and doesn't show you everything. It brings you directly to a "login as:" prompt after throwing up a dialog about missing/unknown keys. What you were supposed to see never made it to the screen.

acomjean 11y ago

Didn't work for me. Here's what I got. I cleaned out .ssh/knownhosts after connecting. +---------------------------------------------------------------------+ | | | _o/ Hello! | | | | | | Did you know that ssh sends all your public keys to any server | | it tries to authenticate to? You can see yours echoed below. | | | | We tried to use that to find your GitHub username, but we | | couldn't :( maybe you don't even have GitHub ssh keys, do you? | | | | By the way, did you know that GitHub publishes all users' | | ssh public keys and Ben (benjojo.co.uk) grabbed them all? | | | | That's pretty handy at times :) But not this time :( | | | | | | P.S. This whole thingy is Open Source! (And written in Go!) | | https://github.com/FiloSottile/whosthere | | | | -- @FiloSottile (https://twitter.com/FiloSottile) | | | +---------------------------------------------------------------------+ Connection to whoami.filippo.io closed. Arams-MacBook-Pro:~ acomjean$ emacs .ssh/known_hosts

joeblau 11y ago
Didn't work for me either. It seems like it fails more than it succeeds based on the results posted in this thread.
- riffraff 11y ago
  presumably, those for which it worked are less likely to post? FWIW, it worked for me.

fortytw2 11y ago

Neat stuff. You could use this to let users identify themselves to services/ssh services via pubkey as their GitHub username - like https://github.com/shazow/ssh-chat https://github.com/shazow/ssh-chat - but with users automatically unique and identified by GitHub.

publysher 11y ago
CoreOS used to do this, but stopped doing it: https://github.com/coreos/coreos-cloudinit/issues/334 https://github.com/coreos/coreos-cloudinit/issues/334 Basically, they don't want server provisioning to depend on Github being up.

deleted 11y ago

[deleted]

samps 11y ago

In all seriousity, I would love a similar SSH server that automatically uses keys from GitHub for authentication. Great for setting up a little private git server without fiddling with keys.

delinka 11y ago
Just keep in mind that you're now at the mercy of github. Or whomever pwns their servers.
- eru 11y ago
  You can salvage something from that idea: github is in the public eye. If they do something fishy, you'll probably now about it a month later. So, for your login service you scrap github periodically, and only trust things that have been there a month ago already. (A bit like ssh being vulnerable to MitM attack on the very first connection, but not afterwards.)

pmatev 11y ago

Pretty interesting. Although it couldn't find my github ssh keys for some reason. Maybe the database has some stale entries? I imagine it's quite a lot of user data to go through and process.

ambrop7 11y ago

Does the server get the client's public key before or after the client has identified the server? I suspect it's after - which would imply that this is much less harmful than it looks like, since by then you've already confirmed the identity of the server. So if my assumption is correct (some quick googling for images of the ssh key exchange suggests it is), then the reason it "works" in this case is because people intentionally say "yes" when presented with the fingerprint, just to see what would happen. If you were ssh-ing to a server that you've used before, there is little to worry about because the ssh client first authenticates the server, and the server presumably needs to know who you are anyway.

icebraining 11y ago
The server only gets the key after it has been identified; you can see that by using "ssh -v".
taejo 11y ago
It should be safe to say "yes" to any fingerprint from any server you don't trust (as long as you don't send any sensitive information over the connection, or trust information coming from it). The risk is that you accept a fingerprint for a server you do trust, allowing some other server to steal that trust.

duggan 11y ago

If this surprises people, it's definitely doing some good. Nicely presented, Filippo!

roozbeh18 11y ago
surprise to me. added IdentitiesOnly yes to my config file.

pdq 11y ago

Found me; very nice. I wouldn't have guessed how you did it without the explanation about GitHub. I wonder if this means we should be rotating keys periodically? I know most companies require users to rotate their password every X days. Also, does GitHub have a setting to disable public key publishing?

delinka 11y ago
You should be using different key pairs on each client machine you log into. You should also be using different key pairs for each host to which you connect (and using ~/.ssh/config to specify which keys are sent to which hosts.) Not only will this limit correlation as demonstrated here, but also make it much easier to revoke access via keys that may have been compromised.
latortuga 11y ago
They're public keys, they're intended to be public. What are you trying to hide by hiding your public key?
- justizin 11y ago
  Though it may be incredibly impractical or theoretically impossible, depending on the key and time of day, there is always a possibility that a public key can be used as an attack vector to guess a private key.
  - gmalette 11y ago
    Or simply to DOS you out of your other accounts. https://news.ycombinator.com/item?id=10005358 https://news.ycombinator.com/item?id=10005358
- bartbes 11y ago
  As much as the keys contain public data, I wouldn't consider (but it apparently is) the list of keys with access to my github account public data. Github willingly reveals information about pseudonyms, etc. This is a data vs metadata thing, the data is public, but who it belongs to, and what one can do with it need not be.

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 ago
I do the same thing, plus I maintain a separate public/private key pair for every host where I need the pubkey auth.
FiloSottile 11y ago
Exactly! 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 ago
  This 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 ago

_wmd 11y ago

Didn't work for me, not because I don't have a Github key, but because I use separate keys for everything, and don't have a default key (requires plenty of ~/.ssh/config muckery). I had been doing this because I'm paranoid, and because I have a tendency to copy keys for my colo boxes to work computers, and my Git keys to the colo boxes. Now I have a new reason -- public keys basically act like a giant supercookie for SSH.

toxicFork 11y ago
Same here. Here's my ~/.ssh/config for anyone interested in what it looks like: Host github.com User toxicFork IdentityFile ~/.ssh/github-toxicFork Host bitbucket.org User toxicFork IdentityFile ~/.ssh/bitbucket-toxicFork And my personal security policy: - Once I want to use a device for development, I create separate key pairs for all of the services I want to use, register it on that server's account config and then add it to my config file by hand ( I should find or write a script to do these automatically :D ) - Once I want to retire a device (or if it gets lost) I just remove the public keys from the services - NEVER move or copy private keys, I'd rather create a new private key and remove the references for the old public keys instead
- ultramancool 11y ago
  Good policies, the mere presence of an id_<ciphername> key in .ssh means you can be identified between multiple ssh servers. I identified this in the OpenSSH source a while ago and posted it on reddit at one point, but few people understood. Glad someone made a practical attack out of it now. IP correlation may seem a more obvious attack, but such an attack could be used to identify for example, someone running a darknet operation or using VPNs for privacy or simply to tie an IP to a name using a public key service like in this example.

sp4ke 11y ago

It didn't work for me even though I have a github account and ssh key installed from the same machine. Maybe related to the fact I use several keys and keychain to manage keys.

deleted 11y ago

[deleted]

aw3c2 11y ago

A great reminder that public key identity management is quite the unsolved annoyance. Why should you use the same key everywhere, allowing others to track you? Ideally you would have one key per service.

mirimir 11y ago
Yes. And all of my machines are named "host", with user "user" :)

arturhoo 11y ago

Nice idea, but don't run the command if you have Host * ForwardAgent yes On your ~/.ssh/config

chmike 11y ago
What is the effect of ForwardAgent ?
- arturhoo 11y ago
  The host you're connecting to could be able to, force write/destroy your public repos or clone your (and your employer's) private repos given that he knows their paths, eg: github/github. I'd assume that a few companies have a */secrets repo of some sort.
- rmetzler 11y ago
  Forwarding your keys basically. It's like giving someone you don't know a handshake AND all your keys.
  - deleted 11y ago
    [deleted]
  - lcswi 11y ago
    public keys I hope?!
    - rmetzler 11y ago
      I worded it the wrong way I guess. Edit: I don't really know how do say this short and concise, but you should only do this with servers you trust. * http://rabexc.org/posts/pitfalls-of-ssh-agents http://rabexc.org/posts/pitfalls-of-ssh-agents * http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-cons...
    - ewindisch 11y ago
      No, it gives the remote server use of your private keys during the lifetime of your connection through connection to your local agent. Yes, it's really stupid to enable AgentForwarding.

omarforgotpwd 11y ago

weird idea: server that hosts open source git repos, but won't let you ssh in to clone unless your GitHub account has contributed to an open source project this year.

golergka 11y ago
This would make this repos not open source, unless they are replicated elsewhere as well.
cortesoft 11y ago
Until someone forks it

dadrian 11y ago

A good reminder that your public keys are, in fact, public. For most people, this is probably a good thing, unless you're specifically trying to hide your identity.

gurkendoktor 11y ago
But I wish anonymity was the default, not something I have to enable as a special case... :(

rtz12 11y ago

We tried to use that to find your GitHub username, but we couldn't :( maybe you don't even have GitHub ssh keys, do you? You just need to properly configure your SSH.

hamandcheese 11y ago

Go has a great SSH library from what I can tell. I'm currently working on a project that is based around SSH, and Go seemed to be the only real option.

gcb0 11y ago

tl;dr: 1. ssh sends the pubkey you use on github ^1 2. his server compare with the publicly ^2 available pub key you uploaded to github.com ^1 (not mine, i set keys per domain) ^2 news to me!

sarciszewski 11y ago

It just closes my connection. root@paragonie:~# ssh whoami.filippo.io Connection to whoami.filippo.io closed. I'm not sure what I'm supposed to be seeing.

bmohlenhoff 11y ago
...presumably it doesn't allow root logins via SSH
- sarciszewski 11y ago
  Oh, duh, username!
  - woof 11y ago
    Why on earth are you logged in as root? man sudo
    - uniformlyrandom 11y ago
      sometimes you just sudo -s
      - lottin 11y ago
        I prefer su -
        uniformlyrandom 11y ago
        You need a root password for that one.
    - sarciszewski 11y ago
      Virtual machine :P
- bonif 11y ago
  Same for me with non-root user iMac:~ bonf$ ssh whoami.filippo.io Connection to whoami.filippo.io closed.

parshimers 11y ago

That's actually super handy. Next time I have to add someone to a shell account, I'll probably just look them up on GitHub first to find their public key instead of asking.

beagle3 11y ago
... thereby making any successful manipulation of the github key database (by the github people or by an attacker, as has happened before - google e.g. http://egorhomakov.com/ http://egorhomakov.com/ ) a successful penetration of YOUR system. Security and convenience unfortunately conflict often.

derefr 11y ago

It occurs to me that you could use this same mechanism to reduce the configuration load on machines that provision users using cloud-init(8). Right now, cloud-init accepts a list of GitHub usernames that should be allowed to log into the machine (which is pretty clever in-and-of-itself), and then creates users for them and sets their authorized_keys to whatever values the GitHub public-SSH-key API returns. But, rather than "burning in" a set of allowed users, you could do something much more interesting: allow any key to authenticate, and then map it back to a user and find out if that user has write-access to the GitHub project!

eru 11y ago
It will probably work. But it seems like you are increasing the attack surface here: the current method gets the list of keys once, and if github isn't compromised at that very instant in time, you are safe. Your proposed method relies on trust in github at all times.

rdl 11y ago

I use different keypairs for different trust domains. (also makes it easier to hand over access when you quit a job.) SSH keys are actually pretty horrible from a security perspective; no expiration, generally held in software, etc. And without a lot of work, single-factor. I love the ssh security model of being pretty good and better than telnet for everything (which it ~fully displaced, unlike https vs. http), but client keys are one of the weak points.

eru 11y ago
> And without a lot of work, single-factor. Wouldn't a passphrase be a second factor? By the way, we use a security fob at work for that. Seems to work fairly well. The private key never leaves the fob, you have to press a button to sign anything, and every once in a while you have to enter your passphrase.
- rdl 11y ago
  passphrase is set/unset locally and not communicated to the server if it is present/used/etc. Could be disabled. along with various other things. HW token with ssh key inside is probably the best. The annoying thing is devices w/o USB. For iOS devices and android devices which support it it's probably better to just use the HW sec features. Something which did bt 4.0le and maybe had a single local LED and button would be better still.
  - eru 11y ago
    > The annoying thing is devices w/o USB. Some new tokens use NFC.
    - rdl 11y ago
      Yeah, but sadly closed iOS sometimes oddly security hostile ecosystem bullshit. Bluetooth would be vastly better for interop.
- ersii 11y ago
  What hardware token (security fob) are you guys using? And is it working well?

georgerobinson 11y ago

This is clever, and very sneaky! Let's say I downloaded every public key from GitHub to ~/.ssh. Would this identify me as everyone on GitHub, or just the owner of the first public key to match? Furthermore, I wonder how Go channels compare to libevent (more specifically, epoll/queue) for high-performance network software. Is there any previous work which compares the two?

ParadoxOryx 11y ago
Adding those public keys would not identify you as everyone, as you do not have all the matching private keys.
- georgerobinson 11y ago
  Someone else commented on here that: > 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) Therefore, even though I can't authenticate as Linus Torvalds, an SSH server can see me present his public key and hence, log that public key for future use, like sending a message? Is that not correct?

skarap 11y ago

Nice trick! Also - everybody should probably be aware that SSH zero-day isn't the only bad thing which can happen to you if you connect to a malicious SSH server. Your terminal emulator has a higher chance of being vulnerable (e.g. take a look here: https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/ https://www.proteansec.com/linux/blast-past-executing-code-t...) than openssh does. P.s. "(And written in Go!)" - the trick would still be very cool if it was written in C, JavaScript, PHP, COBOL or any other language (and it would be freaking awesome if written in brainfuck!).

vinceguidry 11y ago

I simply got a "Connection to whoami.filippo.io closed."

argc 11y ago
Same here...

dmytrish 11y ago

At first, I thought that this is pretty harmless, but now I suspect that there may be a way to exploit a dump of public keys tied to personal information: let's say that some powerful adversary (like NSA) uses some kind of rainbow tables to associate public keys with private. Having a lot of public keys, they are likely to know some private ones and identities behind them. This hypothesis requires some mathematical ground, though. It may be that probability of guessing a private key is still negligible.

craigds 11y ago
Not exactly a cryptography guy, but I don't think PKC quite works like that. Rainbow tables rely on people using the same password as each other. This happens a lot with passwords, but it's unlikely to happen with key pairs, assuming they're generated with proper CSPRNGs.
baby 11y ago
> rainbow tables There is no such thing in public key crypto. The only thing that comes close to it that I can think of is the problem where weak public parameters were hard coded in a library (Apache) and were used by many many many person. Look at the logjam paper.

ambicapter 11y ago

Doesn't work on OS X 10.10.4?

scintill76 11y ago

Ooh goodie, we get to re-open the argument about whether it was bad of GitHub to publish the public keys![1] Pick your talking points: "They're called public for a reason.", "This could enable identity tracking.", "If your security model prefers public keys to be kept secret, it's absurd -- security by obscurity.", "This could enable factoring weak keys.", "This is good for security research.", "It's wrong to reveal metadata without consent, even if it doesn't break the crypto." You could build in another PoC by doing the trick where you hide a command inside the copy-paste version of the ssh command line you gave.[2] [1] https://news.ycombinator.com/item?id=9645703 https://news.ycombinator.com/item?id=9645703 [2] https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste

therealmarv 11y ago

After the question of adding this server to known hosts OS X asked me for the passoword of my private key. Is this normal? Of course I refused and got the message like displayed in other comments.

barkingcat 11y ago

Isn't this just ssh functioning as usual? You can specify which public key ssh should use by updating .ssh/config Otherwise, what's the harm in other people knowing your public key?

taejo 11y ago
Yes, but it's also ssh functioning in a way people don't know about.

enaasen 11y ago

Ok, as a total noob, what does this this suppose to demonstrate?

digital-rubber 11y ago
That if you have your public key on github and you ssh to a random machine, you leak information that can be correlated with github data, and if you filled in your details nicely at github, he can fetch your 'real name' based on the ssh announced key upon connect. This is a stupid post, more critical would be why the fop people host shit at github in the first place. Talking to _you_ paid subscription people with 'private' projects. If you can't even store your own data, why people even create it.

rhinoceraptor 11y ago

Interesting, it didn't work for me because I use a Yubikey Neo with PKCS11 for my SSH keys.

uniformlyrandom 11y ago

Luckily, putty/kitty does not send anything to unknown hosts. Good try though. Please accept a record of my IP address connecting to your honeypot as a token of gratitude.

eru 11y ago
The standard linux ssh client also asks for confirmation before sending anything interesting to a new server.

drinchev 11y ago

I don't see what's wrong with that.

ultramancool 11y ago

I brought this attack up on reddit 3 years ago. http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers_your_public_keys_to_all_servers/ http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers... Glad to see someone implemented an attack and can demonstrate it well now. Cheers Filippo.

baby 11y ago
"attack"
- eru 11y ago
  It's an attack on privacy expectations. There are at least two ways to escalate from here: - One if agent forwarding is enabled. - Another: learning details like people's names is often a first step in social engineering.
  - ultramancool 11y ago
    There's also another leak which isn't really shown here and that leak is that, with just a public key, you can offer to servers and they'll tell you if it's present or not. Using this you could scan the internet (given 6-12 hours and a shitty VPS that you can throw away this is quite possible) for someone's public key to find all of their servers, which could lead to a bypass of DDoS protection, identification of a Tor hidden service, etc.
    - versteegen 11y ago
      Yep, see also Rachelbythebay's comment in this thread (in particular the second post she links to); this is definitely exploitable. https://news.ycombinator.com/item?id=10008012 https://news.ycombinator.com/item?id=10008012
  - baby 11y ago
    > It's an attack on privacy expectations. It's a misunderstanding of the word "public"

GauntletWizard 11y ago

The last time this came up, I wrote a little script to update your authorized_keys file with your github keys. https://github.com/GauntletWizard/pamgithub https://github.com/GauntletWizard/pamgithub

petrsnd 11y ago

There may be some people concerned with GitHub publishing their identity to everyone, but it is pretty easy to use a separate key for GitHub (they'll even generate it for you) if you configure your ssh client appropriately with Host sections. Also, the same technique works if you want to use two different accounts on GitHub (one for work & one for personal). http://stackoverflow.com/questions/19310368/using-two-ssh-keys-with-github-along-with-connection-multiplexing http://stackoverflow.com/questions/19310368/using-two-ssh-ke...

ernsheong 11y ago

"Public keys" are supposed to be public anyway, isn't that what it's designed for? I see no harm

userbinator 11y ago
Using the same public key on two sites is like using the same username - something that you would do only if you want your identity linked between those sites. It's also a much stronger proof of identity than having the same username, because that's what they were designed for.
- baby 11y ago
  So don't use the same public key on two different site
gojomo 11y ago
Not necessarily. The "public" in "public key" is not an announcement of intended global availability, but rather role in contrast to "private key". There are many reasons people or systems might want to keep "public keys" obscured or pseudonymous. Still, many probably don't mind the public disclosure of Github account public keys. But, the more serious issue here goes beyond that. In an unexpected and likely unintended way, one's Github identity is revealed to a third party, along with your origin IP and quite possibly other SSH keys used with other systems. It's that set of mappings – IP <-> Github identity <-> other identities – that violates expectations.

robryk 11y ago

It seems that I get no output because I have an SSH certificate: robryk@sharya-rana ~> ssh -v whoami.filippo.io <...> debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/robryk/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering RSA-CERT public key: /home/robryk/.ssh/id_rsa Connection closed by 178.32.139.168

cmdrfred 11y ago

Just kicked me off after I accepted it's fingerprint, maybe it's down? I have a 8192 bit RSA key.

rachelbythebay 11y ago

Hey, cool, someone did part one with the GitHub public keys. http://rachelbythebay.com/w/2013/04/07/ssh/ http://rachelbythebay.com/w/2013/04/07/ssh/ Now, someone, do part two. http://rachelbythebay.com/w/2013/07/20/ssh/ http://rachelbythebay.com/w/2013/07/20/ssh/

INTPenis 11y ago
Wow after both of those blog posts, TWO years ago, I'm surprised github hasn't stopped exposing this identity information and us HN users haven't started being more paranoid about our ssh_configs.
- nindalf 11y ago
  Public keys are meant to be public, so is it a problem if everyone knows your public key? How often do you want to SSH into a remote server while wanting to remain private? And supposing you really want to, can't you maintain separate keys for separate hosts as other commenters have suggested? Perhaps I'm missing something here.
- misterjinx 11y ago
  why would they? after all they are public keys, they are supposed to be public. if you really are afraid of github exposing your public key, I think you can always create a separate pair to use only with github.
  - eru 11y ago
    And in some sense github is doing as a favour, by partially solving the key distribution problem. If you send me your public key via email, I don't know whether you are who you claim you are. If I get your public key via github, at least I know that you are the person contributing to all those open source projects.

username 11y ago

Wow, thanks for demonstrating this. A dead simple technique like this could have compromised me when trying to use SSH pseudonymously.

INTPenis 11y ago

I see most people acting like this was obvious but I gotta believe that a clear majority of ssh users had no idea about this. Yet it's extremely obvious when you think about it. This, this is true hacking. This is so elegant. I love you Filippo. Keep being awesome!

senthilnayagam 11y ago

like google analytics cookies track your every activity on every website, sending public keys feel the same way. now I have to re-evaluate my ssh usage after discovering ssh sends all my public keys. need to setup per server identities, without too much usage hassle . hope github will stop publishing public keys.

hitlin37 11y ago

i know what you did last summer on my server, would have been better title.

emmelaich 11y ago

Didn't work for me because I use a separate key for each "class" of machines, where class is github, bitbucket, work, home, ... You can reduce the maintenance load by using the %h (remote hostname) and %r (remote username) substitutions in IdentityFile. I make a symlink from the key I want to e.g. id-rsa-<remoteuser>@<remotehostname>.key and use IdentitiesOnly. See 'man ssh_config' Use %u (local user) and %l (local hostname) for extra control. It doesn't have %p (port) but the Host parameter in future versions of openssh will let you match on that too.

sengork 11y ago

From http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html http://www.cisco.com/web/about/ac123/ac147/archived_issues/i... "publickey: The details of this method depend on the public-key algorithm chosen. In essence, the client sends a message to the server that contains the client's public key, with the message signed by the client's private key. When the server receives this message, it checks to see whether the supplied key is acceptable for authentication and, if so, it checks to see whether the signature is correct."

olorundaglory 11y ago

VEHICLES FOR SALE AT AFFORDABLE PRICES AND IN GOOD CONDITION, CALL OFFICER custom glory 08067834923

anilshanbhag 11y ago

I first thought this was something new but wait he just gets public ssh keys. It is public for a reason, meaning anyone can have it and they are frankly useless. Can't find any comment below saying why this is dangerous ?

jakeogh 11y ago

I wish there was a way to have ssh automatically ssh-add keys you use... with a expiration date. I've tried to get this to work a few times, but I use a unique key for every login, so I need something to parse ~/.ssh/config to find the right Host def and ssh-add it. The code is obviously in ssh, but it's not exposed to the command line as far as I can tell.

digital-rubber 11y ago

So… the fact ssh leaks some information you find more worrying then people storing their source code at github? interesting...

fasteo 11y ago

No sure if I am missing something here, but that's the idea behind PKI infrastructure: You can share your public keys without putting your identity at risk. The "server knows who you are" or rather, I "tell the server who I am" Interesting experiment though.

RoryH 11y ago

Eh, I only forward my github ssh key to the host github.com so you don't know who I am ;-)

131hn 11y ago

I dont want to "play" with ssh_config file. My concern here is how pageant/ssh-agent behave, i think i'll try to fix/find a way around that (e.g. attended calls to agent signing api / configurable calls to agent keys listing). I think i'll drive a node-webkit/systray project being an alternative to pageant (#nwagent on freenode)

kragen 11y ago

I’d noticed before that ssh was rather aggressive about offering public keys to servers, but I didn't know Github published my public keys, and so this totally surprised me.

ausjke 11y ago

so what does this imply, security wise? Isn't public key a give-away anyways? which is what public means? Or I'm going to ssh-keygen a new one once a while.

Wisqnet 11y ago

Cripes, people. WHO CARES? So I SSHed in. I got the message. Then I saw all the people freaking out here and couldn't believe my eyes. Ask yourself this: How often do you SSH in to arbitrary hosts? Ones that you don't control, or work for, or trust with your source code? Did you really expect that you could give the same long unique base64 string to a bunch of different hosts and NOT have them connect your identity between them? Do you not understand that the whole point of public keys is to uniquely and reliably identify yourself to an arbitrarily large number of parties? Honestly, the only real eye-opener here is that Github gives out your public keys and can be scraped to collect all of them. But some of us have been using that functionality to share / snag each other's public keys for a long time now anyway.