
Show HN: My SSH server knows who you are - FiloSottile
https://blog.filippo.io/ssh-whoami-filippo-io/
======
chrisfosterelli
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!

~~~
FiloSottile
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/ssh...](https://github.com/FiloSottile/whosthere/blob/master/src/ssherver/server.go)

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

~~~
JoshTriplett
> (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...](https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type=Code&ref=searchresults)

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

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

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

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

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

~~~
creshal
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

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

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

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

~~~
creshal
> 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".

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

~~~
FiloSottile
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](https://github.com/FiloSottile/whosthere#how-it-works)

~~~
rmetzler
\- The key might be to new for the dataset.

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

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

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

~~~
kazinator
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
But I wouldn't get access to all these "DevOps-style" startups backends... Oh.
Oh, I shouldn't have said that.

;)

------
skarap
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...](https://www.proteansec.com/linux/blast-past-executing-code-
terminal-emulators-via-escape-sequences/)) 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!).

------
ultramancool
I brought this attack up on reddit 3 years ago.

[http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers...](http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers_your_public_keys_to_all_servers/)

Glad to see someone implemented an attack and can demonstrate it well now.

Cheers Filippo.

~~~
baby
"attack"

~~~
eru
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
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
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)

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

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

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

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

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

~~~
shanemhansen
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
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_
You don't happen to have recordings of it, by chance?

~~~
kaybe
No, sadly. It was a long time ago.

------
tacone
> 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
> 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
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...](https://medium.com/@gmalette/mistaking-authentication-for-
identification-983447739eee)

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

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

~~~
eridius
> _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.

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

~~~
eridius
> _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.

------
petrsnd
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...](http://stackoverflow.com/questions/19310368/using-two-ssh-keys-with-
github-along-with-connection-multiplexing)

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

Nicely presented, Filippo!

~~~
roozbeh18
surprise to me. added

IdentitiesOnly yes

to my config file.

------
yesco
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
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
It's fairly pointless of github to publish your public key though. Nobody can
trust that it's actually yours.

~~~
the8472
> 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
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)

------
arturhoo
Nice idea, but __don 't __run the command if you have

    
    
        Host *
          ForwardAgent yes
    

On your ~/.ssh/config

~~~
chmike
What is the effect of ForwardAgent ?

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

~~~
lcswi
_public_ keys I hope?!

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

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

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

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

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

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

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

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

------
sarciszewski
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
...presumably it doesn't allow root logins via SSH

~~~
sarciszewski
Oh, duh, username!

~~~
woof
Why on _earth_ are you logged in as root? man sudo

~~~
uniformlyrandom
sometimes you just sudo -s

~~~
lottin
I prefer su -

~~~
uniformlyrandom
You need a root password for that one.

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

------
dadrian
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
But I wish anonymity was the default, not something I have to enable as a
special case... :(

------
rdl
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
> 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
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
> The annoying thing is devices w/o USB.

Some new tokens use NFC.

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

Bluetooth would be vastly better for interop.

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

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

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

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

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

~~~
justizin
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
Or simply to DOS you out of your other accounts.
[https://news.ycombinator.com/item?id=10005358](https://news.ycombinator.com/item?id=10005358)

------
ambrop7
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
The server only gets the key after it has been identified; you can see that by
using "ssh -v".

------
sengork
From
[http://www.cisco.com/web/about/ac123/ac147/archived_issues/i...](http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html)

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

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

------
barkingcat
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
Yes, but it's also ssh functioning in a way people don't know about.

------
uniformlyrandom
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
The standard linux ssh client also asks for confirmation before sending
anything interesting to a new server.

------
omarforgotpwd
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
This would make this repos not open source, unless they are replicated
elsewhere as well.

------
jonathonf

      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
Same. Apparently this server does not support any modern day crypto.

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

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

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

------
georgerobinson
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
Adding those public keys would not identify you as everyone, as you do not
have all the matching private keys.

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

------
131hn
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)

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

~~~
userbinator
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
So don't use the same public key on two different site

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

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

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

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

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

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

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

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

------
rtz12

        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.

------
samps
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
Just keep in mind that you're now at the mercy of github. Or whomever pwns
their servers.

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

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

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

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

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

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

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

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

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

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

~~~
argc
Same here...

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

------
ambicapter
Doesn't work on OS X 10.10.4?

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

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

------
swah
I use putty, this failed.

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

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

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

~~~
egeozcan
There is a setting for it:

[http://i.imgur.com/6G3NxvJ.png](http://i.imgur.com/6G3NxvJ.png)

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

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

