Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

SSH passwordless login

From Livedoc - The Documentation Repository
Jump to: navigation, search

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.

Configuration

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.