SSH Security – Does SSH Send Password Over the Network?

authenticationopensshpasswordsshssh-tunneling

Basically the entire question is in the headline: Does ssh send the password over the network? Presuming of course that login via username and password is used.

I'm asking because if ssh doesn't send the password over the network, a man in the middle can't get the user's password even if the user adds the alleged host to their known_hosts file.

Someone said it has to, so I wrote down a counter example in a comment. Since the question of how else it could possibly work now came up repeatedly, I'm copying that comment here.

The server can tell the client which hash to use. [The same one which is used to hash the passwords in the server's shadow file.] The client can then calculate the hash ψ which should be in the server's shadow file but let's call the one on the server ψ'. So both the server and the client know ψ. The client can then pick a random salt σ an send (hash(ψ.σ), σ) (where . is the concatenation operator) to the server. The server then hashes ψ'.σ and checks whether the first element of the tuple it received from the client matches that hash. If it does, the client knows the password.

Best Answer

If you're using password authentication, then SSH sends the password over the network. The connection is encrypted, so eavesdroppers can't see the password. The connection is authenticated, provided that you don't click blindly through a “The authenticity of … can't be established” message, so your password won't be sent to anyone except the legitimate server.

The boring answer to “why” is that this is what the SSH protocol requires.

The less boring answer is that password authentication has to work that way. There are ways to perform authentication that don't work this way but this is no longer simple password authentication.

Most authentication protocols that are more advanced than simple password authentication have the nice property that the client doesn't send any secret data to the server that a malicious server could use to impersonate the user on some third server. With SSH public key authentication, the most common SSH authentication method other than passwords, this works because the client sends a signature (requiring the private key) of data that includes the session identifier; if the malicious server tried to authenticate to a third server, it would have to generate a signature of data including a different session identifier, which it would be unable to do without the private key that stays on the client.

Note that if you use public key authentication, and you have to type a password to use the key, this is not password-based authentication. The password to use the key is used exclusively on the client side, to read the key from the key file. When using public key authentication, the server does not know or care whether the key was stored in an encrypted file.

Password authentication requires sending the password to the server. Sending a hash of the password instead of the password itself does not help, because then the password becomes the hash: an attacker wouldn't need to find the actual password, only the hash. An attacker could attack by finding the actual password, so there is no improvement. But if the attacker found the hash but not the password, in your proposed scheme, that would be enough. In contrast, with normal password-based authentication, the attacker must know the password, knowing the hash is not good enough, and if the password is strong enough then the attacker won't be able to find the password from the hash. In practice, the reason the attacker might know the hash but not the password is that the attacker managed to extract the database of password hashes from the server, possibly from an unprotected backup or via a vulnerability on the server. Such vulnerabilities on websites make the news pretty often.

Your proposed protocol is less good than the standard one. Don't roll your own crypto!

Related Question