194

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?

vfclists
  • 7,531
  • 14
  • 53
  • 79
  • 11
    Does SSH password authentication provide the server with the password? – jamesdlin Sep 15 '16 at 01:15
  • 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 '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
  • 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 '16 at 20:58
  • @hobbs, ChallengeResponseAuthentication no too, I think – ilkkachu Sep 16 '16 at 09:17
  • One should ignore the warning about connection to an unknown host (not in "known_hosts" file) to get in this situation. I believe no passwords are sent if the user has not decided to pursue the connection to this unknown server. – Vladislavs Dovgalecs Sep 19 '16 at 18:37
  • Comments are not for extended discussion; this conversation has been moved to chat. – Michael Mrozek Sep 20 '16 at 06:13

4 Answers4

215

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)

Stephen Harris
  • 44,540
  • Does this mean the standard sshd daemon does not log the password, although custom builds can, besides PAM modules you mentioned? – vfclists Sep 15 '16 at 00:03
  • 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 :-) – Stephen Harris Sep 15 '16 at 00:06
  • @vfclists It wouldn't just have to be a custom build. Only a very stupid patch or a malicious impersonator would log a password. – Gilles 'SO- stop being evil' Sep 15 '16 at 07:17
  • 119
    Yet another reason to use public/private key pairs... – gerrit Sep 15 '16 at 08: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 08: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
  • 2
    The risk of logging onto the wrong server is also a good reason to use a distinct password for each server. In practical terms, that requires the use of a software vault to remember them. But that does eliminate this risk. – Wayne Conrad Sep 15 '16 at 11:37
  • 45
    Better advice: never use password auth for ssh. The protocol has pubkey auth for very good reasons; use it! – R.. GitHub STOP HELPING ICE Sep 15 '16 at 16:52
  • 3
    or you could just add the sites to your .ssh/config and avoid typos and similar issues... bash can even be set to auto-complete known servers, so pressing TAB is another way to avoid mistyping it... – ivanhoe Sep 17 '16 at 00:59
  • Sorry, I can't make it out, it's so small, is it "never" or "always" send your password to an untrusted server? – Incerteza Sep 17 '16 at 06:36
  • 2
    @ivanhoe: That doesn't really help since you could still send your password to the wrong server (e.g. send your internal server password to a cheap hosting company's server). Even if you trust whoever runs the server you sent it to, do you trust that they're not compromised by someone else who's logging passwords? Etc. Public key auth is immune to all of these issues. – R.. GitHub STOP HELPING ICE Sep 18 '16 at 15:42
  • Why is a hash not sent? – WGroleau Sep 18 '16 at 22:35
  • @WGroleau: Because that would not help; then the hash is the password and you lose all the benefits of having hashed passwords. – R.. GitHub STOP HELPING ICE Sep 19 '16 at 04:33
  • 1
    I agree. But in practice how the admin of wrong server will know the right server? This does not reduce the security risk but is small reassurance. – i486 Sep 19 '16 at 08:46
  • @R..: Well, it also has password auth for a reason, so telling people to use public key because it's there for "a reason" without telling them why password based auth also exists isn't exactly convincing. – user541686 Sep 19 '16 at 19:56
  • @Mehrdad: The reason for password auth is that it's the legacy method people used before ssh. I think others (and this answer) have already covered the reasons to use pubkey auth; I don't need to repeat them. – R.. GitHub STOP HELPING ICE Sep 19 '16 at 22:41
  • @R..: Yeah, no, you don't need to repeat them for me, I'm just saying incorporate it into your future comments for other people. Telling people it's only there for legacy/compatibility reasons is a lot more informative than telling them just not to use it. Otherwise it's not terribly convincing... they might think it's because you think they're too dumb to handle passwords compared to other people or something. – user541686 Sep 19 '16 at 22:43
  • The owner of the machine could easily have configured it to log all attempted passwords. It doesn't even have to be that difficult. Anyone with root access on the server can run strace or truss (or similar, depending on the server OS) and dump all the data sshd reads. Instant keystroke logger. – Andrew Henle Sep 20 '16 at 11:08
  • 1
    @AndrewHenle from a "hands off, leave it running, review logs after" perspective, a 1 line change to sshd generates a lot less noise and doesn't require continuous trussing (Proof of concept at https://www.sweharris.org/post/2016-09-18-ssh-password-exposure/ ) – Stephen Harris Sep 20 '16 at 11:56
  • @StephenHarris No doubt that's cleaner for a system designed to capture passwords. I was trying to point out that a compromised or nefariously-configured system isn't necessary to capture passwords and that most OSes provide the required tools out-of-the-box. – Andrew Henle Sep 20 '16 at 12:37
  • @hometoast The fingerprint warning helps if something reroutes your connection in the network. It won't help if you login to the wrong host because you typed ssh knownsiteA when you meant ssh knownsiteB. – Barmar Sep 22 '16 at 01:23
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.

ilkkachu
  • 138,973
  • 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 03:26
  • where can I see those passwords used to authenticate? They're not in /var/log/auth.log, where then? – Incerteza Sep 17 '16 at 06: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
  • Addendum to @musicinmybrain's comment: If you have to ask, you do not have a good reason to do this. – Shadur-don't-feed-the-AI Mar 30 '19 at 22:14
11

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

Willie S.
  • 111
  • 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 03: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 09: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 09: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.)

jvoorhis
  • 21
  • 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