Connect to Linux

These instructions are written primarily for users trying to log in to a CAC login node, taking linuxlogin as an example; however, the same methods should work for nearly any remote Linux machine. Note: If you are trying to connect to a Red Cloud Linux instance, please see the specific connection instructions in the documentation first. There are also troubleshooting steps to help you if you get stuck.

There are three distinct ways to connect to a remote Linux machine:

  1. Use SSH to open a Linux shell on a login node, which provides a text-only interface.
  2. Use SSH together with X-Windows, which sends any interactive graphics back to your machine window-by-window through an SSH tunnel.
  3. Use a remote desktop client to connect to a remote desktop with multiple text and graphics windows. VNC is the most common option, and we describe it below. However, using VNC is not as straightforward as it could be, due to the need to start up a vncserver and establish a secure tunnel to it first. An easier alternative is Microsoft Remote Desktop Client, but this requires "xrdp" to be installed and set up on the Linux server.

These instructions are intended mainly for users of personal computers and workstations. However, much of the material carries over to mobile computing platforms such as tablets and smartphones. You will have to locate and download an app to enable SSH or VNC connectivity; even a browser plug-in may suffice.

Whichever method you choose, at your first login, you will be challenged for a new password (this does not apply to Red Cloud resources). Find help at Change a Password at First Login.

Using Secure Shell

For basic command-line access, a Secure Shell (SSH) client will give you a remote command shell on one of the login nodes.

  • Nearly all Unix/Linux varieties (including Mac) already have a built-in SSH2 implementation, required by our clusters.
  • For Microsoft Windows machines, an SSH capable client is installed on Windows 10 and newer. For older versions of Windows, consider using PuTTY.
  • The non-secure predecessor of SSH, telnet, is disabled for security reasons.

To connect to the CAC general login node with ssh, you simply open a terminal:

  • Linux: open a terminal, e.g., xterm.
  • macOS: open the Terminal application by searching with cmd-space, or find it under Utilities in the Applications folder, or under Other in Launchpad.
  • Windows: open either the PowerShell application or Command Prompt (cmd) application by searching with the search box.

Once the terminal is open, you connect to the login node by typing: 

ssh <your_CAC_username>@linuxlogin.cac.cornell.edu

Alternatively, you can install a separate SSH client, as long as it supports the SSH2 protocol. For Windows, there are many different SSH clients to choose from. When choosing an SSH client, one consideration is how well other SSH-related tools are integrated, such as SCP (secure copy) and SFTP (secure file transfer protocol).

  • Bitvise is a client with an informative user interface that supports SSH, SFTP, and VNC.
  • MobaXterm has a free Home Edition. It gives you not just SSH, but integrated SFTP/SCP, X-Windows, VNC desktop, and quite a few other useful connectivity tools, all within one convenient client.
  • Token2Shell is a non-free commercial product available from the Microsoft Store. It provides SSH along with SFTP/SCP; however, it does not have X-Windows or VNC.
  • PuTTY is a great option despite the outdated design. It provides SSH, PSFTP client or PSCP command, X-Windows, VNC, and much more. See PuTTY for more details.

Using X-Windows

X-Windows (also called X11) is the longstanding Unix mechanism for displaying interactive graphics in a window. Your "X server" software runs locally, but it is capable of displaying windows that have been generated either locally or remotely. An "X client" on a remote machine can create X-Windows for local display, but it is necessary first to establish a shell on that machine using SSH.

Appropriate use:

Among other things, X-Windows gives you the ability to display a GUI that originates on a login node. However, this ability does NOT imply that you are permitted to run compute-intensive, GUI-driven applications on these machines. On linuxlogin, such usage is contrary to CAC policy. On other shared resources, it is disrespectful toward other users because the login node may become unresponsive through your actions.

Linux users:

The standard way to use X-Windows is to tunnel the X-Windows protocol through an ssh connection. If you open your ssh session with the -X option, it will automatically set up the necessary tunnel and environment variables.

localhost$ ssh -X <your_CAC_username>@linuxlogin.cac.cornell.edu
linuxlogin$ echo $DISPLAY
localhost:11.0
linuxlogin$ gs  # on another system, you want to might try a different X-capable client, like xterm

If all goes well, you should see a valid setting for your DISPLAY environment variable, then have a blank window presented to you by gs (Ghostscript, the PostScript and PDF previewer). If not, check the target system to make sure xorg-x11-xauth has been installed. Note, if gs is not installed on the machine you're logging into, you can try another X client such as xterm, xclock, xlogo, emacs, etc.

The -Y option is much like -X, but it uses a trusted version of X-windows forwarding.

cluster-login-node$ ssh -Y compute-1-37

When you're working on a cluster, the trusted (-Y) version is necessary for forwarding X11 connections in two steps: from a compute node to the login node, then back to your client machine.

Mac users:

In order to use X-Windows on a Mac, an X11 server needs to be installed on the system. The recommended X11 server for use on a Mac is provided by the XQuartz project. XQuartz used to be included with Mac OS X installations (versions 10.5 through 10.7), but is no longer included and must be downloaded and installed manually. After installing XQuartz, be sure to restart your Mac before using X11.

Once XQuartz is installed you should start ssh with the -X or -Y option, which will cause the X11 server to start automatically on your Mac. You can then try the "gs" test in the shell, as described above for Linux.

Windows users:

A few of the SSH clients mentioned above come with a bundled X server. Otherwise, along with your SSH client (e.g., the one in PowerShell or Command Prompt), you will generally need to install an X server on your Windows machine. Some of the possibilities are listed below. Once one of these is installed, you should open it, then type in either PowerShell or Command Prompt:

setx DISPLAY "localhost:0"

and restart the PowerShell or Command Prompt. After this, ssh -Y should cause the X11 server to start automatically in Windows. As a test, follow the same instructions as above for Linux and try running "gs" in your SSH session.

If the "gs" test fails, check to make sure xorg-x11-xauth has been installed on the target system. There are a couple of other things you can check as well:

  • Make sure you have specified ssh -X or ssh -Y as necessary.
  • Type echo %DISPLAY% in your shell to make sure this environment variable is set locally.

Here are some X servers that are available for you to install on your Windows machine.

  • VcXsrv - Open Source, and still being actively maintained. Works with Windows 10. Note that freeware solutions like this one can often work very well, but as always, the installation and use of such packages comes with no guarantees.
  • MobaXterm has a free Home Edition. It gives you not just SSH, but integrated SFTP/SCP, X-Windows, VNC desktop, and quite a few other useful connectivity tools, all within one convenient client.
  • X410 - Commercial product from the same company that produces Token2Shell, available from the Microsoft Store.
  • Xming - See Xming for more details.

A completely different approach is to install a self-contained Linux environment within Windows, then use standard Linux commands to start the X server.

  • Windows Subsystem for Linux (WSL), free from Microsoft, allows you to run Ubuntu or another popular Linux distro within Windows 10 or Windows Server 2019. This allows you to use command-line SSH, SFTP, and SCP plus many other useful Linux tools. You can even install and run a VNC client for Linux in WSL; the advantages of using a VNC remote desktop are described in the next section.
  • Cygwin/X is free and open-source. Like WSL, Cygwin is much more than just an X server; it actually creates an entire Linux-like environment within Windows. It includes an xterm within which you can run OpenSSH commands such as SSH, SFTP, and SCP. While it does not provide a VNC client, plenty of native-Windows VNC clients are available (see below).

When using one of these Linux environments within Windows, your environment variables should be set in the usual manner for Linux. For example, to set the DISPLAY variable, you would enter the following command (which you can add to your .bashrc):

    export DISPLAY=localhost:0

Likewise, you can type the Linux command echo $DISPLAY in your shell to make sure this environment variable is set locally.

Using a Remote Desktop Client

A remote desktop client lets you see a whole Linux desktop on a remote computer from your local computer. Connecting to Linux via SSH and X-Windows is efficient in that it uses a lot less of the remote computer's resources, but a remote desktop can be much faster if you are doing visualization on the remote computer from off campus. Below we describe two methods: Microsoft's Remote Desktop Protocol (RDP), and Virtual Network Connection (VNC).

Appropriate use

The ability to establish a remote desktop on a login node does NOT imply that you are permitted to run compute-intensive, GUI-driven applications on that particular machine. On linuxlogin, for example, such usage is contrary to CAC policy. On other shared resources, it is disrespectful toward other users because the login node may become unresponsive through your actions.

Here is a good example of how to use a remote desktop appropriately. By following these steps you can run (say) Abaqus in GUI-driven mode on a compute node that has been allocated to you through an interactive batch job.

  1. Open a connection to the login node using the instructions below, in order to gain access to a Linux desktop. Make sure two terminal windows are available on this desktop.
  2. In one of the terminal windows, submit an interactive job to the queue of your choice.
  3. Once the job starts, you will be given a command prompt on your assigned machine. Note the result of "hostname". There is no need to enter further commands at this prompt (except to exit the job).
  4. Go to the other terminal window and open a second ssh connection to the compute node using "ssh -Y <userid>@<hostname>"
  5. This new ssh session will tunnel X-Windows from the compute node back to the remote desktop. Therefore (if Abaqus is on your path), you can now open the Abaqus GUI using "abaqus cae -mesa".

Microsoft's Remote Desktop Protocol (RDP)

If the server has xrdp installed (linuxlogin currently does not), you may try connecting to the Linux server using one of the same clients you would use to connect to Windows. RDP clients are available for Windows, macOS, and Unix/Linux. To get started, simply connect to the IP address of the server and fill in your credentials.

Virtual Network Connection (VNC)

VNC is the more common type of remote desktop connection, but a bit more complicated. TigerVNC server has been installed on linuxlogin so you can try VNC there. If you would like to use VNC on a private cluster managed by CAC, please ask your PI to request the VNC installation. Note, a Linux desktop manager is a required part of a VNC installation; GNOME is often a good choice, as is xfce. The latter gives you a minimal desktop that is unlikely to have problems.

For security reasons, CAC requires all VNC connections to be tunneled inside ssh. You will therefore need to be able to connect to the remote computer using SSH. The firewalls running at CAC for all login nodes (e.g., linuxlogin) commonly block all incoming ports except for ssh, so VNC connections must be made over a ssh tunnel as described below.

Local setup for all platforms

  • Install a local VNC client on your local machine if one isn't installed already. For Linux, TigerVNC is a popular choice, as is Remmina. On Mac, you can use the built-in Screen Sharing or install the RealVNC app. For Windows, TightVNC or RealVNC works well, but so do others.

  • The following instructions do not apply to NoMachine/NX, which is an entirely different, proprietary way of connecting to a Linux desktop, available for all three platforms (after purchasing a license).

Starting your remote VNC server (do these steps from an ssh shell)

  • Use ssh to log in to the remote Linux computer.
  • Set the password for your VNC server using the vncpasswd command.
  • Start the VNC server using the vncserver command like this:
    vncserver -geometry 1600x900 -localhost

The geometry numbers 1600x900 (or other numbers of your choosing) specify the size of the desktop in pixels.

  • You will need to get the display number from the output of the vncserver command:

    New 'linuxlogin.cac.cornell.edu:1 (shl1)' desktop is linuxlogin.cac.cornell.edu:1
Starting applications specified in /home/fs01/shl1/.vnc/xstartup
Log file is /home/fs01/shl1/.vnc/linuxlogin.cac.cornell.edu:1.log

  • vncserver is running on port 5900 + display number. In the above example, the display number is :1, therefore vncserver is running on port 5901.

Set up your ssh tunnel (Do these steps on your local computer)

Let's say the port number on linuxlogin is 5901 (as above), and your CAC userid is uid12. Here's what to do to start ssh port forwarding, or tunneling, to that port.

  • From Linux, if you are still in the same ssh session you used to start vncserver, type ~ then C to get to an ssh> prompt, then enter:
    -L 10000:localhost:5901

Or you can type the following full command into a local terminal, which opens another ssh session including the tunnel:

ssh -L 10000:localhost:5901 uid12@linuxlogin.cac.cornell.edu
  • From macOS, open a Terminal and follow one of the Linux methods shown above.
  • From Windows, open a PowerShell or Command Prompt and follow one of the Linux methods shown above. Other ssh clients such as PuTTY can also do port forwarding (tunneling); for specific information about PuTTY, see the PuTTY and Xming page.
  • Leave this ssh session running on your local client computer. (It can run in the background)

Connect your VNC client

To disconnect your client

  • Close the VNC client program.
  • Disconnect the ssh forwarding session (i.e., kill it).

To reconnect your client

  • Restart port forwarding with ssh, using the same remote port number as before.
  • Again connect the VNC client to localhost:10000.

When you are all done

  • It may not be possible to to log out from the Linux desktop. But even if this appears to work, it will leave the VNC server running.
  • When you are finished with your session, shut down all your applications in the desktop, disconnect (close) it, and type this command into a separate ssh session to shut down the VNC server completely:
    vncserver -kill :<display number>

Public Key Authentication

An alternative to password-based authentication is public key authentication (PKA). SSH has a well-established mechanism for making use of a public/private key pair.

Note: setting this up for yourself is completely optional! On CAC private clusters where an SSH key pair is required for intra-cluster communications, one will be created for you when first log in to the head node, and you never need to worry about it.

How it works

  • When you connect via SSH, instead of entering a password, you provide the name of an identity file on your computer. This is your private key, part of a public/private key pair.
  • The computer you are connecting to must already have the matching public key stored in a special location. On Linux systems, it should be found among the list of public keys in the file ~/.ssh/authorized_keys.
  • Upon receiving your initial SSH request, the remote computer encrypts a message using one of the public keys in ~/.ssh/authorized_keys. It sends the encrypted message to your computer.
  • Your local SSH client attempts to decrypt this message using the private key file you specified. The decrypted message is then sent back to the remote computer.
  • The remote computer checks whether your client succeeded in decrypting the message. If so, you have proven your identity. If not, it tries the next public key until all are exhausted.

Clearly, if you want to make use of this mechanism, you will need to set up a public/private key pair!

Create an SSH key pair

Your ssh key pair will only need to be created once. You will not need to repeat this step. You can complete this step from linuxlogin.cac.cornell.edu, the general Linux login node, or from the login node of a private cluster. (If this is your first login to a CAC login node, it will ask you to change your password; this will become your password for connecting to CAC login nodes in the future.) Note that when you create a key pair, you will be prompted to protected your private key with a passphrase. This is an optional step that we will skip below, but an unprotected private key is not as secure and generally not recommended. The steps to create your key pair, and to store the public key where it can be used for future logins, are as follows:

mkdir .ssh
chmod 700 .ssh
cd .ssh
ssh-keygen (and take all default options)
cat id_rsa.pub >> authorized_keys

As a final step, you need to copy the private key, which is stored in the file id_rsa, to the computer that you will be logging in from.

Linux and macOS users:

You'll want to put the private key in the ~/.ssh directory. You may wish to call the key file id_rsa for convenience, BUT be careful not to overwrite an existing file with that name. Let's say you decide instead to call your new private key file cac_id_rsa on your local computer, just to be safe. You MUST change permissions on this file to keep it private:

chmod 600 ~/.ssh/cac_id_rsa

Now you're ready to use your private key to connect to linuxlogin. From a terminal in macOS or Linux, you do the following:

ssh -i ~/.ssh/cac_id_rsa <your_CAC_username>@linuxlogin.cac.cornell.edu

Windows users:

You'll also want to put the file with your private key in the .ssh directory. However, it's not as straightforward as in Linux or macOS. First, open the Notepad or Notepad++ app and paste your private key into a new file. Then, save the file in C:\Users\<YOUR_USERNAME>\.ssh and call your private key file cac_id_rsa. (If the .ssh folder does not already exist, make one with mkdir in Command Prompt or New-Item in PowerShell.)

Next, type ls ~/.ssh (PowerShell) or dir %userprofile%/.ssh (Command Prompt) to confirm that the new file exists. You may see that the file with your key is now named cac_id_rsa.txt instead (because Notepad attaches the .txt extension even without being instructed). To change the name of the file in PowerShell, enter:

ren ~/.ssh/cac_id_rsa.txt cac_id_rsa

or for Command Prompt:

ren C:\Users\<YOUR_USERNAME>\.ssh\cac_id_rsa.txt cac_id_rsa

and confirm the file now has no extension.

Now you're ready to use your private key to connect to linuxlogin. From either PowerShell or Command Prompt, type: 

ssh -i ~/.ssh/cac_id_rsa <your_CAC_username>@linuxlogin.cac.cornell.edu

ssh -i C:\Users\<YOUR_USERNAME>\.ssh\cac_id_rsa <your_CAC_username>@linuxlogin.cac.cornell.edu