Passwordless SSH login to research servers

Tags ssh GSSAPI

Passwordless SSH login to remote servers is convenient for interactive users and often essential for automated tasks.  However, when the remote system uses Kerberos-authenticated storage, as is the case for both DartFS and RStor (AFS), the common method of key pairs does not work.  The problem is that a key pair is considered acceptable authentication for login, but carries no authentication for the file server which holds the home directory and data shares.  The symptom is a partially successful login, but "permission denied" on all attempts to read files in your home directory or any data share.

The solution is the software framework called GSSAPI (Generic Security Services Application Programming Interface).  The idea is that you authenticate on the client - typically the machine you are sitting at, and then SSH (or SFTP, SCP, SMB mount or other GSSAPI-enabled service) will pass your credential to the remote system, where it is checked and then used to log you in.  There are two features which must be enabled in any client program - which may be command line options, configuration file settings or preference menu settings, depending on the software.  They usually have the same names as the directives used in OpenSSH, described below.  

Supported clients (partial list)

  • Mac command line ssh, sftp, scp
  • Mac Fetch SFTP client
  • Windows PuTTY ssh client
  • Windows Tectia (ssh.com commercial offering)
  • Windows MobaXterm v20 or later.
  • Linux command line ssh, scp, sftp

Unsupported clients

  • Windows MobaXterm prior to v20
    • Unfortunately MobaXterm enables GSSAPIAuthentication by default, but older releases have no support for GSSAPIDelegateCredentials.  This makes it confusing.
  • Windows 10 Microsoft-supplied command line SSH
  • Windows SSH Secure Shell (ssh.com, legacy free client)

Note that if a client private key exists, it will be checked first, before considering GSSAPI or prompting for a password.  It may be necessary to use SSH client options to prevent use of keys with servers which cannot use them, while retaining them for other servers.  

Remote servers must also be prepared to use GSSAPI, by registering with the authentication server and storing a key which can be used to validate the credentials passed to them.  For services using active directory tickets (Dartmouth NetID), the common term for this is 'joining to the domain'.  For Windows clients to work, an Active Directory property must also be set for the server.

Client configuration details

Linux and Mac OpenSSH

You must obtain a credential first, using "kinit", before running ssh.  The ssh command line option "-K" can be used, or both of the following directives placed in the configuration file (~/.ssh/config):

GSSAPIAuthentication yes

This enables presenting the credential to the remote server to be used as authentication

GSSAPIDelegateCredentials yes

This enables passing a copy of the credential to the remote server to be used for subsequent access to other services - most commonly filesystem access.  

Windows PuTTY (domain-joined client)

  1. In the configuration menus, select Connection: SSH: Auth: GSSAPI
  2. Check "Attempt GSSAPI authentication"
  3. Check Allow "GSSAPI credential delegation"
  4. In the configuration menus, select Connection: Data
  5. Put your NetID into "Auto-login username", or check the "Use system username" for a domain-joined system.
  6. Save the configuration

PuTTY example configuration panel showing GSSAPI settings

  

Windows MobaXterm (domain-joined client)

  1. In the Settings menus for all sessions, select SSH
  2. Check the box GSSAPI Kerberos
  3. Select OK
  4. When setting up a particular SSH session, check Specify username and enter your NetID or leave it as <default> for a domain-joined system.
  5. Select OK

MobaXterm example configuration for setting GSSAPI

 

MobaXterm example configuration for setting default username

 

Non-domain-joined Windows clients

It is possible to use passwordless logins using PuTTY or MobaXterm on systems where you do not use your NetID for login (non-domain-joined).  However, you need to install some additional software to enable you to authenticate to the Dartmouth Active Directory manually.  Please contact Research.Computing for assistance.  This will be described in a future article.

 

Details

Article ID: 89203
Created
Fri 10/11/19 6:05 PM
Modified
Thu 7/9/20 11:40 AM

Related Articles (1)