0

Please forgive my terminology mishaps.

Recently, I tried to connect to a server over SFTP. The SSH public key response differed by 1 byte to what I was expecting, from an info page.

I was tempted to go ahead and connect anyway, assuming it must be a typo. But I didn't, instead contacted the sysadmin. It turns out it was a typo, has been there since 'Heartbleed', and some how I'm the first to notice it.

If I had gone ahead and connected, what is the actual risk? I think I understand that I'm potentially connecting to an attacker's server instead of the one I intend to, but that raises two questions:

  1. Surely there is no connection to me, so the "only" risk is that I upload something or enter some credentials, thinking it is the correct sever, but that I would not want an attacker to have? That is, there is no risk to the personal files on my machine, and the risk is over when I disconnect from the server?

  2. The key is public. What stops an attacker using the correct public key for her own server, that I unwittingly connect to?

Or do I have it completely wrong?

0
  1. You're correct. The risk is what information you provide to the server, or on the server. The attacker could modify it's SSH client to inject some kind of malicious data in it's responses. However, it would have to conform to the SSH spec in order to be processed correctly by your SSH client, and then also do something malicious. Which in my opinion would be be non-trivial.
  2. Public and private keys are generated as a pair. As long as the key was generated with a cryptographically secure PRNG it will only have one private key paired with it.
  • Re: 2 - I understand that, but what I'm not clear on is that when I attempt to connect, all I see is a public key. What this should be is listed on a public web page. Why can't an attacker make me see this? Or does SSH spec require that it is presented by generation each time? How is this enforced - how do I know the server has generated it with an obviously correct private key, vs. being an attacker not generating it, and just presenting the correct key? – OJFord Sep 26 '14 at 18:39
  • Sadly with SSH there is no real server authentication. It's up to the user to trust the server. So it's up to you to trust the page that posts the public key. That said, an attacker would have to generate their own key, post it on the server in place of the server's public key. An attacker can present the correct key, but they should not have the private key to establish a connection. – RoraΖ Sep 26 '14 at 18:52
  • Why is the private key required to establish a connection though? All I did was (attempt to) connect to sftpserver.example.com, be told that the server's public key is x, and have the option of proceeding. Perhaps I don't understand because I don't understand how the attacker comes in the middle with his server in the first place :/ – OJFord Sep 26 '14 at 18:56
  • Private keys are used to sign data. The client then verifies this signature with the public key. In SSH I believe that the hash of the key exchange is signed with the private key. So if the client can not verify this signed data, the key exchange fails. – RoraΖ Sep 29 '14 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.