Connecting for the first time¶
All connections to OLCF resources are done via Secure Shell (SSH). SSH encrypts the entire session between the user connecting and the OLCF systems and avoids risks associated with using plain-text communication.
To access OLCF systems, your SSH client must support SSH protocol version 2 (this is common) and allow keyboard-interactive authentication.
For UNIX-based SSH clients, the following line should be in either the default
ssh_config file or your
The line may also contain other authentication methods but
keyboard-interactive must be included.
SSH clients are available for Windows-based systems, such as SecureCRT published by VanDyke software. For recent SecureCRT versions, the preferred authentication setting shown above can be made through the “connection properties” menu.
SSH multiplexing is disabled on all of the OLCF’s user-facing systems.
Users will receive an error message if they attempt to connect to an OLCF
resource that tries to reuse an SSH control path. To ensure SSH connections will
not attempt multiplexing, you will need to modify your
file by adding the following:
Host *.ccs.ornl.gov ControlMaster no
With an active user account, you’ll be able to log into any of the systems allocated to your project(s). All OLCF resources (except the Ascent training system) require two-factor authentication. This means you will need an OLCF-provided RSA SecurID fob to log into any of the systems.
For Windows clients, PuTTY and MobaXterm can also be used to provide SSH capability. Recent updates to Windows 10 have added built-in support for SSH. If it is not installed on your version of Windows, please refer to Microsoft’s documentation on OpenSSH.
Activating a new SecurID fob¶
When you first recieve your OLCF RSA SecurID fob, it will be deactivated and unusable. In order to have your RSA SecurID fob activated, you must return a notarized copy of the Notary Token Verification Form or otherwise have your identity verified by the OLCF (See Notary Instructions).
- Initiate a SSH connection to
- When prompted for a PASSCODE, enter the 6-digit code shown on the fob.
- You will be asked if you are ready to set your PIN. Answer with “Y”.
- You will be prompted to enter a PIN. Enter a (4) to (6) digit number you can remember. You will then be prompted to re-enter your PIN.
- Allow the 6-digit code to change (codes regenerate every 30 seconds). Once the (6) digits on your fob change, enter your PIN followed by the new (6) digits displayed on the fob.
- Your PIN is now set, and your fob is activated for login to other OLCF systems.
Once activated, the RSA SecurID fob can be used to access OLCF systems.
When initiating a SSH connection to a system, you will be prompted to
enter your PASSCODE. Simply enter your PIN followed by the (6) digit
code shown on your SecurID fob and press enter. For example, if your pin
1234 and the (6) digits on the fob are
000987, you would
1234000987 when prompted for a PASSCODE.
The 6-digit code displayed on the SecurID fob can only be used once. If prompted for multiple PASSCODE entries, always allow the code to change between attempts. Re-using a code can cause your account to be automatically locked.
If you are an ORNL employee and are using an ORNL-distributed (not OLCF-distributed) SecurID fob, there is no need to follow the activation steps listed above. You may log into OLCF systems using your existing ORNL PIN + 6-digit tokencode.
PINs, Passcodes, and Tokencodes¶
When users connect with RSA SecurID tokens, they are most often prompted for a PASSCODE. Sometimes, they are instead prompted for a PIN (typically only on initial setup) and other times they might be prompted to wait for the tokencode to change and enter the new tokencode. What do these terms mean?
TOKENCODE is the 6-digit number generated by the RSA token.
PIN is a (4) to (8)-digit number selected by the user when they
initially set up their RSA token.
PASSCODE is simply the user’s PIN followed by the current tokencode.
These are relatively straightforward; however, there can be some confusion on initial setup. The first time a user connects with a new token (or, if for some reason the user requested that we clear the PIN associated with their token) they are prompted for a PASSCODE but in reality only enter a tokencode. This is because during this initial setup procedure a PIN does not exist. Since there is no PIN, the PASSCODE is the same as the tokencode in this rare case.
Automatic forwarding of the X11 display to a remote computer is possible with the use of SSH and a local (e.g. on your desktop) X server. To set up automatic X11 forwarding within SSH, you can do one of the following:
1) Invoke ssh on the command line with:
$ ssh -X hostname
Note that use of the -x option (lowercase) will disable X11 forwarding.
2) Edit (or create) your
$HOME/.ssh/config file to include the following line:
All X11 data will go through an encrypted channel. The
variable set by SSH will point to the remote machine with a port number greater
than zero. This is normal, and happens because SSH creates a proxy X server on
the remote machine for forwarding the connections over an encrypted channel. The
connection to the real X server will be made from the local machine.
Users should not manually set the
$DISPLAY environment variable for X11
forwarding; a non-encrypted channel may be used in this case.
Systems Available to All Projects¶
OLCF System Hostnames¶
|System Name||Full Hostname||Hostkey Fingerprints|
|Data Transfer Nodes||
|Moderate-Enhanced Enclave Login Node||
Occassionally, you may receive an error message upon logging in to a system such as the following:
@@ 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 the RSA host key has just been changed.
This can be a result of normal system maintenance that results in a changed RSA public key, or could be an actual security incident. If the RSA fingerprint displayed by your SSH client does not match the OLCF-authorized RSA fingerprint (shown in the table above) for the machine you are accessing, do not continue authentication; instead, contact firstname.lastname@example.org.