9

Assume that I never check the server fingerprint when logging in to an SSH server. This means that certain configurations of SSH can be impersonated. For example, I can log into a server that only has my public key. Obviously this doesn't authenticate the server.

But now suppose that SSH uses a private password. I am not familiar with the internals of SSH, but I would hope that the password challenge goes in both directions when both sides share the same common secret. Therefore, if I enter my password and the client allows the connection, then it has authenticated the server. Is this reasoning correct?

Or is there still some way for someone without my password to impersonate the server?

Improve this question
8
  • Check out this tool: ssh-mitm
    – Kate
    Commented Dec 3, 2022 at 21:58
  • 3
    Who says that the server wouldn't just accept any password? - If I want to impersonate your server, and I just accept your password - you would believe that I was your server - since you didn't look at my keys, and then i'd just connect on to your server - essentially a man in the middle (MitM) attack
    – JoSSte
    Commented Dec 5, 2022 at 13:18
  • 3
    @JoSSte: Suppose the following was how it worked: The password is never sent down the wire; but rather the session key is computed using bits from the password and generating the matching session key is the proof the client has the correct password. Since an implementation can exist that provides the requested security principle, the question is reasonable. Too bad it is not the case.
    – Joshua
    Commented Dec 5, 2022 at 17:16
  • @Joshua how great would it be if we didn't have legacy systems and backwards compatibility to cope with?
    – JoSSte
    Commented Dec 5, 2022 at 19:57
  • 1
    @josste Sounds great! Let's replace all the old inefficiencies and protocol weaknesses with entirely new ones at the low low cost of breaking compatibility with existing hardware/software.
    – Shadur-don't-feed-the-AI
    Commented Dec 6, 2022 at 6:04

3 Answers 3

Reset to default
22

... if I enter my password and the client allows the connection, then it has authenticated the server.

Neither password based nor key based authentication of the client against the server will somehow authenticate the server. This is also true if the client's private key is protected by a password: the password will only be used locally on the client to use the private key on the client, but has nothing to do with successful or unsuccessful server authentication.

In other words: not properly authenticating the server opens you up to server impersonation or man in the middle attacks, no matter which client authentication method is used.

... a private password. I am not familiar with the internals of SSH, but I would hope that the password challenge goes in both directions when both sides share the same common secret.

That's not how password authentication in SSH works. With password authentication the server simply gets the password from the client and then checks it against the local (to server) authentication mechanism. Typically the password is not even known server side for checking it, but only a password hash is known. And maybe not even this, because the server might use an authentication backend like PAM, LDAP or Radius.

So when the client does not properly authenticate the server in this case, then the wrong server (attacker) might end up with the client's password and can use it against the real server.

A real shared common secret would be Pre-Shared Key, as known from WPA-PSK, IPSec or PSK authentication in TLS. In this mode the authentication can only succeed if both client and server know the same secret, but without some man in the middle able to sniff the secret. But PSK based authentication is not defined for SSH.

Improve this answer
3
  • 5
    Key based authentication does in fact protect against man in the middle attacks even if the client doesn't know the server's host key yet. Every once in awhile somebody reads the documentation, thinks they can do it, rolls it out and finds out it doesn't work. What actually happens is the client checks using a builtin feature and notices the server doesn't have the actual key despite accepting it and refuses to continue. We've had to deal with a few of these. Source: gremwell.com/ssh-mitm-public-key-authentication
    – Joshua
    Commented Dec 5, 2022 at 17:24
  • 2
    @Joshua That's a rather different attack than what's being described here - in that one, the MITM is trying to auth to the server as if it was the client. What's being described here only requires the attacker to impersonate the server to the client, which publickey auth does not protect from if the client chooses not to check the server's hostkey.
    – Aaron Dufour
    Commented Dec 7, 2022 at 2:21
  • @AaronDufour: Well not actually providing a connection to the intended server falls into "I want to get caught!" territory.
    – Joshua
    Commented Dec 7, 2022 at 3:18
8

Your question seems to revolve around the idea of mutual authentication between an SSH client and SSH server based on a password. Protocols like PAKE and SRP aim to solve this problem. With PAKE/SRP, the client and the server mutually authenticate one another based on a password known to the client (and a derivation of the password known to the server). At the end of the process, the client and the server share a shared secret, which can then be used to create a secure transport layer between the client and the server. PAKE and SRP offer other benefits as well. See Alternatives for sending plaintext password while login for more info.

But, I am not aware of any SSH implementations that incorporate PAKE or SRP. SSH generally works differently. First, a secure transport layer between the client and the server is built (e.g. as per RFC 5656). The client can optionally authenticate the server during this phase of the process (see section 4 of RFC 5656). Then, once the secure transport layer is in place, the client can then optionally authenticate with the server (e.g. as per RFC 4252), using any one of several possible methods (e.g. public key authentication, password authentication, etc).

Improve this answer
3
  • Yes, this gets to the heart of my question. Very interesting. PAKE/SRP sounds better than the scheme I proposed, as the server does not need a password-equivalent.
    – personal_cloud
    Commented Dec 3, 2022 at 22:00
  • 1
    @personal_cloud Glad to hear it. Channel Binding may also be of interest to you. This is where the secure transport layer is built first, then the client tangles its bearer token (e.g. password) with some of the session material that it sees for the session, and sends a cryptographic result of that. This also mitigates MITM attacks, and does not require the server to store a password (or password equivalent). See browserauth.net for more info. But sadly, neither PAKE/SRP nor channel binding have gained much footing.
    – mti2935
    Commented Dec 3, 2022 at 22:05
  • There are no surviving implementations of SRP in SSH, but the GNU lsh SSH server/client used to have support for SRP as an authentication mechanism based on datatracker.ietf.org/doc/draft-nisse-secsh-srp. (PuTTY's "wishlist" chiark.greenend.org.uk/~sgtatham/putty/wishlist/srp-auth.html also references another different draft and an OpenSSH patch.)
    – grawity
    Commented Dec 5, 2022 at 13:43
3

According to this site:

The general method is password authentication, which is when the server prompts the client for the password of the account they are attempting to log in with. The password is sent through the negotiated encryption, so it is secure from outside parties.

(emphasis on "the password is sent" is mine).

Which suggests that the password itself (or a fixed hash of it) is sent to the server. Not(??!!) hashed with session nonce first.

Given its popularity, it's hard to believe that SSH relies entirely on the fingerprint mechanism to authenticate the server, when it's obvious how to improve on that without changing how it's used. I'm hoping there will be a better answer.

Improve this answer
11
  • 2
    "when it's obvious how to improve on that without changing how it's used." - the server usually does not have the users password, but only the hash. So there is no shared secret. If you think there is an obvious method in this case which is not vulnerable to man in the middle, then please be more clear what this method would be.
    – Steffen Ullrich
    Commented Dec 3, 2022 at 20:32
  • 6
    "Both sides ought to be sending a hash of (user,P,session,sender) and verifying the one they received." - the server might not even have direct access to the hashed password. It might be abstracted away by plugable authentication (PAM), there might be a Radius or LDAP backend etc. So all the server can do is pass through the password received from the client. If you want proper authentication without the risk of MITM even when (for whatever reason) insisting on ignoring the server authentication, then use key based authentication in the client and not a password.
    – Steffen Ullrich
    Commented Dec 3, 2022 at 20:43
  • 2
    @personal_cloud As to your overarching question as to why none of the ideas on this page have been widely implemented - it's the same reason that we still do not have a widely used standard for e2e email encryption after 30+ years (yet WhatsApp was able to do it in less than a year). It's the 'tragedy of the commons' when it comes to open-standard decentralized systems. See moxie.org/2022/01/07/web3-first-impressions.html for some interesting thoughts on this by Moxie Marlinspike.
    – mti2935
    Commented Dec 3, 2022 at 21:48
  • 2
    re. "(or a fixed hash of it)", no it's the plaintext password. That allows the server to decide what sort of hashing to use on its end, or to just shunt the password to some other program (e.g. an LDAP server) for verification. Also, it makes it possible to do stuff like tacking an OTP code at the end of the password and have the server split the password string it received to verify both. Also if a hash of the password was sent, that hash would essentially be the password in that capturing and reusing it would work fine.
    – ilkkachu
    Commented Dec 4, 2022 at 19:50
  • 4
    The thing where you have a secret and use maths to authenticate the client without revealing the secret is called SSH keys.
    – ilkkachu
    Commented Dec 4, 2022 at 19:51

You must log in to answer this question.

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