pfwiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Better SSH experience ======

This page contains some suggestions on how to improve your SSH experience.

===== The ssh config file =====

You user own configuration file is located in your home folder at the path

  ~/.ssh/config
  
In some cases this file does not exist, you can create it for example by issuing <code:bash>touch ~/.ssh/config</code>

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.

===== Speedup connection using tunneling =====

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.

<code:bash>
# 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
</code>

**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:

  ssh hostB

And I will have to input 2 passwords: one for ''hostA.matfys.lth.se'', one for ''hostB.matfys.lth.se''.

In general you will have to input as many passwords as the number of hops. To overcome this problem, use a [[#Reduce passwords using a private/public ssh key pair|private/public ssh keypair]] technique described below.

===== Reduce passwords using a private/public ssh key pair =====

 If you plan to use this, read the following:

:!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!:

| DO **NOT** USE **PASSWORDLESS** KEYS. THESE ARE A SECURITY THREAT FOR THE EVERYONE USING SERVERS!!! |

:!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!::!:

This tutorial is nice:

https://wiki.archlinux.org/index.php/SSH_Keys


:!: the below part of the document is work in progress. :!:

==== What is SSH PKI ====

SSH key pair is a form of PKI, Public Key Infrastructure. In this technology every user or machine has a pair of keys:
  * A **Public** key that can be shared with everyone and copied on servers
  * A **Private** key that should be kept secure at all times and only readable by your user

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.

The machine 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!)

<code:bash>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
</code>

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:
<code:bash>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  root@tjatte.hep.lu.se (RSA1)
</code>

Every time a user connects to a server, the server presents the 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:
<code:bash> 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
</code>

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:
<code:bash>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)
</code>

==== Using user ssh key pair to login ====

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
  - Copy his/her/hir **public** key to that server
  - Instruct the server that such key is trustworthy by modifying the ''~/.ssh/authorized_keys'' file
  - run an ''ssh-agent'' on 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
pfwiki

User Tools

Site Tools

Page Tools
