1. Home
  2. Docs
  3. General Computing Environment
  4. SSH

SSH

SSH authentication to GCE hosts is primarily done with the use of SSH keys. It is required that SSH keys in the GCE use strong passphrases.

If you haven’t already, please read up on login, compute, and home nodes you will use in GCE.

Creating SSH Keys:

Generate a pair of SSH keys with the following command, in this example we create an 4096bit RSA key.  You should use a minimum of 2048 for an RSA key.

# ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/USER/.ssh/id_rsa): /Users/USER/.ssh/GCE_id_rsa

(You can change the name of the ssh key here and is useful if you have several keys)

Enter passphrase (empty for no passphrase):

(A strong passphrase is required)

Enter same passphrase again:

(Repeat the strong passphrase)

Your identification has been saved in /Users/USER/.ssh/GCE_id_rsa.

(This is your private key. Keep it secure, do not share it, and be cognizant of where you store it.)

Your public key has been saved in /Users/USER/.ssh/GCE_id_rsa.pub.
The key fingerprint is:
SHA256:lSglfiIzcdJumCtz1RI03sulFJ3pA3hZcFMbPPEY14Y USER@machine.cels.anl.gov

(This is your public key.)

After you generate your SSH key pair, add ONLY the public key to your account at https://accounts.cels.anl.gov.

  • Copy the contents of the .pub file generated above (in the example above, ~/.ssh/GCE_id_rsa)
  • Choose “Add Key” at the bottom of the Account Information page after login.
  • Paste what you copied into the “Key” section that appears.  The “Description” is purely informational and allows you to give it a meaningful or memorable name/description for future reference.

You will then be able to SSH to “home nodes” and “compute nodes” directly while on a trusted internal network.

SSH from offsite

The recipe below will let you trivially SSH to home nodes, compute nodes, or even your GCE desktop from offsite.  These directions presume you are using a unix-based OS, such as Linux, macOS, or the Windows Subsystem for Linux (WSL).

First, make sure ~/.ssh/.control_channels exists on your local machine, the ssh session will create some control channel sockets in this dir.

mkdir -p ~/.ssh/.control_channels

Edit your ~/.ssh/config similar to the example  ~/.ssh/config below

###################################################
ControlPath ~/.ssh/.control_channels/%h:%p:%r

Host login-gce
Hostname logins.cels.anl.gov
ControlMaster auto
ControlPersist yes
ForwardX11 no
ForwardAgent no
LogLevel FATAL

Host homes-gce
Hostname homes.cels.anl.gov
ProxyCommand ssh login-gce -q -W %h:%p
ForwardX11 yes
###################################################

Note: If your local machine username does not match your ANL username you can add “User anlusername” under each of the hosts so the ssh connection is made using the correct username.

With the above parameters, running “ssh homes-gce” will set the control channel to logins.cels.anl.gov and subsequently providing you with a shell on homes.cels.anl.gov. You can add additional host/proxy command entries to connect to other machines using the same SSH tunnel. For example, if you want to connect to your CELS-managed workstation from offsite, you can add to your ~/.ssh/config file something similar to the following example, changing the hostname to the appropriate name:

###################################################
Host workstation-offsite
Hostname workstation.cels.anl.gov
ProxyCommand ssh login-gce -q -W %h:%p
ForwardX11 yes
###################################################

This will use the same ssh control channel we setup in the previous example to connect to your workstation.

You can also create a general wildcard entry that would tunnel all SSH connections through the logins.  Example:

###################################################
Host *.cels.anl.gov
ProxyCommand ssh login-gce -q -W %h:%p
ForwardX11 yes
###################################################

With the above any SSH to a hostname ending with .cels.anl.gov will be tunneled through the login nodes.

Note: Do not store your ssh private key on the NFS shared filesystem, this includes the home dir of your GCE workstation if you have one. In most cases you should not need your ssh key once logged in to one of the CELS GCE managed machines: home nodes, compute nodes, workstations. Once logged in to one of these you will be able to ssh between these type of managed nodes without further use of the private key.

Was this article helpful to you? Yes No

How can we help?