Page MenuHomePhabricator

Bad authentication state after failed GSSAPI authentication
Closed, ResolvedPublic

Description

https://cpaste.org/py1skpwji/df1gkw#line-105

[2016/10/06 17:51:23.076184, 2] ssh//packet//userauth//failure:  Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
[2016/10/06 17:51:23.076195, 1] ssh//packet//userauth//failure:  Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
[2016/10/06 17:51:23.076213, 2] ssh//userauth//gssapi:  Authenticating with gssapi-with-mic
[2016/10/06 17:51:23.076264, 2] ssh//gssapi//auth//mic:  Authenticating with gssapi to host dell-t5810ws-rdo-05.tpb.lab.eng.brq.redhat.com with user pino
[2016/10/06 17:51:23.079093, 3] ssh//gssapi//match:  GSSAPI valid oid 0 : 2a:86:48:86:f7:12:01:02:02
 
[2016/10/06 17:51:23.079128, 2] ssh//gssapi//auth//mic:  Sending 1 oids
[2016/10/06 17:51:23.079229, 3] ssh//socket//unbuffered//write:  Enabling POLLOUT for socket
[2016/10/06 17:51:23.079264, 3] packet//send2:  packet: wrote [len=76,padding=10,comp=65,payload=65]
[2016/10/06 17:51:23.080826, 3] ssh//packet//socket//callback:  packet: read type 60 [len=28,padding=11,comp=16,payload=16]
[2016/10/06 17:51:23.080888, 3] ssh//packet//process:  Dispatching handler for packet type 60
[2016/10/06 17:51:23.080902, 4] ssh//packet//userauth//pk//ok:  Received SSH//USERAUTH//PK//OK/INFO//REQUEST/GSSAPI//RESPONSE
[2016/10/06 17:51:23.080913, 3] ssh//packet//userauth//gssapi//response:  Received SSH//USERAUTH//GSSAPI//RESPONSE
[2016/10/06 17:51:23.293624, 1] ssh//gssapi//log//error:  GSSAPI(Initializing gssapi context): Unspecified GSS failure.  Minor code may provide more information
ssh: authenticate    ... auth with kerberos: 4
[2016/10/06 17:51:33.090030, 4] agent//talk:  Request length: 1
[2016/10/06 17:51:33.090212, 4] agent//talk:  Response length: 965
[2016/10/06 17:51:33.090314, 1] ssh//agent//get//ident//count:  Answer type: 12, expected answer: 12
[2016/10/06 17:51:33.090335, 3] ssh//agent//get//ident//count:  Agent count: 3
[2016/10/06 17:51:33.090377, 3] ssh//userauth//agent:  Trying identity /home/ptoscano/.ssh/ci.centos.org
[2016/10/06 17:51:33.090398, 1] ssh//userauth//try//publickey:  Wrong state during pending SSH call
[2016/10/06 17:51:33.090420, 3] ssh//userauth//publickey//auto:  Trying to authenticate with /home/ptoscano/.ssh/id//ecdsa
[2016/10/06 17:51:33.090464, 4] ssh//pki//import//pubkey//file:  Error opening /home/ptoscano/.ssh/id//ecdsa.pub: No such file or directory
[2016/10/06 17:51:33.090489, 4] ssh//pki//import//privkey//file:  Error opening /home/ptoscano/.ssh/id//ecdsa: No such file or directory
[2016/10/06 17:51:33.090501, 3] ssh//userauth//publickey//auto:  Private key /home/ptoscano/.ssh/id//ecdsa doesn't exist.
[2016/10/06 17:51:33.090512, 3] ssh//userauth//publickey//auto:  Trying to authenticate with /home/ptoscano/.ssh/id//rsa
migration created this object with visibility "Restricted Project (Project)".
migration created this object with edit policy "Restricted Project (Project)".
asn raised the priority of this task from Normal to High.Nov 16 2017, 12:05 PM
asn changed the visibility from "Restricted Project (Project)" to "Public (No Login Required)".Jan 19 2018, 10:27 AM

Is there a reproducer for this?

Proposed fix: https://github.com/ansasaki/libssh/pull/5

When the GSSAPI authentication failed inside one of the response packet handling callbacks, the session->auth_state was not set to SSH_AUTH_STATE_ERROR.

Then, ssh_auth_response_termination() would return 0 because the state would be kept as SSH_AUTH_STATE_GSSAPI_REQUEST_SENT, for instance, which would result in ssh_userauth_get_response() to return SSH_AUTH_AGAIN.

Finally, in ssh_userauth_gssapi(), if the returned error code was SSH_AUTH_AGAIN, session->pending_call_state is not reset to SSH_PENDING_CALL_NONE, being kept as SSH_PENDING_CALL_AUTH_GSSAPI_MIC.

This would lead to errors in following tries to authenticate the user using the same session due to the wrong state.

I could not reproduce the error condition, can someone check if this fixes the reported bug?

Moved this to https://gitlab.com/ansasaki/libssh-mirror/merge_requests/5

It was rebased to the available master at the time; the CI run was successful

In T56#1303, @ansasaki wrote:

I could not reproduce the error condition, can someone check if this fixes the reported bug?

I'm the author of the original redmine task.

The setup is very easy:

  1. from a stock Fedora machine (no changes to the local ssh config), try to ssh to another Fedora machine (again, no changes to the default sshd configuration)
  2. the machine to which you are connecting to has no GSS/kerberos setup
  3. after ssh_userauth_none(), ssh_userauth_list() returns also SSH_AUTH_METHOD_GSSAPI_MIC
  4. attempt to authenticate via ssh_userauth_gssapi(), which will fail because of (2)
  5. now any other ssh_userauth_*() will fail
asn added a subscriber: asn.Aug 6 2018, 10:48 AM

I think this got more or less fixed with: 83421c0e8cb30adfe9d459d74822a9bf7fdb99ba

However Anderson his patch handles the error correctly.