This page contains some suggestions on how to improve your SSH experience.
You user own configuration file is located in your home folder at the path
In some cases this file does not exist, you can create it for example by issuing
This file is very useful to create ssh shortcuts to servers and add specific options for each server. In what follows I show some examples of how this can be used. You can edit the file with any text editor of your choice, it's a simple text file.
One can speedup logging in by configuring her/his own ssh client. This will also help in scp-ing data to the cluster.
The configuration example below shows how you can access a machine through another machine with a single ssh command. The scenario is as follows:
User ---> machine hostA.matfys.lth.se ----> machine hostB.matfys.lth.se ----> machine hostC.matfys.lth.se
And you want to use one single command to login to B or C.
# access hostA.matfys.lth.se Host hostA HostName hostA.matfys.lth.se User <username on hostA.matfys.lth.se> # this line below is equivalent to ssh -X hostA.matfys.lth.se ForwardX11 yes # directly access hostB.matfys.lth.se Host hostB User <Username on hostA.matfys.lth.se> ForwardX11 yes # Use this command if A uses Openssh server version < 5.4. # It requires the program netcat (nc) to be installed on the # hostA.matfys.lth.se machine. ProxyCommand ssh -q hostA.matfys.lth.se nc hostB.matfys.lth.se 22 # directly access hostC.matfys.lth.se Host hostC User <Username on hostC.matfys.lth.se> ForwardX11 yes # Use this command if hostB.matfys.lth.se uses Openssh server version >= 5.4, # that has native support for tunnelling ssh connections. ProxyCommand ssh -q hostB.matfys.lth.se -W hostC.matfys.lth.se:22
Example: My user is florido. In the template above, I would change all the <Username …> to florido.
then to login to
hostB.matfys.lth.se I will do:
And I will have to input 2 passwords: one for
hostA.matfys.lth.se, one for
In general you will have to input as many passwords as the number of hops. To overcome this problem, use a private/public ssh keypair technique described below.
If you plan to use this, read the following:
|DO NOT USE PASSWORDLESS KEYS. THESE ARE A SECURITY THREAT FOR THE EVERYONE USING SERVERS!!!|
I will give you a set of quick steps how to setup ssh keys. But it is important that one understands the concepts behind, so please read the sections below.
SSH key pair is a form of PKI, Public Key Infrastructure1). In this technology every user or machine has a pair of keys:
The machine or host keys are usually stored in the
/etc/ssh/ system folder, and they are generated at installation time by the OpenSSH scripts. They are of different kinds as they support different encryption schemas,
their names being like ssh_host_<schema> (private) and ssh_host_<schema>.pub (public).
In the example below, note how the private key is readable and writable ONLY by root while all the
.pub ones are readable by everyone (but not writable!)
ls -ltrah /etc/ssh/ssh_host* -rw-r--r-- 1 root root 393 mar 30 2016 /etc/ssh/ssh_host_rsa_key.pub -rw------- 1 root root 1,7K mar 30 2016 /etc/ssh/ssh_host_rsa_key -rw-r--r-- 1 root root 601 mar 30 2016 /etc/ssh/ssh_host_dsa_key.pub -rw------- 1 root root 672 mar 30 2016 /etc/ssh/ssh_host_dsa_key -rw-r--r-- 1 root root 173 mar 30 2016 /etc/ssh/ssh_host_ecdsa_key.pub -rw------- 1 root root 227 mar 30 2016 /etc/ssh/ssh_host_ecdsa_key -rw-r--r-- 1 root root 93 mar 30 2016 /etc/ssh/ssh_host_ed25519_key.pub -rw------- 1 root root 399 mar 30 2016 /etc/ssh/ssh_host_ed25519_key -rw-r--r-- 1 root root 651 maj 10 2016 /etc/ssh/ssh_host_key.pub -rw------- 1 root root 986 maj 10 2016 /etc/ssh/ssh_host_key
Every ssh pki key has a fingerprint, that is, a unique way to identify that key. You can check your machine unique fingerprint by using the
ssh-keygen script provided by OpenSSH:
tjatte:~> ssh-keygen -lf /etc/ssh/ssh_host_key ssh-keygen: /etc/ssh/ssh_host_key: Permission denied tjatte:~> ssh-keygen -lf /etc/ssh/ssh_host_key.pub 2048 7a:21:c6:ee:4c:a1:a0:0e:4d:72:71:e9:3d:2f:b6:d7 firstname.lastname@example.org (RSA1)
Every time a user connects to a server, the server presents its key fingerprint and the user is requested to acknowledge he/she/ze is aware of trusting that fingerprint. The sysadmin has a list of trustworthy fingerprints, so if you're unsure, ask me!
When a fingerprint is accepted, it is stored in the user's home folder inside the file
~/.ssh/known_hosts in encrypted form:
head ~/.ssh/known_hosts |1|MPQKqI2ylQAvJh/w7R3iXekDlv8=|aGwTSWRlJL4O3olYfRmzato1h3o= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCm0y1t5RLpgUZ16Et8To6lKkh6AyTaCBQyQQ2Z/ASLpr6qTYWIX9Ebx3ZYr7kgUUsikJzuPe8CFHflpNnIAFhVdih1j9y4RJXRi4vo/3SlmT59jq6I6OqG5qcnhys6gFx21Yd8dLiKCgAyWw296gzTsBJDTIp8Myfz0MCPIEO+qWeSOcWq/6wm6iWnTGnfBkJyGnwqZooqO2XgVF3gYbVonES7MB6nTADVSUIAZ8P1TZ2V8vJbXkogUkHD8kv1wt4N/O7yFEtYySsoXLZlb7zFQyw/REVaW1Jn1RVtg76KMhvxBwlgM0J9bbUjcok5E/kIVvu5oDijmMahKBpiOUrB |1|/vDgSpeBUKtJVgcul94pqe5nWyE=|1eF4hBt+gSqT1mf+X7psKVdWeWQ= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCm0y1t5RLpgUZ16Et8To6lKkh6AyTaCBQyQQ2Z/ASLpr6qTYWIX9Ebx3ZYr7kgUUsikJzuPe8CFHflpNnIAFhVdih1j9y4RJXRi4vo/3SlmT59jq6I6OqG5qcnhys6gFx21Yd8dLiKCgAyWw296gzTsBJDTIp8Myfz0MCPIEO+qWeSOcWq/6wm6iWnTGnfBkJyGnwqZooqO2XgVF3gYbVonES7MB6nTADVSUIAZ8P1TZ2V8vJbXkogUkHD8kv1wt4N/O7yFEtYySsoXLZlb7zFQyw/REVaW1Jn1RVtg76KMhvxBwlgM0J9bbUjcok5E/kIVvu5oDijmMahKBpiOUrB
As you can see the above is not human readable. But if you want to know if you've trusted a machine, you can do for example 2):
ssh-keygen -lf ~/.ssh/known_hosts -F watto # Host watto found: line 274 type RSA 2048 2f:21:6b:19:fc:fc:9d:62:8f:88:c2:2b:c4:d6:0c:70 |1|vyeQU5q0QfKZzq9/helQLGGK9s4=|ZN50r7hlYRTlCeSEXzzz+80XZKw= (RSA)
These user keys are usually stored in the user's
~/.ssh/ folder, the default names are
id_rsa (private) and
id_rsa.pub (public). But one can choose any location and any name.
A user key can have a password or not. It is strongly discouraged to use passwordless keys. Should your private key get stolen, this will generate an enormous security breach.
The password is used to “unlock” the key, that is, to allow the ssh client (more precisely, the ssh-agent )to use it to connect on the user's behalf.
In order for the user key to work, the machine where one has to login needs to trust that key.
The overall mechanism is as follows. A user willing to connect to a server has to
ssh-agenton his/her/hir local machine that will take care of authenticating the user to the server when logging in. Usually this is automatically started by the ssh client if the user is using PKI.
OpenSSH on linux provides a set of scripts for managing keys:
ssh-keygen: does key management
ssh-copy-id: copies a key to a server and updates the authorized_keys automatically
ssh-agent: takes care of remembering which key as been used for which host, remembers key password
We will generate a public/private key pair called myid_rsa and myid_rsa.pub and copy it to a machine called
watto.matfys.lth.se in order to login to it.
ssh-keygen -b 4096 -f ~/.ssh/myid_rsa
Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /nfs/users/floridop/.ssh/myid_rsa. Your public key has been saved in /nfs/users/floridop/.ssh/myid_rsa.pub. The key fingerprint is: 2d:1d:94:b9:71:35:59:f8:79:26:92:b5:a3:f5:d4:e3 email@example.com The key's randomart image is: +--[ RSA 4096]----+ | .o .o+.| | .+ . +. | | .+ o oo| | o..o =o*| | S o +.*o| | . . E.| | | | | | | +-----------------+
chmod 600 ~/.ssh/myid_rsa; chmod 644 ~/.ssh/myid_rsa.pub; ls -ltrah ~/.ssh/myid_rsa*
-rw------- 1 pflorido hep 3,3K maj 3 13:59 /nfs/users/floridop/.ssh/myid_rsa -rw-r--r-- 1 pflorido hep 751 maj 3 13:59 /nfs/users/floridop/.ssh/myid_rsa.pub
ssh-copy-id -i ~/.ssh/myid_rsa firstname.lastname@example.org
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'email@example.com'" and check to make sure that only the key(s) you wanted were added.
Enter passphrase for /nfs/users/floridop/.ssh/myid_rsa: Identity added: /nfs/users/floridop/.ssh/myid_rsa (/nfs/users/floridop/.ssh/myid_rsa)
ssh -i ~/.ssh/myid_rsa.pub firstname.lastname@example.org
You can now create entries in your
~/.ssh/config file to use tunnelling as described in Speedup connection using tunneling, and the agent should automatically forward your keys.
The best to debug is to enable ssh verbose mode:
ssh -vv email@example.com
ssh-add -d ~/.ssh/myid_rsa
ps aux | grep ssh-agent
ssh-keygen -R <hostname>
ssh-keygen -R <hostname or IP>