Using SSH

SSH stands for Secure Shell. It allows you to remotely connect to our login nodes and Spear servers and interact with our services via the command-line. This is the primary way that most people use our services.

Commonly Accessed Servers

HPC Login Node:

ssh [username]

Spear Servers (with optional -Y parameter for X11 Forwarding):

ssh -Y [username]

SSH from Mac or Linux

Both Mac and Linux operating systems allow you to use SSH directly from the command-line. Locate and run the Terminal application, and use the syntax above to connect to our systems. To disconnect, simply type exit.

SSH from Windows

Windows systems do not have built-in support for SSH, so you must install a third-party software package to connect to our systems. PuTTY is the most popular open source (ie free) SSH client for Windows. To install it, visit the download site, and download the Installer package.

Once installed, find the PuTTy application shortcut in your Start Menu, desktop, or in the Windows 8 start screen. The PuTTy Configuration dialog should appear:

Locate the Host Name input box in the PuTTy Configuration screen. Enter the server name you wish to connect to (e.g. [username], and click Open. Enter your password when prompted, and press Enter. You are now connected!

Using SSH Keys

By default, when connecting via SSH, you use your RCC password to login. There is a more secure and potentially more convenient way to login, however, by using SSH keys. To use SSH keys, you must first create a keypair, which consists of two files, a private key and a public key. The public key is uploaded to our servers to identify you and the private key is kept on your computer. You never share your private key with anybody, but you do need it to login.

Setting up a Keypair (Mac/Linux)

Before using SSH keys, you must generate a keypair. If you are on Linux or Mac, you can do this directly on your system by using the Terminal application and then typing the following command:

ssh-keygen -t rsa

Once you type this command, you will see a message similar to the following:

Enter file in which to save the key (/home/YOU/.ssh/id_rsa):

You can simply press <ENTER> to continue. Then, you will see:

Enter passphrase (empty for no passphrase):

You may enter a passphrase, but this is optional. If you do use a passphrase, you will be required to enter it before using your key to connect to the server. This is not the same as password authentication, though. The passphrase is used to unlock your private key; it is never transferred across the network. The benefit to using a passphrase is that it protects your private key in case anybody ever gets access to the file.

Once you complete these steps, you should see something similar to the following:

Your identification has been saved in /home/YOU/.ssh/id_rsa.
Your public key has been saved in /home/YOU/.ssh/
The key fingerprint is:
4a:dd:0a:c6:35:4a:3f:ed:24:38:8f:74:44:4d:93:63 YOU@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|     + .     o   |
|     . = = .     |
|      = = .      |
|     o + S = +   |
|      . o + o .  |
|           . o   |
|                 |

This creates two files on your computer, a public key (stored in ~/.ssh/ and a private key (stored in ~/.ssh/id_rsa).

Copying your Public Key to the Server (Mac/Linux)

Once you have created a keypair, you now need to copy your public key to the RCC server. The following command reads your public key file and transfers it over SSH to the correct location inside your home directory on our server:

cat ~/.ssh/ | ssh "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

You will be prompted for your RCC password when you run this command. However, once you complete this command, you should now be able to login to the server using your key instead of a password. Try it:


If you specified a passphrase when you created your keypair, you may be prompted for that. If you did not, you should be automatically logged-in.

You can repeat this process for any of our servers (e.g or any SKY servers you create.

SSH Keys on Windows

Depending on which client SSH application you are running, there are different ways to generate and upload PKI keys from Windows. We recommend using PuTTy, and there is a very good step-by-step guide in the official PuTTY documentation.

Server Signatures

The first time that you connect to one of our servers, your client will ask you to confirm the host key.  This is a security measure to prevent man-in-the-middle attacks.  All of our servers expose the same RSA, DSA, and ECDSA keys.  You can check the host key against the reference below to ensure that you are connecting to one of our servers.

MD5 Signatures

2048 MD5:c0:6a:38:02:ee:ec:a1:4b:65:2a:c1:c2:f9:0a:9e:91(RSA)
256 MD5:b6:77:3f:69:39:0c:9b:e3:51:9e:73:31:a3:64:83:3f (ECDSA)
256 MD5:b0:90:b1:1f:31:fb:4b:fa:be:97:e2:82:90:f6:f9:e3 (ED25519)
1024 MD5:42:e6:e9:8b:73:27:44:3f:5d:2e:5f:04:43:1d:35:a5 (DSA)

SHA256 Signatures

2048 SHA256:al+ouqhHedLLmtLrCu/Wr3k/u6FTDaCtfKv03gLkWoc (RSA)
256 SHA256:9zOowqoXMGNIGJ0gsCLJ5YmMxk37HOikhsRrGvapU6s (ECDSA)
256 SHA256:OdDmdK7PRmQXgwOpVbWWC/EPE1fg9H0mlsL0m3H9JKI (ED25519)
1024 SHA256:uClXRvMe8owMilTjhjdyM+TlvpFML9FGA53SWwtFwY4 (DSA)

Connection Problems?

The most common connection problem is for off-campus access. For security reasons, you must use the FSU VPN to connect to any of our systems from off-campus. See our documentation for how to do so.

For other errors, see below. If this guide does not address your issue, you should submit a support ticket, and we will assist you.

Changed Host Keys

Very occasionally, the SSH host keys for our servers change. This used to occur fairly often, but in August, 2016, we started using consistent server signatures, so it happens less frequently now. Server configuration issues can cause this problem as well. The solution is to:

  1. verify the new host key is legitimate, and
  2. remove the old cached host key on your client.

If you attempt to login to a server via SSH and receive a messge simliar to the following, that means our server host key has likely changed:

Add correct host key in /home/jdoe/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/jdoe/.ssh/known_hosts:19
RSA host key for *** has changed and you have requested strict checking.
Host key verification failed.

On Ubuntu or Debian systems, the message may look even scarier:

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.
The fingerprint for the RSA key sent by the remote host is
------------------------(RSA key)
Please contact your system administrator.
Add correct host key in /home/jdoe/.ssh/known_hosts to get rid of this message.
Offending key in /home/jdoe/.ssh/known_hosts:19
RSA host key for 'my IP' has changed and you have requested strict checking.
Host key verification failed.

On other clients, you may simply see a message that states:

Warning: Host Identification has Changed!

Remove the old key

You will need to manually remove your copy of the host key before you attempt to reconnect. Take note of the following line in the warning output in the warning message above:

Offending RSA key in /home/jdoe/.ssh/known_hosts:19

Open the known_hosts file in your favorite text editor (hint: it is a hidden file), and remove the offending line. In this example, you would open /home/jdoe/.ssh/known_hosts and delete line 19.

Save the file and attempt to reconnect. You will need to manually approve the new host key the first time you connect:

The authenticity of host ' (' can't be established.
RSA key fingerprint is c0:6a:38:02:ee:ec:a1:4b:65:2a:c1:c2:f9:0a:9e:91.
Are you sure you want to continue connecting (yes/no)? yes

Ensure that the new key is not a security exploit attempt

Before you approve the request to connect, ensure that the host key shown in the message matches our server key.  If it does not, please let us know; you may be seeing an attempted security exploit.  Refer to the Server Signatures section above to compare the key your client sees with our keys.