Comment by problems | Hacker News Reader

Comment by problems | Hacker News Reader

Parent Full thread

I wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party.

The only bad thing about the GitHub issue there is that a de-anonymization attack is possible as an SSH server will tell you if it accepts a given public key... if, say you had the same SSH key on your GitHub account and a server you wanted to keep private, this could be bad to say the least. And SSH clients offer every id_* key to every server they connect to, so if you connect to an untrustworthy server, even over an anonymity network like Tor your client may offer a key that identifies you (use your ssh config!).

If I remember, SSH server don't share the public key it accepts. Your SSH agent will try all your key one by one (you can change this behaviour with custom config)

Yes, but similarly if you have a given public key you can ask a server if it accepts that key with no need for the private key.

Basically, don't reuse keys in places where you might not want to be identified and use ssh configs to prevent announcing all keys to the world.

?"The only bad thing about the GitHub issue there is that a de-anonymization attack is possible as an SSH server will tell you if it accepts a given public key"

Could you elaborate more on this specific attack?

A quick overview of how SSH key authentication works:

> SSH client: I support key auth

> SSH server: Let's use key auth

> SSH client: Do you take this public key hash: XXXXXX?

> SSH server: Yes I do

or

> SSH server: No I don't

Repeat for as many keys as you like.

You can therefore grab a list of known public keys for a given person and ask a given ssh server if it knows about the given public key. Given a few days you could even scan the entire IPv4 space for servers taking a given public key. Username must match, etc of course, but it's an attack many people might not consider.

Expanding this to the tor case that the GGP outlined, even if the server isn't compromised the use of the same key in two very different contexts (for git and for your silkroad command console) reveals that the client is one and the same. I believe just packet sniffing can ascertain this.

Sure, you would still need a Linux userid on that host (I'm assuming that PermitRootLogin is set to No.) Although that's probably easy to guess considering a person's name is often available in from Github or even the default comment field that ssh-keygen adds.

Reply on news.ycombinator.com