SSH passwordless login

Overview
SSH passwordless login is set up on all CSL workstationsand the remote access server, to connect to different machines without having to type in your password. This is achieved using GSSAPI and Kerberos.

Common Problems
Here are some common problems, and how to fix them.

Disconnecting: Protocol error: didn't expect packet type 34
This is usually the result of an error in GSSAPI. Run ssh again with the "-v" option. If the message debug1: Delegating credentials debug1: Received Error debug1: GSSAPI Error: Miscellaneous failure Wrong principal in request appears, then it means you are probably trying to connect to a service IP address. "Wrong principal in request" means (I think) that the server tried to contact a Kerberos KDC from a different IP than the IP you tried to access. GSSAPI does not seem to work with service IPs.

No AFS tokens, but successful login
If you have Kerberos tickets, as well (run "klist" to see), but no AFS tokens, then sshd might be running with UsePrivilegeSeparation turned on. Set it to "no" in /etc/ssh/sshd_config, and restart the ssh server.

Prompted for a password
For some reason GSSAPI is either not being used, or is failing. Run ssh with the "-vvv" option, and look around for output like this (right after the "banner" displays): debug3: preferred gssapi-with-mic,publickey,gssapi,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,gssapi,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic This represents that ssh is trying to use the gssapi-with-mic authentication method. If you don't see anything like this, check the local ssh_config and the user's personal .ssh/config to see if they are changing their PreferredAuthentications to something without GSSAPI.

If it is trying to use GSSAPI, then look for other error messages. You can also try looking for errors on the KDC to see if there's an error with the tickets (such as if they are not forwardable for some reason). Also check to see if the user's tickets are forwardable by running "klist" with the "-f" switch, and look for the F flag by the user's tickets.

One known error is if the user logs into the system with capital letters, they will be able to log in, but GSSAPI will fail.

GSSAPI not offered
If you see something similar to: debug1: Authentications that can continue: publickey,keyboard-interactive then the server may not be configured to use GSSAPI. Check that /etc/ssh/sshd_config has the following: GSSAPIAuthentication yes GSSAPICleanupCredentials yes

The following line may cause sshd to fail and fall back to older configuration, as the option is not recognized by newer ssh servers: GSSAPIStrictAcceptorCheck no If this is happening, make sure to remove this line.