Connecting to Sherlock #

Credentials#

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.

Connection#

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>@login.sherlock.stanford.edu

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 'login.sherlock.stanford.edu' 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 'dtn.sherlock.stanford.edu' 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:

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 sherlock.stanford.edu alias, you will be presented with the following message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for sherlock.stanford.edu has changed, and the key for
the corresponding IP address 171.66.97.101 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.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
SHA256:T1q1Tbq8k5XBD5PIxvlCfTxNMi1ORWwKNRPeZPXUfJA.
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 sherlock.stanford.edu entry from your ~/.ssh/known_hosts file with the following command on your local machine:

$ ssh-keygen -R sherlock.stanford.edu

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.

Authentication#

Password#

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

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

<sunetid>@login.sherlock.stanford.edu'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):

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

Success. Logging you in...

Troubleshooting#

Timeouts#

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

$ ssh login.sherlock.stanford.edu
ssh: connect to host login.sherlock.stanford.edu 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#

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 login.sherlock.stanford.edu port 22: Connection refused

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

Login#

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
  https://doresearch.stanford.edu/policies/research-policy-handbook and
  https://adminguide.stanford.edu/chapter-6/subchapter-2/policy-6-2-1
-----------------------------------------------------------------------------
  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 https://uit.stanford.edu/guide/riskclassifications for details.
-----------------------------------------------------------------------------

        Docs         https://www.sherlock.stanford.edu/docs
        Support      https://www.sherlock.stanford.edu/docs/#support

        Web          https://www.sherlock.stanford.edu
        News         https://news.sherlock.stanford.edu
        Status       https://status.sherlock.stanford.edu

-----------------------------------------------------------------------------

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.

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.