Secure Shell – SSH

The Vega cluster (login node) can also be accessed via an SSH connection. SSH (Secure Shell) is a service that secures communication between the user and the server through encryption. There are several ways to use SSH. One way is by using automatically generated public-private key pairs to easily encrypt the network connection and then by logging in with the authentication and password of your account on the server. When a client connects to an SSH server, the server sends a copy of its public key to the client before the client logs in. This allows to set up secure encryption for the communication channel and authenticate the server to the client.

Log in to the target system with the command: $ ssh <username>@<server>

However, the SSH server can also be configured to allow authentication without a password, but with key-based authentication. This is based on a public and private key scheme. In this case, it is necessary to create the appropriate pair of cryptographic key files. One file is a private key and the other is a public key. A private key file is used as an authentication credential and just as a password must be concealed and secured. The public key is copied to the system the user wants to connect to and is used to verify the private key. The public key therefore does not need to be concealed.

A user must insert or copy his public key to his account on the server. Eventually, when the user tries to log in, the SSH server can issue a public key challenge that can only be answered correctly with the private key. As a result, the user's SSH client can automatically confirm the login to the server with the user's unique private key. This allows the client to securely access the systems in a way that does not require the need to re-enter an interactive password each time. To create a private key and a corresponding public authentication key, it is necessary to issue the following command for Linux users:

 $ ssh-keygen

Private and public keys are stored in the following files by default:

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

When creating SSH keys, it is possible to specify another directory where the keys should be saved. This can be done by adding the -f option to the ssh-keygen command and assigning a file where the key should be saved.

$ ssh-keygen -f <private key>

The private key is the full path and file name that contains the private key associated with the cluster that the user wants to access. There is also an even newer version of the keys (ed25519), which is based on a newer cryptographic solution and is faster and more secure. The difference in the management of such keys compared to the usual ones is only in the creation of such a key, where it is necessary to add the -t option to the ssh-keygen command and assign ed25519.

$ ssh-keygen -t ed25519
$ ssh-keygen -t ed25519 -f <private key>

The created keys also have a different name from the usual ones.

~/.ssh /id_ed25519
~/.ssh/id_ed25519.pub

When running the ssh-keygen command, the user is prompted to set any password for his private SSH key. If the user does not specify a password, the generated private key is not protected. In this case, anyone who is in possession of user's private key file could use it for authentication as this user. On the other hand, if the user sets a password, then they must enter it each time they want to use a private key for authentication. In this case, the private key password would be used for authentication and not the user password on the remote host. However, a utility called ssh-agent can be started, which temporarily stores the private key password in memory at the beginning of the session, which allows authentication without entering the password during the current session, because each time a user logs in to another system using the private key, ssh-agent automatically provides the password.

The ssh agent is started with the following command:

$ eval $ (ssh-agent)

When the ssh-agent starts, it needs to be told the password for the private key. This can be done with the ssh-add command. If the user's private key is not in the default file /home/user/.ssh/id_rsa, the location of the key must be assigned to ssh-add command.

$ ssh-add <private key>

Before the key-based authentication can be used, the public key must be copied to the target system (server). This is done with the ssh-copy-id command. In default mode, the command uses the /home/user/.ssh/id_rsa.pub file. If the key is located in another file, it is necessary to add the -f option and specify the path to the public key file.

$ ssh-copy-id -f <public key> <username>@login.vega.izum.si

First login

Once the key has been copied, the user can log in to the target system with the key in the same way as logging in without a key. However, if the user has the key stored in any file other than the default /home/user/.ssh/id_rsa, they must assign the -i option to the ssh command and specify the path to the private key file.

$ ssh <username>@login.vega.izum.si
$ ssh -i <private key> <username>@login.vega.izum.si

When you establish an SSH connection with a particular host for the first time, the shell asks you if you want your system to remember that host. If you answer with y (yes), the fingerprint of this host is written to the newly created know_hosts file in the ~/ .ssh directory. All other hosts that you may connect to in the future are then entered into the same file.