191

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
  • 41
    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 '16 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 '16 at 19:19
  • 5
    @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 '16 at 20:58
  • @hobbs, ChallengeResponseAuthentication no too, I think – ilkkachu Sep 16 '16 at 9:17
214

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)

  • 13
    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 :-) – Stephen Harris Sep 15 '16 at 0:06
  • 116
    Yet another reason to use public/private key pairs... – gerrit Sep 15 '16 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 '16 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 '16 at 10:43
  • 44
    Better advice: never use password auth for ssh. The protocol has pubkey auth for very good reasons; use it! – R.. Sep 15 '16 at 16:52
52

Yes.

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 '16 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. – Blacklight Shining Sep 16 '16 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 '16 at 3:26
  • where can I see those passwords used to authenticate? They're not in /var/log/auth.log, where then? – アレックス Sep 17 '16 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. – musicinmybrain Sep 18 '16 at 20:36
10

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.

https://livesshattack.net

https://livesshattack.net/about

  • 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 '16 at 3:49
  • its not working anymore, I sent a huge string as password, I think that might have broken it, sorry :-/ – scottydelta Sep 18 '16 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 '16 at 15:28
  • Out of interest is the source for your modified lib-storepw available for others to use? – Tim Fletcher Sep 20 '16 at 9:10
2

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 '16 at 15:41

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.