[someplaceguy]

> if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers.

Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound.

In fact, passwords in /etc/shadow already do have random salts, so why aren't these sent over to the SSH client so it can send a proper hash instead of the plaintext password?

[danparsonson]

If the hash permits a login then having a hash is essentially equivalent to having a password. The malicious user wouldn't be able to use it to sudo but they could deploy some other privilege escalation once logged in.

[djao]

It's a little bit more complicated than just sending a hash of the password, but there are ways to authenticate using hashed passwords without sending the password over the wire, for example https://en.wikipedia.org/wiki/Digest_access_authentication or https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

Even so, these protocols require the server to know your actual password, not just a hash of the password, even though the password itself never traverses the network. So a compromised server can still lead to a compromised credential, and unless you use different passwords for every server, we're back to the same problem.

[tialaramex]

Asymmetric PAKEs don't require the server to know your password. You and the server need to have a discussion to establish some parameters that work for your chosen password, without revealing what it is, and then in future you can supply evidence that you indeed know the password (that is, some value which satisfies the agreed parameters), still without revealing what it is. This is not easy to do correctly, whereas it's really easy to get it wrong...

https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/