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.

  • How else could it work? – Lightness Races in Orbit Jul 24 '16 at 14:46
  • @LightnessRacesinOrbit I added it to the question. – UTF-8 Jul 24 '16 at 17:45
  • @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. – ilkkachu Jul 25 '16 at 9:08
  • 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 Feb 9 '20 at 15:31
  • 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. – JanKanis Feb 9 '20 at 15:42

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!

  • 2
    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. ;-) – UTF-8 Jul 25 '16 at 9:59
  • I slightly disagree that sending the password is always better than sending a hash. There are common scenarios where users use the same synchronized password for multiple systems. One of these systems might be outsourced to a third party. Then it would be beneficial to pass just the hash to the third party and not the password, since the hash cannot be used on the other (different) systems, while the password is universal and can get used on all systems. (I assume a proper hash which cannot be reversed even with rainbow tables, like bcrypt or PBKDF2.) – Johannes Overmann Nov 8 '18 at 23:05
  • @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. – Gilles 'SO- stop being evil' Nov 9 '18 at 7:18
  • @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 Nov 10 '18 at 19:02
  • @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. – Johannes Overmann Nov 10 '18 at 19:04

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.

  • @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. – ilkkachu Jul 23 '16 at 19:42
  • 1
    @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. – user4556274 Jul 23 '16 at 19:45
  • 1
    @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. – ilkkachu Jul 23 '16 at 21:00
  • 2
    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. – R.. GitHub STOP HELPING ICE Jul 24 '16 at 0:10
  • 1
    @R.., do you have any references on that? Problems with password, I mean, and especially the timing attack? – ilkkachu Jul 24 '16 at 8:45

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]


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.


% 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.


SSH does send the userid and password over the network in plain text inside an encrypted channel. This is why when you connect a new host you get prompted to accept the key. In the case of a man-in-the-middle attack with a known host, SSH will refuse to connect until you remove the old key.

The plain text password is available at the end points, your computer and the remote computer. It is possible to disable password authentication, in which case the password is neither prompted for nor sent to the remote host.

It is safer to use key-based authentication with a password protected key. You need to get your key added to the remote system. The public key is a text file that can be transferred by many mechanisms. When using key-based authentication it is possible to place restrictions on the use of the key.

  • No. See RFC 4252 #8. – user207421 Jul 24 '16 at 9:44
  • Your answer contradicts itself in several places. – Lightness Races in Orbit Jul 24 '16 at 14:47
  • 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' Jul 24 '16 at 22:20
  • 'Plain text inside an encrypted channel' is now a contradiction in terms. – user207421 Jul 26 '16 at 5:44
  • @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. – BillThor Aug 3 '16 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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