Show HN: My SSH server knows who you are | Hacker News Reader

Show HN: My SSH server knows who you are

blog.filippo.io

836 pointsFiloSottile245 comments

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!

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

[1] https://github.com/FiloSottile/whosthere

[2] https://github.com/FiloSottile/whosthere/blob/master/src/ssh...

[3] https://news.ycombinator.com/item?id=10005169

This might be more obvious than I thought, but could you explain how you scraped all of GitHub keys throughout the entire user-base?

There 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

It'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_age...

The public keys should be ok. But the comment on them may be a problem.

The comment isn't sent to the server during the authentication

> (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...

> EDIT: Check out this search: 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?

I 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.

For 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.

I 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.

Well, what you describe (pretty much) is the "agent", and many people do, in fact, find it "quite handy" ;P. (I do not use this feature, myself.)

The SSH agent maintains your private keys and provides the necessary responses to ssh when it wants to authenticate to a server. If you ssh to a server and forward your SSH agent, that server can then run ssh themselves and impersonate you to a different remote server, and your SSH agent will supply the necessary authentication information.

Or, in short: never use ForwardAgent (or ssh -A) to a server you don't trust.

The remote ssh process asks your host to unencrypt it's traffic? Your process takes an encrypted stream, sends the plaintext, and your keys never leave your machine. That's...incredibly clever, although I can only think of one scenario where it would be necessary (navigating securely through a sequence of ssh sessions where some of the secondary hosts are inaccessible from your originating host. E.g. a kind of "secure trojan horse".

Sometimes I feel just so awed at the ingenuity of people, especially with software and computers.

its very useful for so called "Bastion Hosts", an SSH server that allows further access into the network and is totally locked down.

This is what I do for my home network. I hadn't realised it had a name (though not at all surprised)

You don't need agent forwarding for that. Just use ssh's dumb tcp forwarding and keep your agent on your local host.

Ex.:

    Host bastion.company
    	ProxyCommand none

    Host *.company
    	ProxyCommand ssh -W %h:%p bastion.company

Because enabling tcp forwarding is so much more safe on a jump box? That's just asking for another pile of unauditable trouble.

Safer than dumping all your private keys onto the jump box and using that to validate the final target? Why yes. This way, your local ssh client validates the final target public key, not the jump box.

The whole point of agent forwarding is that you don't have to place your keys on the jump box. With -c for per use confirmation it seems much more secure.

> The whole point of agent forwarding is that you don't have to place your keys on the jump box.

A socket that allows dumping the keys isn't really an improvement. If the box is compromised, agent forwarding can still be abused.

> seems much more secure.

Emphasis on "seems".

I know it as a "jump host" or "jump box". Regardless, it's still not a good idea to have agent forwarding - what about the boxes you forward to? Do you trust them not to abuse the forwarding trust (Is there a way to limit forwarding trust to just one machine?)

Also, I used to add every jump combination into my .ssh/config file, but came across a wonderful trick that makes it unnecessary: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...

Not exactly. The remote host, which you have forwarded your agent to, tries to log onto your production host using your public key, and when the production host sends it a signing challenge to prove it has the authority of your private key, it can simply ask your ssh agent to do that signing. Once that is complete, you are logged in and the session has a session key that has nothing to do with your pub/private keys. The ssh agent does not do decryption, it just gets the session started.

Another example is if I want to transfer something from server A to server B, without it going through my shitty little pipe, and without storing the private key on either server.

I also use the -c (confirm) flag with ssh-add. I don't forward the agent willy-nilly, but if someone still manages to compromise the agent, I will hopefully know when I'm getting confirmation popups I didn't initiate.

I wish gnome-keyring's integrated ssh agent supported that.

It's been awhile since I set it up, but I believe I've disabled gnome-keyring's agent[1], use the OpenSSH one instead, use ssh-askpass-keyring[2] as the SSH_ASKPASS environment variable to ssh-add to read key passphrases from the keyring (manually invoked via a shell script helper; but only needs to be done once per login session), and GNOME's gnome-ssh-askpass installed as the system default, for key confirmations.

(This is on the Cinnamon desktop, so other GNOME setups could be different.)

[1] See https://askubuntu.com/questions/63407/where-are-startup-comm... for how to override in your user dir, or find it in the GUI somewhere. [2] https://launchpad.net/ssh-askpass-keyring is the Ubuntu page

I know how to override it, but I prefer all the other behavior of gnome-keyring's agent. -c is literally the only feature I want that it doesn't have.

There's something I found on hacker news awhile back that can allow you to use ForwardAgent while limiting your identities so that you can forward your ssh agent, but it only forwards the identity you used to connect to that server. It starts up a separate agent for each identity when you invoke it.

You can find it at: https://github.com/ccontavalli/ssh-ident

Thanks for the tip. I use ForwardAgent for all my servers at work, but I had it defined in a "Host *" block. I've now setup separate blocks for my work domains and have moved ForwardAgent into there alone. Never knew it was a risk until this thread.

And now I've rotated my keys and fixed my ssh config file. Thanks :-)

why rotate them? They're just public keys anyways. Useless on their own.

Note 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

Thanks for the link, adding a warning for that, too.

Thanks 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 ;-)

Is 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?

You 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.

Untested 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

This only worked for me after I renamed id_rsa (and id_rsa.pub).

I never realized that SSH does this. Thank you.

This really need to be better known.

Thanks!

I 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.

Yeah, 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.

I 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!

> 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.

Yes, 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.

Double-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

Ah, 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.

Doesn'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.

You 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.

I do the same thing, plus I maintain a separate public/private key pair for every host where I need the pubkey auth.

> 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...

> 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?

It 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.

Exactly. 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.

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

Didn't work for me either. It seems like it fails more than it succeeds based on the results posted in this thread.

presumably, those for which it worked are less likely to post? FWIW, it worked for me.

That is true! I didn't think about that.

That's a very good thing to keep in mind when reading any complaints on the Internet and using them to gauge sentiment about a thing. Folks who are happy with a thing are far less likely to take the time to write up their experience than those who are unhappy.

and it worked for me too, just thought i'd chime in here. nice educational and simple project.

It's probably most apt to working when the local username is the same as the username in your SSH keys.

If your local username is something like "johndoe", while your server logins (and keys mapping to them) is "jdoe", it isn't likely to align the one to the other.

If your local and remote usernames tend to be the same, and they are also the same as your Github keys, then it's probably pretty likely to be accurate.

It's based exclusively on the public key. My local username and github login are unrelated, and it worked for me.

Hi! A few reasons it might fail:

* You don't have your SSH keys on GitHub

* You don't have your GitHub keys on that laptop

* Your key is not RSA (because I'm LAZY)

* Your ssh version uses only recent algorithms not supported by Go's x/crypto/ssh

* You actually disabled IdentityKeys

Nothing to do with usernames or heuristics, by the way. All it does is first enumerate your client keys, then let you in, then check a huge GitHub keys database, then ask the GitHub API for your name.

https://github.com/FiloSottile/whosthere#how-it-works

- The key might be to new for the dataset.

This was the case for me. The keys I'm using now I added this past weekend, and I get the "couldn't find you" message.

Whenever I push, I login. Apparently this laziness saved my ass this time. Of course, this could be used on any service I ssh into regularly and has a scrappable listing of users, so it's good of you to bring this up.

I'm using ed25519 with Github, figured it was just laziness. (also deliberately set it up to send that key because it wouldn't normally).

I had the same result, and was rather surprised. It's probably because I have a DSA key.

Aren't these published by github too?

It also does not work with keys from a smartcard (yubikey NEO). Here is the ssh log:

    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: cardno:000603010929
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Trying private key: /home/pbonzini/.ssh/id_rsa
    debug1: Trying private key: /home/pbonzini/.ssh/id_dsa
    debug1: Trying private key: /home/pbonzini/.ssh/id_ecdsa
    debug1: Trying private key: /home/pbonzini/.ssh/id_ed25519
    debug2: we did not send a packet, disable method
    debug1: No more authentication methods to try.

I got the same.

Just run "ssh-keygen -R whoami.filippo.io".

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.

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

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.

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

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.

But I wouldn't get access to all these "DevOps-style" startups backends... Oh. Oh, I shouldn't have said that.

;)

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-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!).

I brought this attack up on reddit 3 years ago.

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.

"attack"

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.

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.

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

> It's an attack on privacy expectations.

It's a misunderstanding of the word "public"

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!

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.

Hey, cool, someone did part one with the GitHub public keys.

http://rachelbythebay.com/w/2013/04/07/ssh/

Now, someone, do part two.

http://rachelbythebay.com/w/2013/07/20/ssh/

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.

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.

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.

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.

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!

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

There are probably some morons out there, but I'd be surprised if most automated ssh scanners were offering up a private/public keypair.

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!

You don't happen to have recordings of it, by chance?

No, sadly. It was a long time 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 :)

> 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.

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-id...

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.

A DOS is especially annoying, if the attacker needs to burn less resources than the defender.

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.

I'm not arguing they're not, but that they shouldn't be used as a means of identification

DOS is a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway.

> A simple solution would be to avoid the single user login git@service.com, and use that as identification, for example gmalette@service.com.

Except this completely ignores the reason why services use git@service.com. It's not because they're lazy. It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server), and removes the ability for people to copy&paste a `git clone` command from a README (or blog post or wherever else).

So yes, there is a theoretical annoyance attack here, but nobody really cares because it's never going to happen accidentally, it can't be used against most people, and it's so trivially bypassed nobody's going to bother doing it except as a PoC. The benefits of using git@service.com greatly outweigh the downsides.

> and it's easily solved by a small SSH config change on their end

The article does mention it. The issue is not fixing the problem, it's actually finding it.

> [...] that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server)

It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?

For Github et. al, that's easily solved by project-level or organization-level identity.

> that URL wouldn't work for anyone else

And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.

> nobody really cares because it's never going to happen accidentally

Except it does. Those service providers often get contacted because this happens BY ACCIDENT.

I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config.

A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.

I've heard similar stories elsewhere too.

> It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?

I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you.

> For Github et. al, that's easily solved by project-level or organization-level identity.

How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@.

> And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.

Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way.

> Those service providers often get contacted because this happens BY ACCIDENT.

Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this.

> A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.

Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.

> If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules

You're missing the point. You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo. You're not going to `git submodule add git@heroku.com:project`. So for the sake of argument, if we pretend that git repo hosts do need to use `git@`, I don't see a single reason why Heroku would.

> And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@

Now you're confusing two things. Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification. If you want commit access, why would project-level not work?

> Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn

Again, missing the point. If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.

> And no, your own anecdotes do not constitute proof that providers often have to deal with this.

If you're not going to believe anything I say, I got nothing. Otherwise, 2 things

- I opened an issue and the response was basically "Ooooo that explains some of those tickets". They specifically mentioned issues with vagrant. - I presented this at a local meetup and someone else had put themselves in this position.

> Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH?

No. As I said, it was meant to setup the vagrant box and then not be used. By default vagrant connects using an insecure keypair.

> You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo.

Ah, I see what you mean. But is that actually true? If you push a repo to Heroku, are you still expecting to host the canonical version of that repo elsewhere, instead of just using Heroku as the canonical version? Because if it's the latter, and you're working with other people, then it's still useful to have a single URL that identifies the repo.

> Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification.

But you're going over SSH, so you have to negotiate the connection before the server knows what action you're taking. So the SSH connection will be the same whether you're pushing or pulling. You can't negotiate different identities for pushing vs pulling, so whatever identity you settle on has to work for both.

> If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.

Ah, I see.

It sounds to me like using username@ is still completely useless regarding your proposed "attack", but does have some small utility for people who have multiple accounts. But I still think the obvious general utility of having a single URL that works for everyone is more important.

As an aside, it looks to me like you could try using the `Match` keyword in your ssh_config and have it run an external command that determines which account you should be using. This could be controlled with an environment var, or maybe it could look at $PWD. If you can come up with some suitable command, then you can use that to control which identity file to use.

> If you're not going to believe anything I say, I got nothing.

I believe your personal, anecdotes, but you can't just make a broad claim about providers with no evidence and expect me to believe that it really is as widespread an issue as you claim.

"It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else."

Couldn't the URL just not include a username, though? Then when git tries to establish an ssh connection, it could try the local username (like ssh does by default), or a username specified somewhere in a config file.

What server owner didn't know before you visited was which IP corresponded to your public key.

Tor exit ;)

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-ke...

If this surprises people, it's definitely doing some good.

Nicely presented, Filippo!

surprise to me. added

IdentitiesOnly yes

to my config file.

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?

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.

It's fairly pointless of github to publish your public key though. Nobody can trust that it's actually yours.

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?

> 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.

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

> 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.

Not only a different key-pair per server, but also per session.

No, in order to mess with your repo, an attacker would need your private key. Github only publishes public keys. For more information you can check out https://en.wikipedia.org/wiki/Public-key_cryptography

GitHub doesn't even have your private key.

Oh yea, duh. Thanks for clearing that up for me, I get the two mixed up a lot. (which is bad)

To make it easier. Your public key is something others would place on their servers to grant you access, and you'll need to have your private key to authenticate.

Nice idea, but don't run the command if you have

    Host *
      ForwardAgent yes

On your ~/.ssh/config

What is the effect of ForwardAgent ?

Forwarding your keys basically. It's like giving someone you don't know a handshake AND all your keys.

public keys I hope?!

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://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-cons...

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.

OMG! This was an important and helpful precision. Thank you very much.

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.

Yes, for more information, see SSH Agent Forwarding Considered Harmful (http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-cons...). Finally a legitimate use of the title "considered harmful".

Don't use agent forwarding to any host you don't have exclusive root access to and are 100% sure isn't compromised. Anyone else who is root on a box you SSH to with agent forwarding can authenticate to other servers using your private key while you are connected.

Is this a problem if my private key is on a smartcard and I have to press a button on the card to sign something?

Slightly less so. But they can still trick you into signing something different than what you'd expect.

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 [2] https://thejh.net/misc/website-terminal-copy-paste

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.

Yes.

And all of my machines are named "host", with user "user" :)

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

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.

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.

... 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/ ) a successful penetration of YOUR system.

Security and convenience unfortunately conflict often.

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.

...presumably it doesn't allow root logins via SSH

Oh, duh, username!

Why on earth are you logged in as root? man sudo

sometimes you just sudo -s

I prefer su -

You need a root password for that one.

Virtual machine :P

Same for me with non-root user

iMac:~ bonf$ ssh whoami.filippo.io Connection to whoami.filippo.io closed.

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

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.

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

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.

> 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.

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.

> The annoying thing is devices w/o USB.

Some new tokens use NFC.

Yeah, but sadly closed iOS sometimes oddly security hostile ecosystem bullshit.

Bluetooth would be vastly better for interop.

What hardware token (security fob) are you guys using? And is it working well?

It's called gnubby internally. There's some public information at https://sites.google.com/site/oauthgoog/gnubby

There are supplied by yubico and look like the ones at https://www.yubico.com/applications/fido/ . I am not sure how much we hacked them up internally, if at all.

The newer small ones work really well. You just leave them permanently in a USB port. Every once in a while you have to enter your passphrase to keep them activated (eg reboot), normally you only need to touch them to sign / log-in. The requirement for touching comes from the fob itself, and can't be overridden by our computer.

For most operations you only need your gnubby. For some more sensitive ones, we require password + gnubby touch. (You are allowed to reuse your password as the gnubby activation password.)

At first I thought that leaving the gnubby permanently in the PC would weaken security, but essentially it just means that your PC (including gnubby) is your second factor.

You can have more than one gnubby. We recommend one per computer you are using. We allow falling back to the Google Authenticator app on your phone. (It's less convenient, and potentially phishable, but otherwise secure enough.)

The earlier fobs were technically usb keyboards and were just outputting a six digit string when touched (equivalent in security to the app). The new fobs do a little cryptographic dance with the website, and are thus more secure.

From my user's point of view, it's working very well. It saves me typing my password every two minutes. And the security guys assure me it's more secure, too.

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 - but with users automatically unique and identified by GitHub.

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

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

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.

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?

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.

They're public keys, they're intended to be public. What are you trying to hide by hiding your public key?

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.

Or simply to DOS you out of your other accounts. https://news.ycombinator.com/item?id=10005358

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.

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.

The server only gets the key after it has been identified; you can see that by using "ssh -v".

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.

From 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."

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.

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?

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

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.

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

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.

This would make this repos not open source, unless they are replicated elsewhere as well.

Until someone forks it

  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.

Same. Apparently this server does not support any modern day crypto.

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.

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

no. you should use an ssh key w/ password. more secure and easier. your public key is designed to be public.

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.

SSH with a keypair should be much more secure than user/pass over TLS.

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?

Adding those public keys would not identify you as everyone, as you do not have all the matching private keys.

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?

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)

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

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.

So don't use the same public key on two different site

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.

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.

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

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

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.

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 ?

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

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)                  |
        |                                                                     |
        +---------------------------------------------------------------------+

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.

ssh: Connection to root@whoami.filippo.io:22 exited: Remote closed the connection

That's what happens to me from OpenWrt

Go figure, root.

root because that's the user I use to log into OpenWrt. But it's the same if I change it.

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.

    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.

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.

Just keep in mind that you're now at the mercy of github. Or whomever pwns their servers.

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.)

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.

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.

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

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.

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.

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.

> 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.

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

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

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

Same here...

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.

Doesn't work on OS X 10.10.4?

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

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

I use putty, this failed.

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.

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.

Worked fine on my PuTTY, got the message after leaving an empty user at the "login as:" prompt

Interesting. When I tried it at work earlier (Windows 7, latest PuTTY) it closed out the window without showing anything. I just tried it at home (Windows 10, latest PuTTY) and it worked as you said.

There is a setting for it:

http://i.imgur.com/6G3NxvJ.png

Right there in front of me. Now I'm wondering when and why I changed that behavior at home (I'm assuming the "Only on clean exit" setting is the default).

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!

Reply on news.ycombinator.com