J’expose ici le protocole SSH (Secure SHell). Je décris les principales commandes de ce protocole, ainsi que la mise en oeuvre de paire de clés privée/publique pour s’authentifier. J’aborderai dans un premier temps la partie client (votre machine) et ensuite la partie serveur (machine distante). Je suppose que le serveur (machine distante) dispose de sshd (serveur ssh).

SSH c’est quoi ?

SSH est un shell sécurisé(Secure SHell) qui vous permet de vous connectez à  une machine distante à  travers le réseau, cela peut être une machine de votre réseau local mais également une machine située à  Londres, Madrid ou New York! En outre, il vous permet de lancer des applications sur la machine distante. Vous pouvez également effectuer des transferts de votre machine locale sur le serveur et inversement tout cela de manière sécurisée. SSH permet d’établir un canal de communication sécurisé et de s’authentifier de manière forte (mise en place de paire de clés) sur le serveur distant.

Pourquoi utiliser SSH ?

Les commandes traditionnelles comme rcp, rlogin, telnet sont vulnérables, il est assez aisé par exemple au sein d’un réseau local de trouver les logins et mot de passe qui circulent. Il faut savoir que les logins et les mots de passe sont envoyés en clair sur votre réseau, il suffit alors pour quelqu’un de mal intentionné d’écouter vos ports et d’analyser les paquets circulant. Essayer l’utilitaire EtherReal, c’est assez déroutant … SSH est beaucoup plus sécurisé, les données sont cryptées donc bon courage aux gens malintentionnées… Quoique faites attention quand même !!! Votre mot de passe est crypté lors de la connexion et les données circulant entre le serveur et le client le sont également.

Quelques notations

La machine locale s’appellera ipowerht d’IP 10.0.0.3. Le serveur distant s’appellera ipower d’IP 10.0.0.4. mon login (identifiant de connexion) sera nadir.

SSH coté client

Pour vous connectez à  un serveur ssh, on utilise la commande suivant:

ssh login@serveur_distant

Je vous rappelle que nous sommes coté client mon ip est 10.0.0.3 et la machine c’est ipowerht, on peut vérifier:

nadir@ipowerht:~ $ ifconfig eth0
eth0      Lien encap:Ethernet  HWaddr 00:0C:6E:4D:3F:2A
          inet adr:10.0.0.3  Bcast:10.0.0.255  Masque:255.255.255.0
          adr inet6: fe80::20c:6eff:fe4d:3f2a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12462 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11916 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:6283113 (5.9 MiB)  TX bytes:1396161 (1.3 MiB)
          Interruption:22

On se connecte et mettez yes !

nadir@ipowerht:~ $ ssh nadir@10.0.0.4
The authenticity of host '10.0.0.4 (10.0.0.4)' can't be established.
RSA key fingerprint is c2:72:14:de:97:a3:68:e6:80:96:e5:f6:03:6d:ab:b0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.4' (RSA) to the list of known hosts.
nadir@10.0.0.4's password:
Linux ipower 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
You have new mail.
Last login: Mon Oct 31 12:32:04 2005
nadir@ipower:~$

Nous somme à  présent connecté sur le serveur distant ipower d’ip 10.0.0.4.

Quelques explications. Vous êtes obligé de répondre yes pour vous connecter. Vous autorisez à  ce moment là  l’enregistrement d’une clé publique dans un fichier known_hosts situé dans le répertoire .ssh de votre répertoire personnel.

nadir@ipowerht:~ $ cat ~/.ssh/known_hosts
|1|0Oe37usFY/ObV2ZushNUYkaCJHw=|hUK+rpChGZkayH3B5DtafHoggwQ= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtb+INGggM1ISDOrKTBc0bp3wa7HZOzaAjgi8TJEt
VQyg4cB1ege3C+2WiOdUDoKBDxBdgKaWesEIwx4g+LTY1YzwB6bb2JHU487WJx5YRDRF
yfKYICLJLg2n++vQWW/Bw8fwpcjCfhjV591WyDzHtb9lPkX45qFcWWtgJvJGxOc=

SSH coté client: transfert de fichiers par scp

Pour transférer des fichiers de manière sécurisée, on utilise la commande scp comme suit

scp source destination

s’il s’agit de répertoire on utilise -r

scp -r source destination

lorqu’il s’agit de la machine cliente, on utilise la notation classique des répertoires, s’il sagit du serveur distant on utilise login@serveur_distant:(Ne mettez pas d’espace après:). Regardons quelques exemples: je copie du client vers le serveur un fichier

nadir@ipowerht:~ $ scp Desktop/sources.list nadir@10.0.0.4:Desktop
nadir@10.0.0.4's password:
sources.list                                  100% 1686     1.7KB/s   00:00

Ici je copie un répertoire (-r) du serveur vers la machine locale:

nadir@ipowerht:~ $ scp -r nadir@10.0.0.4:simula+ Desktop/
nadir@10.0.0.4's password:
Root                                          100%   29     0.0KB/s   00:00
Repository                                    100%    8     0.0KB/s   00:00
Entries                                       100%   43     0.0KB/s   00:00
test.cpp                                      100%  181     0.2KB/s   00:00

SSH coté client: transfert de fichiers par sftp

Au lieu d’utiliser le ftp classique c’est la commande sftp qu’il faut utiliser, ne râlez pas si on découvre votre mot passe alors que vous utilisez le ftp classique. La syntaxe est la suivante:

sftp login@serveur_distant

En pratique:

nadir@ipowerht:~ $ sftp nadir@10.0.0.4
Connecting to 10.0.0.4...
nadir@10.0.0.4's password:
sftp>

SSH coté client: Authentification par clé

Nous avons vu précédemment que l’authentification sur le serveur se faisait via un login et un mot de passe. Nous allons voir à  présent que l’authentification peut se faire grâce à  la cryptographie asymétrique et et une paire de clés privée/publique.

L’authentification forte c’est quoi au juste?

  • c’est d’abord un cryptage de type RSA/DSA
  • chaque utilisateur (user) possède deux clés l’une publique l’autre privée
  • pour s’authentifier la partie privée doit être située sur le client et la partie publique sur le serveur.
  • au lieu d’introduire votre login et votre mot de passe vous n’aurez plus qu’à  introduire une passphrase, c’est un mot de passe qui autorise des phrases, NE LAISSEZ JAMAIS LA PASSPHRASE VIDE!!!, c’est un ordre ! évidemment si quelqu’un pique votre clé publique vous êtes mal puisque vous n’avez pas mis de passphrase.

Pour générer une paire de clés on utilise

ssh-keygen -t rsa

Vous avez le choix entre dsa, rsa et rsa1. Regardons un exemple avec le cryptage dsa comment générer les clés publique et privée. Par défaut tapez entrée pour le nom des fichiers, mais pas pour la passphrase, je le répète: NE LAISSEZ JAMAIS LA PASSPHRASE VIDE!!!

nadir@ipowerht:~ $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/nadir/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nadir/.ssh/id_dsa.
Your public key has been saved in /home/nadir/.ssh/id_dsa.pub.
The key fingerprint is:
99:02:09:26:f7:18:1d:9d:85:93:d8:3f:12:2a:0e:52 nadir@ipowerht
nadir@ipowerht:~ $ ls -al .ssh
total 16
drwx------   2 nadir nadir 4096 2005-11-01 20:28 .
drwxr-xr-x  41 nadir nadir 4096 2005-11-01 19:16 ..
-rw-------   1 nadir nadir  736 2005-11-01 20:28 id_dsa
-rw-r--r--   1 nadir nadir  604 2005-11-01 20:28 id_dsa.pub

Dans le répertoire de l’utilisateur, on retrouve donc le répertoire .ssh qui contient les clé publique id_dsa.pub et privée id_dsa. Notez l’importance des droits de la clé privée id_dsa

-rw——- 1 nadir nadir 736 2005-11-01 20:28 id_dsa

Elle est du type 600, c’est à  dire rw pour l’utilisateur et les autres n’ont aucun droit. Pourquoi ? Tout simplement parce que les autres ne doivent pas lire votre clé privée …

Transfért de la clé publique sur les serveur distant

il faut à  présent transférer la clé publique sur le serveur distant. On utilise la commande suivante

ssh-copy-id -i chemin_de_la_clé_publique login@serveur_distant

En pratique cela donne:

nadir@ipowerht:~ $ ssh-copy-id -i ~/.ssh/id_dsa.pub nadir@10.0.0.4
27
The authenticity of host '10.0.0.4 (10.0.0.4)' can't be established.
RSA key fingerprint is c2:72:14:de:97:a3:68:e6:80:96:e5:f6:03:6d:ab:b0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.4' (RSA) to the list of known hosts.
nadir@10.0.0.4's password:
Now try logging into the machine, with "ssh 'nadir@10.0.0.4'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Alors là  vous avez un message vous indiquant que vous devez essayer de vous connecter sur le serveur distant et de vérifier le fichier .ssh/authorized_keys. Comme on n’a pas la flemme on essaye, il faut évidemment entrer la passphrase:

nadir@ipowerht:~ $ ssh nadir@10.0.0.4
Enter passphrase for key '/home/nadir/.ssh/id_dsa':
Linux ipower 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
You have new mail.
Last login: Tue Nov  1 22:42:00 2005 from ipowerht.lan
nadir@ipower:~$ cat .ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBANIk54Df106UVD4Op/bHSOFWvyWl+P5GfkaOJV
j5i+MOO2fs1GD3SivhpZ6UbWfV2VhpidGg+DgqLg9817Isj7GexCrIQ269TgNSvLRb
rD3fA3JkD8zXOlBwn0UhFXURZkUJ9+ghT/JQPUXoKLhb+SN6kQxH8XAh7yPH5+hsug
YRAAAAFQCQtWe+/XfqCmkQO9iAtnJqlNED7wAAAIBUXoNpRZKBNi6CXeSNCzMS6jjC
0yuaLEUetwDGYT0w1aI8rVNiCrohcPiPba/vKgrgO/F+uSBsU2RsNLL8TLHfZvl+2c
e4U6m2o6APzwZFCyRXlgZWvPmsZZqnx1qKwRLkjSOq5ufIfMBXed2RWprwYINq8W7U
a0NYbjVkdD8G7AAAAIEAutDMfZeURchN88dHVuLA5uSR5dE+y2Gk2OmZx2ZjxM7adB
Zi1dKJQ85h6NrnqrgrgNhA0yWDhOBkIWNp24S9jwXS9dCHlnRO+yeaR2faXZbOGjeV
CtEfcdjc5GLSR2heFqBDQntiNnwmNoYzV9kqu1SzylbmdIAHNWJarjxo9xw= nadir@ipowerht

Vous pouvez vérifier que c’est bien la bonne clé:

nadir@ipower:~$ exit
logout
Connection to 10.0.0.4 closed.
nadir@ipowerht:~ $ cat ~/.ssh/id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBANIk54Df106UVD4Op/bHSOFWvyWl+P5GfkaOJV
j5i+MOO2fs1GD3SivhpZ6UbWfV2VhpidGg+DgqLg9817Isj7GexCrIQ269TgNSvLRb
rD3fA3JkD8zXOlBwn0UhFXURZkUJ9+ghT/JQPUXoKLhb+SN6kQxH8XAh7yPH5+hsug
YRAAAAFQCQtWe+/XfqCmkQO9iAtnJqlNED7wAAAIBUXoNpRZKBNi6CXeSNCzMS6jjC
0yuaLEUetwDGYT0w1aI8rVNiCrohcPiPba/vKgrgO/F+uSBsU2RsNLL8TLHfZvl+2c
e4U6m2o6APzwZFCyRXlgZWvPmsZZqnx1qKwRLkjSOq5ufIfMBXed2RWprwYINq8W7U
a0NYbjVkdD8G7AAAAIEAutDMfZeURchN88dHVuLA5uSR5dE+y2Gk2OmZx2ZjxM7adB
Zi1dKJQ85h6NrnqrgrgNhA0yWDhOBkIWNp24S9jwXS9dCHlnRO+yeaR2faXZbOGjeV
CtEfcdjc5GLSR2heFqBDQntiNnwmNoYzV9kqu1SzylbmdIAHNWJarjxo9xw= nadir@ipowerht

Rien à  dire c’est la même! A chaque connexion sur la machine distante, ssh vous demandera la passphrase qui a servi à  crypter la clé privée:

nadir@ipowerht:~ $ ssh nadir@10.0.0.4
Enter passphrase for key '/home/nadir/.ssh/id_dsa':

SSH coté serveur

La configuration du serveur ssh se fait à  travers le fichier /etc/ssh/sshd_config. Ce fichier gère le paramètrage des connexions sur le serveur, toute modification de ce fichier nécessite un redémarrage du démon sshd comme suit

nadir@ipower:~$systemctl restart sshd

Notez que le redémarrage empêche la déconnexion des utilisateurs du serveur ssh, contrairement à  l’arrêt

nadir@ipower:~$systemctl stop sshd

Pour le paramétrage de ce fichier de configuration, je vous invite vivement à  lire la documentation

nadir@ipower:~$man sshd