Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

migrated from serverfault.com Dec 27 '13 at 0:10

This question came from our site for system and network administrators.

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 1: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 2 at 17:39

3 Answers 3

up vote 39 down vote accepted

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

share|improve this answer
    
Another good argument in favor of using symmetric keys rather than a password for SSH connections. –  Shadur Dec 27 '13 at 8:53
6  
@Shadur: You mean "asymmetric keys", don't you? –  DarkWanderer Dec 27 '13 at 13:28
    
Argh, yes. In my defense, it was early. >_> –  Shadur Dec 27 '13 at 15:25

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.

share|improve this answer
    
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 3 at 0:12
    
Since you said the server is at your office, why not just copy your public key onto it via sneakernet? –  sampablokuper Jan 3 at 5:04

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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