Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My SSH server knows who you are

blog.filippo.io

Post reply on HN
Print view View original

231–240 of 257 posts

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

#231

Post by hamburglar »

javajosh wrote: post #204
JoshTriplett wrote: post #143

Earlier quoted context omitted.

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 "secur…

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.

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

#232

Post by digital-rubber »

enaasen wrote: post #125

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

That if you have your public key on github and you ssh to a random machine, you leak information that can be correlated with github data, and if you filled in your details nicely at github, he can fetch your 'real name' based on the ssh announced key upon connect.

This is a stupid post, more critical would be why the fop people host shit at github in the first place. Talking to _you_ paid subscription people with 'private' projects.

If you can't even store your own data, why people even create it.

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

#233

Post by dlitz »

chrisfosterelli wrote: post #30

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?

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

#234

Post by [deleted] »

microcolonel wrote: post #165
FiloSottile wrote: post #43

Earlier quoted context omitted.

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

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

[deleted]

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

#235

Post by bonzini »

FiloSottile wrote: post #43
acomjean wrote: post #14

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…

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

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.

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

#236

Post by egeozcan »

morganvachon wrote: post #133
NotHereNotThere wrote: post #122

Earlier quoted context omitted.

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

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

#237

Post by voyou »

eridius wrote: post #172
gmalette wrote: post #67

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

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

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

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

#238

Post by micaeked »

javajosh wrote: post #204
JoshTriplett wrote: post #143

Earlier quoted context omitted.

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 "secur…

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.

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

#239

Post by beagle3 »

throwaway2048 wrote: post #208
javajosh wrote: post #204

Earlier quoted context omitted.

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 "secur…

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

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

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

#240

Post by gmalette »

eridius wrote: post #215
gmalette wrote: post #193

Earlier quoted context omitted.

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

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

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

Post reply on HN