[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
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?
I'm the author of the original redmine task.
The setup is very easy:
- 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)
- the machine to which you are connecting to has no GSS/kerberos setup
- after ssh_userauth_none(), ssh_userauth_list() returns also SSH_AUTH_METHOD_GSSAPI_MIC
- attempt to authenticate via ssh_userauth_gssapi(), which will fail because of (2)
- now any other ssh_userauth_*() will fail