Does ssh send the password over the network?

Question

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.

Solution 1

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!

Solution 2

Yes. The password is sent over the encrypted connection, but it's in plaintext to the remote server.

The usual way to authenticate is for the server to calculate a hash of the password and to compare it to a value saved on the server. There are several ways of saving hashes, and with current implementations, the client doesn't know what the server uses. (see e.g. the crypt man page). (Even if it did, simply sending a hash of the password would make the hash equivalent to the password anyway.)

Also, if the server uses PAM, the PAM modules might implement authentication with just about any method, some of which may require the password in plaintext.

Authentication using public keys doesn't send the key to the remote host, however. (Some explanation and links about this in a question on security.SE)

There are also password-based authentication algorithms like SRP, that don't require sending the password in plain text to the other end. Though SRP appears to be only implemented for OpenSSH as an external patch.

Solution 3

If you use a password based authentication scheme then, yes the password is passed over the network to the end point...

But it is an encrypted channel.

eg

% ssh remotehost
user@remotehost's password: 

bash$ logout

In this scenario the password was sent encrypted over the network.

This is why it is very important to handle known_hosts entries properly and pay a lot of attention if you see the @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ message! That is your defense against a MITM attack.

Solution 4

Yes, ssh sends the password over the network, but after end-to-end encryption has been negotiated. See section 8 of RFC 4252 which says that a password authentication message contains plaintext password in ISO-10646 UTF-8 encoding [RFC3629]

View more solutions

Comments

[Lightness Races in Orbit]

How else could it work?

[UTF-8]

@LightnessRacesinOrbit I added it to the question.

[ilkkachu]

@UTF-8, I also mentioned that public key authentication doesn't require sending a plaintext password, and also that things like SRP exist. I thought it was clear from context that "has to" was not an exact statement, but a reference to how current, usual implementations work. What could be done, seems a different question.

[JanKanis]

FYI, there are real security protocols that do such zero-knowledge proofs, as they are called in security circles. See this related question. There's the (slightly dodgy) Secure Remote Password protocol (SRP), and the newer OPAQUE. The question links to this article by Matthew Green that gives a nice description.

[JanKanis]

SSH sending the password as-is to the server also has some advantages. SSH (usually) uses PAM, the plugable authentication manager, to do the actual password verification. PAM is also used for the regular desktop log-in, so obviously it doesn't know anything about networks. PAM does a lot more than just checking the password, it can also handle things like setting up the session, unlocking encrypted disks and password managers, handling password expiration, etc. It can also be configured to do second factor authentication with tokens. By using PAM all that is also available in SSH for free.

[ilkkachu]

@UTF-8, Something like that could of course be implemented. Or something like CRAM-MD5. As far as I'm aware, that's not the usual case, though. Also anything like that would require client-side changes. Sending the password in plain allows for the server to decide on its own how to hash it.

[UTF-8]

But the server can tell the client which hash to use. 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.

[user4556274]

@UTF-8, you could do something like this, but it would no longer be the password authentication type defined in the ssh standards. It would be a variant of the keyboard interactive authentication type.

[UTF-8]

But why wasn't it designed like this? It's simple to dream up and would render man in the middle attacks unfeasible without the need for asymmetric keys, so it'd also be easy to use. Sending the password to the server just seems like such a bad idea to me. ssh could guarantee to the user to never send their password to the server, no matter what happens on the server side. Other than in the case of a website, the designer of the authentication methods is guaranteed to be able to run code on the client.

[ilkkachu]

@user4556274, or maybe a completely separate authentication method, since code changes would be required anyway, and the RFC pretty strongly implies that keyboard-interactive is meant for input from the user.

[R.. GitHub STOP HELPING ICE]

It should be noted that password authentication is obsolete and has lots of problematic consequences for security, and keyboard-interactive is even worse for submitting password-like secrets due to timing attacks. Modern configurations should be using public key authentication only and should have password authentication disabled. There's no reason for user accounts to even have passwords anymore.

[ilkkachu]

@R.., do you have any references on that? Problems with password, I mean, and especially the timing attack?

[user207421]

No. See RFC 4252 #8.

[Lightness Races in Orbit]

Your answer contradicts itself in several places.

[R.. GitHub STOP HELPING ICE]

@ilkkachu: For timing, perhaps people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf or security.stackexchange.com/questions/47192/….

[Gilles 'SO- stop being evil']

The first sentence is true. But this is not why you get prompted to accept the key of a new host.

[Gilles 'SO- stop being evil']

@R.. Timing attacks on passwords are very difficult to carry out in practice when the password is sent in one go, as is the case with SSH, as opposed to character by character. The main reason to deprecate password authentication is that users choose insecure passwords (with insufficient entropy). Passwords have plenty of legitimate uses. Keys have their weaknesses too, in particular that they have to be stored and an encrypted file from a stolen disk can be brute-forced to recover the key.

[R.. GitHub STOP HELPING ICE]

@Gilles: That's why I specifically commented about keyboard-interactive method in regards to timing attacks.

[ilkkachu]

@R.., That article is about passwords entered during the SSH session (like running su or sudo from the shell), not about the authentication phase of the SSH connection. keyboard-interactive authentication doesn't send keypresses one-by-one (according to RFC4256 it could even send responses to several prompts in one message). The paper mentions "interactive mode", which I suppose refers to a user pressing keys as opposed to a script entering commands (where any passwords would likely be sent as complete strings in one go).

[UTF-8]

Oh, you're right. That really would mean that knowing the hash is enough. I was focused on keeping users who reuse passwords safe and didn't think about leaked shadow files. Maybe dreaming something up within a few seconds in the process of writing a comment below an answer on StackExchange doesn't lead to the best security concepts after all. ;-)

[R.. GitHub STOP HELPING ICE]

@ilkkachu: OK, perhaps keyboard-interactive is just misnamed and not as dangerous as I thought.

[user207421]

'Plain text inside an encrypted channel' is now a contradiction in terms.

[BillThor]

@EJP The password is plain text as apposed to any of multiple non-plain text formats. The channel is encrypted as apposed to the un-encrypted channel used by telnet. If you manage to get someone to connect to a honeypot server, you will capture a plain text password.

[Gilles 'SO- stop being evil']

@JohannesOvermann That's a different scenario from the one I discuss in my answer: my answer is only about a two-party scenario with a client authenticating to a server. In your scenario involving three parties, the solution you propose doesn't work for the reason I explain in my answer: the third-party server has no way to know that the requester knows the password. It's also insecure because the third party gets a chance to reverse the hash by brute force. There are widely-deployed solutions for that scenario that actually work securely, e.g. Kerberos.

[Johannes Overmann]

@Gilles Yes, I agree Kerberos would be the proper way to do it. I still have concerns that via ssh and many other password based systems the password is transmitted to the other side in a way so that the other side knows the plain text password. My main points are: 1. Yes, the hash is as good as the password, except that the hash is use-case dependent while the password is universal. 2. Passing the password in plain text (encrypted) means that there is no difference between "I am authorized to access the system" and "I trust the system I am authorizing to to know my password" which is nasty.

[Johannes Overmann]

@Gilles Anyway, I appreciate your input (it still makes me think) and I have a feeling we both would agree that passwords based authentication is in itself not the best way to authenticate. It is a rather crude fallback.