8

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?

personal_cloud
  • 389
  • 1
  • 8
  • Check out this tool: [ssh-mitm](https://github.com/ssh-mitm/ssh-mitm) – Kate Dec 03 '22 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 Dec 05 '22 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 Dec 05 '22 at 17:16
  • @Joshua how great would it be if we didn't have legacy systems and backwards compatibility to cope with? – JoSSte Dec 05 '22 at 19:57
  • @JoSSte: The scheme merely has a different downside. The password (or rather, a password equivalent) is recoverable on server breach instead. It's 1994 tech. – Joshua Dec 05 '22 at 20:03
  • 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 Dec 06 '22 at 06:04
  • @Shadur irony may occur – JoSSte Dec 06 '22 at 10:20
  • @Shadur Actually, It's as simple as changing my own server to ssh++ (or whatever we want to call it), and having my users use the new client when logging in from an insecure network. And a client that supports both ssh and ssh++ would gain wide adoption. – personal_cloud Dec 23 '22 at 18:08

3 Answers3

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.

Toby Speight
  • 1,226
  • 9
  • 17
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • "Neither password based nor key based authentication of the client against the server will somehow authenticate the server." Sure, but this question is about configurations with *shared private credentials*, so the authentication is hopefully bidirectional. So after a secure session is established via DH, *both sides* need to send a hash of (username, password, session nonce, sender name). How does the server correctly produce its hash if it doesn’t have the password? – personal_cloud Dec 03 '22 at 19:26
  • @personal_cloud: What do you mean with *"shared private credentials"* ? Do you mean Pre-Shared Keys (PSK), where client and server have the same common secret? I don't think this is supported as SSH authentication. – Steffen Ullrich Dec 03 '22 at 19:46
  • Thank you, "both sides share the same common secret" is a better way to phrase it. I've updated the question accordingly. My question is about password mode, so the common secret is the (username, password) tuple. – personal_cloud Dec 03 '22 at 20:10
  • @personal_cloud: password mode does not provide this, see updated answer – Steffen Ullrich Dec 03 '22 at 20:31
  • Thank you, it makes sense now. One small thing I would change is when you say "That's not how password authentication works" I would add "in SSH". (Because obviously the asymmetry is not universal, as for example in PSK, which could be called "password authentication" because it authenticates using a password.) – personal_cloud Dec 03 '22 at 20:41
  • 1
    @personal_cloud: Good point, I've made this more clear. – Steffen Ullrich Dec 03 '22 at 20:46
  • 4
    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: https://www.gremwell.com/ssh-mitm-public-key-authentication – Joshua Dec 05 '22 at 17:24
  • 1
    @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 Dec 07 '22 at 02:21
  • @AaronDufour: Well not actually providing a connection to the intended server falls into "I want to get caught!" territory. – Joshua Dec 07 '22 at 03:18
9

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).

mti2935
  • 21,098
  • 2
  • 47
  • 66
  • 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 Dec 03 '22 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 http://www.browserauth.net/ for more info. But sadly, neither PAKE/SRP nor channel binding have gained much footing. – mti2935 Dec 03 '22 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 https://datatracker.ietf.org/doc/draft-nisse-secsh-srp/. (PuTTY's "wishlist" https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/srp-auth.html also references another different draft and an OpenSSH patch.) – user1686 Dec 05 '22 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.

personal_cloud
  • 389
  • 1
  • 8
  • 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 Dec 03 '22 at 20:32
  • @Steffen Both sides have a shared secret P. Whether P is password or hash(password) makes no difference. Both sides ought to be sending a hash of (user,P,session,sender) and verifying the one they received. Or just using symmetric encryption. But Alas SSH appears to have needless vulnerability. – personal_cloud Dec 03 '22 at 20:35
  • *"Or just using symmetric encryption."* - which would require a shared secret in the first place, or what key would you use to encrypt? Also, as you mentioned yourself the connection to submit the password is already encrypted. But if the authentication is not done properly, then the encryption key was exchanged between client and attacker, not client and server. – Steffen Ullrich Dec 03 '22 at 20:40
  • 5
    *"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 Dec 03 '22 at 20:43
  • @Steffen Sure, accessing the password hash would have system design implications on the server side. But password sync is generally not a show-stopper, especially if it improves security by providing a second layer of server authentication. – personal_cloud Dec 03 '22 at 20:47
  • @Steffen Re: "if the authentication is not done properly, then the encryption key was exchanged between client and attacker". I think that all the proposals address that. With the current DH, then that key has no value to the attacker because it’s generated from nonces. If we add bi-directional password challenge, then the attacker gains nothing because he only receives a hash that includes the session nonce. If we simply use a hash of (username, password) as the key, then there is no key exchange – the attacker simply gets data that he can’t decrypt. – personal_cloud Dec 03 '22 at 21:01
  • 1
    @personal_cloud What you describe seems very similar to 'channel binding', where a TLS session is built first, then the client's bearer token (e.g. password) is tangled with the session material, then a cryptographic product of that is sent to the server. See http://www.browserauth.net/ for more info. – mti2935 Dec 03 '22 at 21: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 https://moxie.org/2022/01/07/web3-first-impressions.html for some interesting thoughts on this by Moxie Marlinspike. – mti2935 Dec 03 '22 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 Dec 04 '22 at 19:50
  • 3
    The thing where you have a secret and use maths to authenticate the client without revealing the secret is called SSH keys. – ilkkachu Dec 04 '22 at 19:51
  • @mti2935: Actually that's due to the Snowden fiasco. Offline X509 certificates are considered broken now. – Joshua Dec 05 '22 at 20:05