When you accidentally attempt to connect to the wrong server with password credentials is it possible for the administrator to read and log the password you used?

  • 11
  • 42
    In an ssh client, you first authenticate the server and doing so you say "I trust I can tell my password to this server". Next time pay closer attention to the message you saw first: "The authenticity of X can't be established. RSA key fingerprint is Y Are you sure Z? (yes/no)" This annoying question wouldn't be asked if you supposed to automatically answer yes every single time.
    – kubanczyk
    Sep 15, 2016 at 11:25
  • 6
    It's possible to set PasswordAuthentication no by default in OpenSSH, and only enable it (if/when needed) for trusted servers. Combined with strict host key checking, this should mostly protect you from exposing your password, at a cost in convenience of course.
    – hobbs
    Sep 15, 2016 at 19:19
  • 6
    @kubanczyk, if you wanted to SSH to "internal-www.my-company.com" but accidentally typed in "ssh www.my-company.com", that prompt won't protect you -- it's likely that both servers are on your trusted list, it's just that one of them is run by you, and the other by a third party.
    – Mark
    Sep 15, 2016 at 20:58
  • @hobbs, ChallengeResponseAuthentication no too, I think
    – ilkkachu
    Sep 16, 2016 at 9:17

4 Answers 4


Simple put: yes

More detail...

If you connect to my machine then you don't know if I'm running a normal ssh server, or one that has been modified to write out the password being passed.

Further, I wouldn't necessarily need to modify sshd, but could write a PAM module (eg using pam_script), which will be passed your password.

So, yes. NEVER send your password to an untrusted server. The owner of the machine could easily have configured it to log all attempted passwords.

(In fact this isn't uncommon in the infosec world; set up a honeypot server to log the passwords attempted)

  • 14
    Correct. By default, the standard sshd does not log passwords. (If you enter your password as a login name then it'll be logged, but that's another problem). The standard sshd is a security tool, and so won't log credentials like this :-) Sep 15, 2016 at 0:06
  • 119
    Yet another reason to use public/private key pairs...
    – gerrit
    Sep 15, 2016 at 8:33
  • 3
    I have been wondering about my use of passwords for a while and it recently dawned on me that attempting to log on to the wrong servers would be a good way of revealing my password to a malicious server administrator.
    – vfclists
    Sep 15, 2016 at 8:39
  • 10
    @vfclists logging on to the wrong server is also exactly the reason your sshd client stores the finger print for each server. When you first connect, you accept that fingerprint, then later if it doesn't match, you get a giant warning which you should heed.
    – hometoast
    Sep 15, 2016 at 10:43
  • 45
    Better advice: never use password auth for ssh. The protocol has pubkey auth for very good reasons; use it! Sep 15, 2016 at 16:52


The password is sent after the encrypted connection is established, but the remote server gets the password in plaintext.

If you care about that, the best and easiest solution is to use SSH keys.

If you have machines that cannot accept keys, then one solution would be to create a tool that stores your passwords safely, and then uses sshpass to always send the correct password depending on the server you're connecting to.

Now, the reason the password is sent in plaintext, is that it leaves all decisions of handling and storing it to the remote end, and the client can be totally dumb. There are a couple of different password hashing (storage) formats used in Linux and BSD systems during the last ten years or so (crypt(3)), none of which require support from the client.

Though that's partly because of history, too (i.e. it's always been like that). There are better challenge-response authentication protocols that could be used even with passwords. For example SRP, that provides the parties with a shared secret during the authentication. It has been implemented for some SSH servers, but the patch for OpenSSH is for a (very) old version.

  • 1
    The problem with challenge-response protocols for password authentication is that some of them require the server to store the password in plain-text. If the challenge-response protocol does allow for the server to store a hashed password, then it most likely requires a very specific hashing algorithm.
    – kasperd
    Sep 15, 2016 at 22:30
  • 8
    Passwords are generally sent in “plaintext” (i.e. not actually in the clear, but only with the protection that the underlying SSH|TLS|whatever connection provides). If a system called for passwords to be hashed client-side and the hash to be sent, servers would have no way to derive the actual password, and would instead grant access to anyone who could provide the password hash, making said hash password-equivalent. Sep 16, 2016 at 20:43
  • 1
    @BlacklightShining Zero-knowledge password proofs do exist, but aren't used in SSH because there's no way to use the standard password database for them and no real point to using them rather than key-based authentication.
    – Random832
    Sep 17, 2016 at 3:26
  • where can I see those passwords used to authenticate? They're not in /var/log/auth.log, where then?
    – Incerteza
    Sep 17, 2016 at 6:37
  • OpenSSH will not log passwords, failed or otherwise. (I’m not very familiar with other SSH servers.) In nearly all legitimate installations, any value this might provide would be outweighed by the risk inherent in intentionally recording passwords—some of which might have been provided by legitimate users who made a typo or tried a wrong-but-right-for-something-else password—in cleartext. If you have a good reason to do this, though, it would be easy to patch OpenSSH. Sep 18, 2016 at 20:36

To build on top of Stephen Harris's answer, here is a real-time view I built that shows what a modified PAM auth script would be able to capture when connecting to a box over ssh (a honeypot of sorts). I use a modified version of the PAM library lib-storepw.



  • 4
    Answers that are primarily links are frowned upon in case the link becomes unavailable (it sounds like you maintain this site personally, but still). You should describe a bit how you managed this with your auth script for readers.
    – Centimane
    Sep 17, 2016 at 3:49
  • its not working anymore, I sent a huge string as password, I think that might have broken it, sorry :-/ Sep 18, 2016 at 9:10
  • @scottydelta Although I have not looked into it, there may be a buffer limit on either the password size the PAM module or the SSH daemon itself can accept in an authentication attempt. The site is still working as I intended it to, albeit will handle up to the buffer limit accepted by the sshd or the PAM module if this is indeed the case.
    – Willie S.
    Sep 19, 2016 at 15:28
  • Out of interest is the source for your modified lib-storepw available for others to use? Sep 20, 2016 at 9:10

SSH is a protocol which requires mutual trust. That is the reason why the OpenSSH client maintains a known_hosts file, to implement its trust on first use scheme.

When you attempt to logon to an SSH server, regardless of who supplied the software or what data it is configured to log, you are participating in some authentication procedure. When using password authentication, you are transmitting your password to that server. This is one reason why asymmetric cryptography (public key, certificates) is recommended - public key cryptography greatly reduces the risk of disclosing your credentials. (Although that may not protect you from an MitM attack if using ssh-agent forwarding or some similar scheme.)

  • SSH does not require mutual trust, or at least not symmetric trust. It's important to be precise: known_hosts is about authenticity, not trust. As you point out, placing a public key on a less-trusted host is safe. Indeed, using a password to login there is "safe" as well, assuming you don't reuse that password. (It's only as safe as the degree to which you trust the server, of course.) Even hostbased ssh logins depend on asymmetric trust.
    – markhahn
    Sep 23, 2016 at 15:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .