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.

If you're unfamiliar with SSH, you might want to check out this LinkedIn Learning overview video.

Commonly Accessed Servers

HPC Login Node:

ssh [username]

Spear Servers:

ssh [username]

SSH from Windows, Mac, or Linux

All modern operating systems (Mac, Windows, and Linux) allow you to use SSH directly from the command-line. Locate and run the Terminal (Mac/Linux) or Command Line (Windows) application, and use the syntax above to connect to our systems. To disconnect, simply type exit.

Using Graphical Programs with SSH on Windows

Although basic SSH functionality is supported out-of-the-box in Windows 10, if you want to use interactive programs with a graphical user interface over SSH on Windows, you can use MobaXTerm.

MobaXTerm is a simple but powerful SSH client with graphical capabilities for Windows. It has both a Free and a Paid licensed version. The software features a built-in X11 windows server which is required for using graphical applications. A detailed demonstration for how to use MobaXTerm is available on the vendor's website.

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 should never share your private key with anybody, but you do need it to login.

Setting up a Keypair

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 (Mac/Linux) or Command Line (Windows) 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/Windows*)

* for Windows, you'll need to use the PowerShell app for this syntax to work.

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.

Because we have a shared filesystem across most of our systems, you should be able to login to most RCC services via PKI (passwordless) authentication from now on.

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.