Live data from Hacker News

Show HN: My SSH server knows who you are

blog.filippo.io

241–250 of 257 posts

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

#241

Earlier quoted context omitted.

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

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.

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

#242
post #233

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

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

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

#243

Earlier quoted context omitted.

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/w…

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.

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

#244
post #241

Earlier quoted context omitted.

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.

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

#245
post #59

Earlier quoted context omitted.

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

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

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

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

#249
post #241

Earlier quoted context omitted.

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.

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

#250
post #233

Earlier quoted context omitted.

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

Post reply on HN