Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »


To effectively use the cluster resources, you will need to ensure that all the compute nodes have the ability to authenticate you, without you ever needing to send your password over the network. This is achieved by setting up an ssh key pair, generated using the RSA algorithm. 

Setting up your ssh keys only needs to be done once.


Connect to Gateway Server

Connect to one of our gateway nodes using the username and password provided to you by the SCU. In this example, we are using pascal:

ssh <your-scu-username>@pascal.med.cornell.edu


Create your Key pair

First, check if you don't already have ssh keys set up:


ls ~/.ssh

If the output shows the files id_rsa and id_rsa.pub, you already have keys in place. Skip the following command and continue to authorizing your key.

If the output did not show those files, generate them with the following command:

ssh-keygen -t rsa

Follow the instructions on screen. Accept the default location. This will create two new files: id_rsa and id_rsa.pub, your private and public keys, respectively.

While your public key in id_rsa.pub can be shared freely, your private key in id_rsa must be kept secret. If another person gains access to this file, they will be able to generate new keys impersonating you, which would grant them access to any system you have access to.

Authorizing your key

Add the public key you just created to the list of public keys that can authenticate you. Usually, this would be done on the server you wish to connect to, but since all servers on SCU infrastructure mount your home directory, you can instead go directly to the directory that stores all the authentication information, and add your key:

cd ~/.ssh
cat id_rsa.pub >> authorized_keys

This will create the file if it does not already exist.

Because all the shared SCU servers mount your home directory, this file will be read by any shared SCU machine we want to connect to. Once you are logged onto the SCU infrastructure, you should be able to connect to any other shared SCU server you have access to without ever typing in a password again.

Avoiding Fail2ban and SSH Proxy



Fail2ban will block invalid connection attempts when users attempt multiple logins with wrong username.

When logging into a server if you don't explicitly specify username then the default for ssh is to try username of current user.  So if you laptop has the username of "joe" then typing "ssh aphrodite.med.cornell.edu" will include "joe" as the user for authentication.

To avoid avoid this use ~/.ssh/config to specify username that way you cannot type wrong one.

For example:
Host *.pbtech
User scu_ldap_username
ProxyCommand ssh -W %h:%p scu_ldap_username@scu.login.node
ControlMaster auto
ControlPersist 60
ServerAliveInterval 120
IdentityFile ~/.ssh/your_private_key


Host *.med.cornell.edu
User scu_ldap_username
ControlMaster auto
ServerAliveInterval 120
ControlPersist 60
IdentityFile ~/.ssh/your_private_key
If you place this at bottom of ~/.ssh/config file then it will be read last and these settings are applied to any server with "med.cornell.edu" in the hostname.   This will also allow proxying through a login node to reach our internal HPC network.
Then you can just do "ssh aphrodite" and the user name will never be incorrect.



  • No labels