Skip to content

Connecting to Sherlock #

Sherlock account required

To be able to connect to Sherlock, you must first obtain a Sherlock account.


All users must have a Stanford SUNet ID and a Sherlock account to log in to Sherlock. Your Sherlock account uses the same username/password as your SUnet ID:

Username: SUNet ID
Password: SUNet ID password

To request a Sherlock account, please see the Prerequisites page.

Resetting passwords

Sherlock does not store your SUNet ID password. As a consequence, we are unable to reset your password. If you require password assistance, please see the SUNet Account page.


Access to Sherlock is provided via Secure Shell (SSH) login. Most Unix-like operating systems provide an SSH client by default that can be accessed by typing the ssh command in a terminal window.

To login to Sherlock, open a terminal and type the following command, where <sunetid> should be replaced by your actual SUNet ID:

$ ssh <sunetid>

Upon logging in, you will be connected to one of Sherlock's load-balanced login node. You should be automatically directed to the least-loaded login node at the moment of your connection, which should give you the best possible environment to work.

Host keys#

Upon your very first connection to Sherlock, you will be greeted by a warning such as :

The authenticity of host '' can't be established.
ECDSA key fingerprint is SHA256:eB0bODKdaCWtPgv0pYozsdC5ckfcBFVOxeMwrNKdkmg.
Are you sure you want to continue connecting (yes/no)?

The same warning will be displayed if your try to connect to one of the Data Transfer Node (DTN):

The authenticity of host '' can't be established.
ECDSA key fingerprint is SHA256:eB0bODKdaCWtPgv0pYozsdC5ckfcBFVOxeMwrNKdkmg.
Are you sure you want to continue connecting (yes/no)?

This warning is normal: your SSH client warns you that it is the first time it sees that new computer. To make sure you are actually connecting to the right machine, you should compare the ECDSA key fingerprint shown in the message with one of the fingerprints below:

Key type Key Fingerprint
legacy format: f5:8f:01:46:d1:f9:66:5d:33:58:b4:82:d8:4a:34:41
ECDSA SHA256:eB0bODKdaCWtPgv0pYozsdC5ckfcBFVOxeMwrNKdkmg
legacy format: 70:4c:76:ea:ae:b2:0f:81:4b:9c:c6:5a:52:4c:7f:64

If they match, you can proceed and type ‘yes’. Your SSH program will then store that key and will verify it for every subsequent SSH connection, to make sure that the server you're connecting to is indeed Sherlock.

Host keys warning#

If you've connected to Sherlock 1.0 before, there's a good chance the Sherlock 1.0 keys were stored by your local SSH client. In that case, when connecting to Sherlock 2.0 using the alias, you will be presented with the following message:

The RSA host key for has changed, and the key for
the corresponding IP address is unknown. This could
either mean that DNS SPOOFING is happening or the IP address for the
host and its host key have changed at the same time.
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!  It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.

You can just check that the SHA256 key listed in that warning message correctly matches the one listed in the table above, and if that's the case, you can safely remove the entry from your ~/.ssh/known_hosts file with the following command on your local machine:

$ ssh-keygen -R

and then connect again. You'll see the first-connection prompt mentioned above, and your SSH client will store the new keys for future connections.



To ease access and increase compatibility1 with different platforms, Sherlock allows a simple password-based authentication mechanism for SSH.2.

Upon connection, you will be asked for your SUNet ID password with the following prompt:

<sunetid>'s password:

Enter your password, and if it's correct, you should see the following line:

Authenticated with partial success.

Second factor (2FA)#

Sherlock implements Stanford's Minimum Security Standards policies which mandate two-step authentication to access the cluster.

Two-step authentication protects your personal information and credentials by combining something only you know (your password) with something only you have (your phone, tablet or token). This prevents an attacker who would steal your password to actually use it to impersonate you. For more details about two-step authentication at Stanford, please refer to the University IT two-step page.

After successfully entering your password, you'll be prompted for your second authentication factor with a message like this:

Duo two-factor login for <sunetid>

Enter a passcode or select one of the following options:

 1. Duo Push to XXX-XXX-9999
 2. Phone call to XXX-XXX-9999
 3. SMS passcodes to XXX-XXX-9999 (next code starts with: 9)

Passcode or option (1-3):

Avoiding two-factor prompt on each connection

If you routinely open multiple sessions to Sherlock, having to confirm each one of them with a second authentication factor could rapidely become cumbersome. To work around this, the OpenSSH client allows multiplexing channels and re-using existing authenticated for opening new sessions. Please see the Advanced Connection Options page for more details.

If your second factor is accepted, you'll see the following message:

Success. Logging you in...



If you ever encounter timeout errors when connecting to Sherlock, like these:

$ ssh
ssh: connect to host port 22: Operation timed out

you can try to either:

  • switch to a wired connection if you're connecting over wifi,
  • connect via the Stanford VPN

Authentication failures#

Excessive authentication failures

Entering an invalid password multiple times will result in a (temporary) ban of your IP address.

To prevent brute-force password guessing attacks on Sherlock login nodes, we automatically block IP addresses that generate too many authentication failures in a given time span. This results in a temporary ban of the infringing IP address, and the impossibility for the user to connect to Sherlock from that IP address.

When this happens, your SSH connection attempts will result in the following error:

ssh: connect to host port 22: Connection refused

IP blocked by this mechanism will automatically be authorized again after a few minutes.

SSHFS on macOS

SSHFS on macOS is known to try to automatically reconnect filesystem mounts after resuming from sleep or uspend, even without any valid credentials. As a result, it will generate a lot of failed connection attempts and likely make your IP address blacklisted on login nodes.

Make sure to unmount your SSHFS drives before putting your macOS system to sleep to avoid this situation.


If your IP got blocked and you have an urgent need to connect, before the automatic blacklist expiration, we recommend trying to connect through Stanford's VPN: your computer will then use a different IP address and will not be affected by the ban on your regular IP address.


Congratulations! You've successfully connected to Sherlock. You'll be greeted by the following message of the day:

             --*-*- Stanford Research Computing Center -*-*--
                  ____  _               _            _
                 / ___|| |__   ___ _ __| | ___   ___| | __
                 \___ \| '_ \ / _ \ '__| |/ _ \ / __| |/ /
                  ___) | | | |  __/ |  | | (_) | (__|   <
                 |____/|_| |_|\___|_|  |_|\___/ \___|_|\_\

  This system is for authorized users only and users must comply with all
  Stanford computing, network and research policies. All activity may be
  recorded for security and monitoring purposes. For more information, see and
  Sherlock is *NOT* approved for storing or processing HIPAA, PHI, PII nor
  any kind of High Risk data. Users are responsible for the compliance of
  their data.
  See for details.




Once authenticated to Sherlock, you'll see the following prompt:

[<sunetid>@sh03-ln01 login! ~]$

It indicates the name of the login node you've been connected to, and a reminder that you're actually connected to a login node, not a compute node.

Login nodes are not for computing

Login nodes are shared among many users and therefore must not be used to run computationally intensive tasks. Those should be submitted to the scheduler which will dispatch them on compute nodes.

By contrast, the shell prompt on a compute node looks like this:

[<sunetid>@sh03-01n01 ~]$

Start computing#

To start computing, there's still a extra step required, which is requesting resources to run your application. It's all described in the next section.

  1. On Sherlock 1.0, GSSAPI tokens (based on Kerberos tickets) were the only allowed authentication method, which could cause some interoperability with third-party SSH clients. 

  2. For other methods of authentication, see the Advanced Connection Options page.