Problématique
SSH (Secure SHell) permet de se connecter de façon sécurisée à un système Unix ou Linux et doit être privilégié par rapport à d’autres programmes tels que rlogin, telnet, rcp, ftp et rsh. SSH garantit entre autres la confidentialité, l’intégrité et l’authentification.
Avec SSH, l’authentification peut se faire sans l’utilisation de mot de passe ou de phrase secrète en utilisant la cryptographie asymétrique. Cette technique est à la fois plus sûre mais aussi plus pratique (plus de mot de passe à taper) et enfin et surtout indispensable pour pouvoir scripter ou programmer des échanges en utilisant ce protocole.
Principe
Le principe de mise en place d’une authentification par clé est simple et comporte deux étapes :
- Création de la paire de clé sur le client (celui depuis lequel on souhaite lancer une commande SSH) ; cette est à faire une fois pour toutes
- Envoyer sa clé publique sur le serveur dans le fichier
authorized_keys
La mise en pratique est parfois moins triviale de part la diversité des systèmes utilisés (PC, Nas, Box) et de part la diversité des implémentations logicielles du protocole SSH.
On peut distinguer deux principales implémentations logicielles du protocole SSH :
- OpenSSH, projet libre d’outils SSH, est l’implémentation la plus utilisée par les distributions GNU/Linux (PC, NAS Synology…)
- Dropbear, une implémentation libre destinée à remplacer OpenSSH sur les systèmes embarqués Unix ayant peu de ressources (VeraLite…)
Remarque : Attention, la création de la paire de clé sur le client (première étape) ne doit être réalisée qu’une seule fois. Lorsqu’un client se connecte sur un serveur en utilisant le protocole SSH, la clé du client est stockée sur le serveur dans le fichier known_hosts. Si le client venait à changer sa clé, il faut l’effacer dans le fichier known_hosts du serveur afin de pouvoir à nouveau s’y connecter. Dans le cas contraire, la connexion SSH entre le client et le serveur n’est plus possible.
OpenSSH et Dropbear
OpenSSH
- Création de la clé :
[client]$ ssh-keygen -t dsa - Copie de la clé :
[client]$ ssh-copy-id -i ~/.ssh/id_dsa.pub <login>@<adresse_serveur> - Connexion sans mot de passe :
[client]$ ssh <login>@<adresse_serveur> - Afficher des informations si cela ne fonctionne pas :
[client]$ ssh -vvv <login>@<adresse_serveur> - Fichiers générés sur le client
~/.ssh/id_dsa: la clé privée qui ne doit jamais être divulguée ou diffusée~/.ssh/id_dsa.pub: la clé publique envoyé dans le fichierauthorized_keyssur le serveur par la commandessh-copy-id~/.ssh/known_hosts: ce fichier contient les clés publiques des comptes hôtes, donc celle de<login>@<adresse_serveur>~/.ssh/authorized_keys: le cas échéant, ce fichier contient les clés des clients autorisés à se connecter en utilisant l’authentification par clé
Dropbear sur la VeraLite
- Création de la clé :
[client]$ dropbearkey -t rsa -f ~/.ssh/id_rsa - Génération de la clé publique (facultatif) :
[client]dropbearkey -y -f ~/.ssh/id_rsa | grep "^ssh-rsa " > ~/.ssh/id_rsa.pub - Copie de la clé :
[client]$dropbearkey -y -f ~/.ssh/id_rsa | grep "^ssh-rsa " | ssh <login>@<adresse_serveur> "cat - >> ~/.ssh/authorized_keys" - Connexion sans mot de passe :
[client]$ ssh -i ~/.ssh/id_rsa <login>@<adresse_serveur> - Fichiers générés sur le client
~/.ssh/id_rsa: la clé dropbear~/.ssh/id_dsa.pub: la clé publique~/.ssh/known_hosts: ce fichier contient les clés publiques des comptes hôtes, donc celle de<login>@<adresse_serveur>~/etc/dropbear/authorized_keys: le cas échéant, ce fichier contient les clés des clients autorisés à se connecter en utilisant l’authentification par clé
Redémarrer le service SSH
- PC Linux :
service ssh restart - NAS Synology :
/usr/syno/etc.defaults/rc.d/S95sshd.sh restart - VeraLite :
/etc/init.d/dropbear restart
Exemples de mise en place de l’authentification par clé
PC Linux sur Synology
- Création de la clé (une seule fois) :
[PC]$ ssh-keygen -t dsa - Copie de la clé :
[PC]$ ssh-copy-id -i ~/.ssh/id_dsa.pub root@<IP_Syno> - Connexion sans mot de passe :
[PC]$ ssh root@<IP_Syno>
PC Linux sur VeraLite
- Création de la clé (une seule fois) :
[PC]$ ssh-keygen -t dsa - Copie de la clé :
[PC]$ cat ~/.ssh/id_dsa.pub | ssh root@<IP_Vera> "cat - >> /etc/dropbear/authorized_keys" - Connexion sans mot de passe :
[PC]$ ssh root@<IP_Vera>
Synology sur VeraLite
- Création de la clé (une seule fois) :
[Synology]$ ssh-keygen -t dsa - Copie de la clé :
[Synology]$ cat ~/.ssh/id_dsa.pub | ssh root@<IP_Vera> "cat - >> /etc/dropbear/authorized_keys" - Connexion sans mot de passe :
[Synology]$ ssh root@<IP_Vera>
VeraLite sur Synology
- Création de la clé (une seule fois) :
[Vera]$ dropbearkey -t rsa -f ~/.ssh/id_rsa - Copie de la clé :
[Vera]$dropbearkey -y -f ~/.ssh/id_rsa | grep "^ssh-rsa " | ssh root@<IP_Syno> "cat - >> ~/.ssh/authorized_keys" - Connexion sans mot de passe :
[Vera]$ ssh -i ~/.ssh/id_rsa root@<IP_Syno>
Ça ne fonctionne pas !
- Afficher des informations si cela ne fonctionne pas :
[client]$ ssh -vvv <login>@<adresse_serveur>
Les logs sont difficiles à lire. Mieux vaut avoir une connexion qui fonctionne pour pouvoir les comparer. - Il existe deux types de clefs :
dsaetrsa. Certains systèmes ne fonctionnent qu’avec l’un des deux types. - Éditer le fichier
/etc/ssh/sshd_configet décommenter les trois lignes suivantes :
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
-
Vérifier les droits des dossiers utilisateur pour que le démon SSH puisse accéder aux différents fichiers :
chmod 755 /volume1/homes/admin
chmod 700 /volume1/homes/admin/.ssh
chmod 644 /volume1/homes/admin/.ssh/authorized_keys
