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?

1 Answer 1

  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, 2014 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, 2014 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, 2014 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, 2014 at 12:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .