Live data from Hacker News

Show HN: My SSH server knows who you are

blog.filippo.io

171–180 of 257 posts

Re: Show HN: My SSH server knows who you are

#172
post #52

Earlier quoted context omitted.

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

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.

Re: Show HN: My SSH server knows who you are

#173
post #26

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 i…

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.

Re: Show HN: My SSH server knows who you are

#174

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.

Re: Show HN: My SSH server knows who you are

#175

Earlier quoted context omitted.

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

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.

Re: Show HN: My SSH server knows who you are

#176

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 h…

I got the same.

Re: Show HN: My SSH server knows who you are

#177
post #166

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.

Re: Show HN: My SSH server knows who you are

#178
post #93

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, rathe…

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.

Re: Show HN: My SSH server knows who you are

#179

Earlier quoted context omitted.

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.

Re: Show HN: My SSH server knows who you are

#180

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

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.
Post reply on HN