Tested on 3.9p1 - code inspection shows the same issue in 4.x I have gss_auth setup on both ends. Works fine. I decide that I need to ssh to the server as a differnet user. So I do ssh notme@<host> Then a) I get prompted for a password for notme and log in ok b) the credential cache is set to krb5cc_<uid>_xxxx and is loaded my originating credentials, even though I am not logged on as that principal This is very surprising The reason is that kuserok is called right at the end of auth, the creds have been forwarded and sshd is ready to set up the logged in users' envirnment; ten right at the last moment we decide not to allow gss to work - but sshd still stores the creds it has one line fix to this. In ssh_gssapi_krb5_userok, after failure do krb5_free_creds(krb_context, client->creds); this blows the forwarded creds away and so storecreds (called later ) does nothing
Created attachment 951 [details] Delete delegated credentials if userok call fails
Unfortunately, you can't (safely and portably) just call krb5_free_creds on the client->creds structure, as its a pointer to a GSSAPI structure, which will not necessarily be the same (or managed by the same allocator) as the underlying Kerberos one. I believe that the attached patch should solve the problem.
Comment on attachment 951 [details] Delete delegated credentials if userok call fails >+ gss_release_buffer(&lmin, &gssapi_client.displayname); >+ gss_release_buffer(&lmin, &gssapi_client.exportedname); >+ gss_release_cred(&lmin, gssapi_client.creds); shouldn't that be &gssapi_client.creds?
Created attachment 952 [details] Fix arg to gss_release_cred Like this
Comment on attachment 951 [details] Delete delegated credentials if userok call fails Indeed it should be - good catch. Obsoleting older patch.
Fix applied, will be in the imminent release (4.2)
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.