41

A few minutes ago I attempted to ssh to a server I have at my office. Since it is a new server my public key has not been set up there so I had to type my password in manually.

After three times of trying to log in unsuccessfully I notice that I had typed the domain name wrong -- two characters transposed. The server I had actually been trying to log into was not at my office but somewhere else!

My question: does the SSH protocol expose my password in such a situation? In other words if that server had be deliberately set up in some way to catch a mistake like this could it do it?

I am going to go change that password anyway but I would like to know if that accident is a real risk. Any insights welcome.

smokris
  • 199
  • 1
  • 2
  • 5
AlanObject
  • 525
  • 3
  • 8
  • 2
    ...which is reason #1749 to always use key authentication. If you'd done this, there would have been no information leakage of consequence. – EEAA Dec 27 '13 at 01:36
  • 2
    @EEAA Yes but how to I get my public key into the authorized_keys file before I log in for the first time? – AlanObject Dec 28 '13 at 18:33
  • Configuration Management. I'll add that this scenario is one of the reasons host keys exists and ssh checks the known hosts to ensure you're hitting the server you think you are. – Zeb Jan 02 '14 at 17:39

3 Answers3

41

Yes, the remote server will now have had access to your password. And if they've set it up to log that password (which is not the default in any SSH product I know), you should change your password even quicker than you are already doing :)

Dennis Kaarsemaker
  • 466
  • 5
  • 5
9

Yes. The packet containing your password is encrypted so that only the intended server can read the incoming password, however once the packet is processed your password is sitting there in the clear. The ssh client is not transmitting a hash of your password (I thought it was so I checked the source and found otherwise), it is your password whole.

Of course, no legit sshd would log passwords, but equally of course, no one should ever trust some random unknown server.

smokris
  • 199
  • 1
  • 2
  • 5
blah44
  • 141
  • 5
7

The relevant reference documentation is Section 8 of RFC 4252 - The Secure Shell (SSH) Authentication Protocol.

The pertinent parts of this say:

Password authentication uses the following packets. All
implementations SHOULD support password authentication.

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "password"
  boolean   FALSE
  string    plaintext password in ISO-10646 UTF-8 encoding [RFC3629]

Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer.

So, as other people here have observed: the good news is that anyone eavesdropping on the exchange shouldn't have seen the plaintext of your password; the bad news is that you have by your actions disclosed your password to the SSH server you tried to log in to, and you would be well advised to change that password. Better still, use public key authentication instead.

Community
  • 1
sampablokuper
  • 2,071
  • 1
  • 21
  • 33
  • Thanks for looking up the specification for me. Had I read it before I would have known the answer to the question. However I have to use a password to get access so I can set up public key authentication -- getting my key into the authorized_hosts file. Unless you know of a way of doing that without using a password? – AlanObject Jan 03 '14 at 00:12
  • Since you said the server is at your office, why not just copy your public key onto it via sneakernet? – sampablokuper Jan 03 '14 at 05:04
  • 1
    Thanks for the real reason to use key instead of password. – Smit Johnth Dec 02 '16 at 19:08