Some SSH related frequently asked questions are documented down below.
For more in-depth details, other options, please consult the man pages:
man ssh and
Login via ssh keys
To login to a server without typing in your password every time,
you can configure ssh to use public key cryptography.
In case you use a linux system start by generating a pair of keys and
saving them in the folder
ssh-keygen -t ed25519 -a 100 -f .ssh/id_sigma2
Make sure to enter a passphrase to encrypt the key.
To copy and install the public key to the server, for example saga, we use:
ssh-copy-id -i ~/.ssh/id_sigma2 firstname.lastname@example.org
Using ssh keys has the added benefit that you can avoid having to type your password every time.
ssh-agent is program installed on virtually all linux versions to manage the keys so that you only have to unlock the key once.
We can add the new key with:
We recommend you configure your ssh client by adding a section for each Sigma2 system you have access to by editing
Host saga Hostname saga.sigma2.no User myusername IdentityFile .ssh/id_sigma2
This will let you simply type
ssh saga, rather than e.g.
ssh email@example.com -i .ssh/id_sigma2
For more information see https://www.ssh.com/ssh/keygen/
Windows ssh client
In Windows 10 and newer you can now get a fully functional Linux terminal by installing WSL: https://docs.microsoft.com/en-us/windows/wsl/install-win10
This will not only give you a shell with the ssh client, but also let you install and use all of your favourite Linux software such as vim, emacs, nano, perl, python and so on.
X11 forwarding should be used with caution due to security implications. Please note that if someone can read your X authorization database 1, that person would be able to access the local X11 display through the forwarded connection.
We suggest switching it on only when needed, with the use of options (
-Y) passed to the
ssh command. Whenever possible, use
-X option to mark
remote X11 clients untrusted.
In some cases
-X will fail to work and either the use of
-Y option or
ForwardX11Trusted in your ssh config file to "yes" is required. In
this case remote X11 clients will have full access to the original X11 display.
Alternatively, if X11 forwarding is always needed, you can configure it on a
per-host basis in your
# global settings ForwardX11 no # disable X11 forwarding ForwardX11Trusted no # do not trust remote X11 clients # per-host based settings, example for Fram Host fram # alias, you may run "ssh fram" only HostName fram.sigma2.no # actual hostname for Fram User my_username # replace with your username on Fram IdentityFile ~/.ssh/id_rsa_fram # pointer to your private SSH key ForwardX11 yes # enable X11 forwarding ForwardX11Trusted no # do not trust remote X11 clients
No matter how you login, you will need to confirm that the connection
shall be trusted. The first time you log in to a machine via
ssh, you will
get a message like
The authenticity of host '<hostname>' can't be established. ECDSA key fingerprint is <fingerprint>. Are you sure you want to continue connecting (yes/no)?
<fingerprint> matches the fingerprint of the login machine
you are logging in to (see below), you can confirm by typing
Enter. (Note that the trailing "." is not part of the
fingerprint.) If the fingerprint does not match, please contact
For the Fram login nodes, the ECDSA key fingerprint is
Some ssh clients will show it as
(possibly without the
Putty seems to at least sometimes display the ED25519 key instead
For the Saga login nodes, it is
sometimes shown as
or for ED25519
For the NIRD login nodes, it is
sometimes shown as
or for ED25519
To display all fingerprints for a certain server, you can use the following command on your local machine (Linux or Mac):
ssh-keygen -lf <(ssh-keyscan **login.nird.sigma2.no** 2>/dev/null)
login.fram.sigma2.no are round-robin DNS
entries, every time you use this name the round-robin configuration
will send you to one of the following two login nodes:
When you use
sshfs, to make sure your authentication is valid, you
should always specify one of the real login nodes above. You should
fram.sigma2.no in your
command, otherwise you will risk to get your IP address blacklisted,
since your session is authenticated against only one login node not
login.saga.sigma2.no are round-robin
DNS entries for
In case of poor connection to the server (likely from a very remote area),
usually noticeable with X11 forwarding enabled, you may request data
compression by using the
Please note that the compression uses the CPU to compress-decompress all data sent over ssh and will actually have negative impact, slow down things on a fast network.
1. By default your X authority database is stored in the
~/.Xauthorityfile. This file contains records with authorization information used in connecting to the X server. ↩