Client auth: "authentication methods that can continue" is mishandled #533
Comments
tomaswolf
added a commit
to tomaswolf/mina-sshd
that referenced
this issue
Jul 25, 2024
The ClientUserAuthService iterates through the configured authentication methods and tries them each in order, skipping those that the server did not list as acceptable. However, it only set the "server acceptable" on a partial success, or on the initial failure for the "none" request. This was wrong: if a pubkey auth fails and the server replies with SSH_MSG_USERAUTH_FAILURE and an acceptable methods list not containing "pubkey", then pubkey should not continue even if it had more keys available (or more signatures to try for an RSA key). This case actually occurs, for instance with an XFB.Gateway SSH server and RSA keys, if an rsa-sha2* signature is used. That server apparently knows only ssh-rsa signatures and consequently may reply with SSH_MSG_USERAUTH_FAILURE, partialSuccess=false, allowed=password. (Presumably if the key was right but the signature was unknown, and the user has only a single authorized key, and password auth is enabled server-side.) So reset the "server acceptable" list on any SSH_MSG_USERAUTH_FAILURE, even if partialSuccess = false. Check whether the current method is still allowed, and if not start over instead of continuing with the current method. A second problem was with the handling of multiple required authentication methods. A server may require multiple authentications, for instance first a pubkey auth, then a password auth, and then again a pubkey auth with another key. Such continuations are indicated by SSH_MSG_USERAUTH_FAILURE with partialSuccess = true and a list of methods to try next. For pubkey,password,pubkey the client would get a message SSH_MSG_USERAUTH_FAILURE partialSuccess=true allowed=password after the successful first pubkey authentication, and then a message SSH_MSG_USERAUTH_FAILURE partialSuccess=true allowed=pubkey after the successful password log-in. On that second use of pubkey auth, the previously successful key must not be re-tried, and there's also no point in re-trying previously rejected keys. Thus our code cannot simply create a new UserAuthPublicKey instance again as this would re-load the key iterator from scratch. Instead we must remember the pubkey auth instance once created and re-use that same instance on the second use, so that we keep on with any remaining keys that might be available. See also https://issues.apache.org/jira/browse/SSHD-1229, which may be related. Bug: apache#533
tomaswolf
added a commit
to tomaswolf/mina-sshd
that referenced
this issue
Jul 29, 2024
The ClientUserAuthService iterates through the configured authentication methods and tries them each in order, skipping those that the server did not list as acceptable. However, it only set the "server acceptable" on a partial success, or on the initial failure for the "none" request. This was wrong: if a pubkey auth fails and the server replies with SSH_MSG_USERAUTH_FAILURE and an acceptable methods list not containing "pubkey", then pubkey should not continue even if it had more keys available (or more signatures to try for an RSA key). This case actually occurs, for instance with an XFB.Gateway SSH server and RSA keys, if an rsa-sha2* signature is used. That server apparently knows only ssh-rsa signatures and consequently may reply with SSH_MSG_USERAUTH_FAILURE, partialSuccess=false, allowed=password. (Presumably if the key was right but the signature was unknown, and the user has only a single authorized key, and password auth is enabled server-side.) So reset the "server acceptable" list on any SSH_MSG_USERAUTH_FAILURE, even if partialSuccess = false. Check whether the current method is still allowed, and if not start over instead of continuing with the current method. A second problem was with the handling of multiple required authentication methods. A server may require multiple authentications, for instance first a pubkey auth, then a password auth, and then again a pubkey auth with another key. Such continuations are indicated by SSH_MSG_USERAUTH_FAILURE with partialSuccess = true and a list of methods to try next. For pubkey,password,pubkey the client would get a message SSH_MSG_USERAUTH_FAILURE partialSuccess=true allowed=password after the successful first pubkey authentication, and then a message SSH_MSG_USERAUTH_FAILURE partialSuccess=true allowed=pubkey after the successful password log-in. On that second use of pubkey auth, the previously successful key must not be re-tried, and there's also no point in re-trying previously rejected keys. Thus our code cannot simply create a new UserAuthPublicKey instance again as this would re-load the key iterator from scratch. Instead we must remember the pubkey auth instance once created and re-use that same instance on the second use, so that we keep on with any remaining keys that might be available. See also https://issues.apache.org/jira/browse/SSHD-1229, which may be related. Bug: apache#533
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
master
Bug description
(Split from #531)
ClientUserAuthServiceignores "authentication methods that can continue" on SSH_MSG_USERAUTH_FAILURE if not a partialSuccess.Actual behavior
Server replies during publickey authentication
Client continues with publickey authentication all the same:
Expected behavior
Client should switch to password authentication, and not continue with publickey authentication.
Relevant log output
No response
Other information
This may be related to SSHD-1229. There is another, related problem in
ClientUserAuthService, which may have been what prompted the report in SSHD-1229: if a server is configured to require multiple authentications and "publickey" is mentioned more than once (for instanceAuthenticationMethods publickey,publickey: user has to authenticate with two different keys),ClientUserAuthServicemisbehaves and tries the first key again.The text was updated successfully, but these errors were encountered: