Advanced connection options#
Sherlock login nodes are regrouped behind a single DNS alias:
This alias provides a load-balanced login environment, and the assurance that you will be connected to the least loaded login node when you connect to Sherlock.
If for any reason, you want to directly connect to a specific login node and bypass the automatic load-balanced dispatching of new connections (which we don't recommend), you can use that login node's hostname explicitly. For instance:
$ ssh <sunetid>@ln21.sherlock.stanford.edu
This can be useful if you run long-standing processes on the login nodes, such as screen or tmux sessions. To find them back when you reconnect to Sherlock, you will indeed need to login to the same login node you started them on.
The drawback is that by connecting to a specific login node, you will forfeit the load-balancing benefits, which could result in a crowded environment, or even in login errors in case that specific login node is unavailable.
SSH public-key authentication is not supported on Sherlock.
The recommended way to authenticate to Sherlock is to simply use your SUNet ID and password, as described in the Connecting page.
Passwords are not stored on Sherlock. Sherlock login nodes will delegate password authentication to the University central Kerberos service.
For compatibility with previous generations of Sherlock, GSSAPI1 authentication is still allowed, and could be considered a more convenient option, as this mechanism doesn't require entering your password for each connection.
GSSAPI authentication relies on a token system, where users obtain Kerberos ticket-granting tickets, transmit them via SSH to the server they want to connect to, which will, in turn, verify their validity. That way, passwords are never stored locally, and never transit over the network. That's why Kerberos is usually considered the most secure method to authenticate.
To connect using GSSAPI on Sherlock, you'll need to go through a few steps2:
make sure the Kerberos user tools are installed on your local machine. You'll need the
kdestroy) utilities. Please refer to your OS documentation to install them if required.
download and install the Stanford
krb5.conffile, which contains information about the Stanford Kerberos environment:
$ sudo curl -o /etc/krb5.conf https://web.stanford.edu/dept/its/support/kerberos/dist/krb5.conf
configure your SSH client, by modifying (or creating if it doesn't exist already) the
.ssh/configfile in your home directory on your local machine. Using a text editor, you can add the following lines to your
~/.ssh/configfile (indentation is important):
Host login.sherlock.stanford.edu GSSAPIDelegateCredentials yes GSSAPIAuthentication yes
Once everything is in place (you only need to do this once), you'll be able to test that your Kerberos installation works by running
kinit <sunetid>@stanford.edu. You should get a password prompt, and upon success, you'll be able to list your Kerberos credentials with the
$ kinit email@example.com Password for firstname.lastname@example.org: $ klist Ticket cache: FILE:/tmp/krb5cc_215845_n4S4I6KgyM Default principal: email@example.com Valid starting Expires Service principal 07/28/17 17:33:54 07/29/17 18:33:32 firstname.lastname@example.org renew until 08/04/17 17:33:32
Kerberos ticket expiration
Kerberos tickets have a 25-hour lifetime. So you'll need to run the
kinit command pretty much once a day to continue being able to authenticate to Sherlock.
Please note that when your Kerberos ticket expire, existing Sherlock connections will not be interrupted. So you'll be able to keep connections open to Sherlock for several days without any issue.
You're now ready to connect to Sherlock using GSSAPI. Simply SSH as usual:
$ ssh <sunetid>@login.sherlock.stanford.edu
and if everything goes well, you should directly see the two-factor (Duo) prompt, without having to enter your password.
If you want to destroy your Kerberos ticket before its expiration, you can use the
OpenSSH offers a variety of configuration options that you can use in
~/.ssh/config on your local computer. The following section describe some of the options you can use with Sherlock that may make connecting and transferring files more convenient.
Avoiding multiple Duo prompts#
In order to avoid getting a second-factor (Duo) prompt every time you want to open a new connection to Sherlock, you can take advantage of the multiplexing features provided by OpenSSH.
Simply add the following lines to your
~/.ssh/config file on your local machine to activate the
ControlMaster option. If you already have a
Host login.sherlock.stanford.edu block in your configuration file, simply add the
Control* option lines in the same block.
Host login.sherlock.stanford.edu ControlMaster auto ControlPath ~/.ssh/%l%r@%h:%p
It will allow SSH to re-use an existing connection to Sherlock each time you open a new session (create a new SSH connection), thus avoiding subsequent 2FA prompts once the initial connection is established.
The slight disadvantage of this approach is that once you have a connection open to one of Sherlock's login nodes, all your subsequent connections will be using the same login node. This will somewhat defeat the purpose of the load-balancing mechanism used by the login nodes.
Connection failure with
If your connection fails with the following error message:
unix_listener: "..." too long for Unix domain socket
ControlPathline above by:
Connecting from abroad#
As a good security practice, we always recommend to use the Stanford VPN when connecting from untrusted networks.
Access to Sherlock is not restricted to campus, meaning that you can connect to Sherlock from pretty much anywhere, including when traveling abroad. We don't restrict inbound SSH connections to any specific IP address range or geographical location, so you shouldn't have any issue to reach the login nodes from anywhere.
Regarding two-step authentication, University IT provides alternate authentication options when phone service or Duo Mobile push notifications are not available.
The Generic Security Service Application Program Interface (GSSAPI, also GSS-API) is an application programming interface for programs to access security services. It allows program to interact with security services such as Kerberos for user authentication. ↩