Passwordless SSH login to research servers

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.  

Caveats for MacOS:

• The SSH client supplied with MacOS (at least through MacOS 12.6) strips the 'renewable' property from your credential before passing it to the remote server.  This means that it will expire at the same time as the original credential on your Mac, and cannot be extended by running krenew.  This limits the usefulness to short jobs, and in particular it cannot usefully be used to submit jobs to the Discovery scheduler.

 

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

  

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

 

 

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.