ssh : Authentification par clé
Par drpixel, dimanche 9 juillet 2006 à 09:20 :: Documentation :: #10 :: rss
SSh (Secure SHell) permet de se connecter de façon sécurisée à un système Unix, Linux et Windows (très peu utilisé mais disponible via l'API cygwin).
Il faut distinguer :
- ssh : le protocole de communication
- ssh : le programme client permettant de se connecter au serveur
- sshd : le serveur (ssh daemon) écoutant sur le port 22 par défaut
Il existe des clients ssh pour toutes les architectures :
- Linux : ssh, putty, ...
- Windows : putty, ssh (via cygwin)
- Mac : macssh, ssh
SSh (Secure SHell) permet de se connecter de façon sécurisée à un système Unix, Linux et Windows (très peu utilisé mais disponible via l'API cygwin).
Il faut distinguer :
- ssh : le protocole de communication
- ssh : le programme client permettant de se connecter au serveur
- sshd : le serveur (ssh daemon) écoutant sur le port 22 par défaut
Il existe des clients ssh pour toutes les architectures :
- Linux : ssh, putty, ...
- Windows : putty, ssh (via cygwin)
- Mac : macssh, ssh
1. Présentation
Du point de vue de l'utilisateur une connexion ssh s'établit comme une session telnet (demande de connexion, demande de login, demande de mot de passe), le principe est en réalité beaucoup plus complexe.
Ssh permet de garantir :
- La confidentialité : le cryptage des paquets permet de garantir celle-ci. Les anciens services tels que telnet, rlogin, ..., envoyaient les données en clair.
- L'intégrité : ssh permet de garantir que les paquets circulant d'un hôte vers un autre ne sont pas altérés.
- L'authentification : chaque connexion ssh vérifie l'identité du serveur (par sa clé d'hôte ~/.ssh/known_hosts) puis celle du client (par mot de passe ou clé publique ~/.ssh/authorized_keys).
- L'autorisation : il est possible avec ssh de limiter les actions autorisées à l'utilisateur (~/ssh/.authorization).
- Tunneling : ssh permet de sécuriser un service dont les informations circulent habituellement en clair (POP,IMAP,VNC, ...). D'autres aspects du tuneling sont la sécurisation du protocole X11 (X11forwarding) , et l'utilisation de clés privées situées sur un hôte distant (Agent forwarding).
SSh est donc sécurisé mais ne protège pas de tout. L'authentification par mot de passe reste relativement vulnérable (mot de passe trop facile à découvrir ... toute la difficulté d'un bon mot de passe : facile à retenir, difficile à découvrir par les autres).
2. L'authentification par clé
Face à la faiblesse de l'authentification par mot de passe, l'authentification par clé se revèle être très efficace.
La clé permet de garantir à un système qu'un utilisateur est bien celui qu'il prétend être ... en deux mots :"Je jure et je prouve que c'est bien moi".
L'authentification par clé fonctionne grâce à 3 composants :
- Une clé publique : elle sera exportée sur chaque hôte sur lequel on souhaite pouvoir se connecter.
- Une clé privée : elle permet de prouver son identité aux serveurs.
- Une passphrase : Permet de sécuriser la clé privée (notons la subtilité, passphrase et pas password ... donc "phrase de passe" et non pas "mot de passe").
La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et vice-versa.
3. Création de la paire de clé
La création de la paire de clé se fait avec ssh-keygen.
Il existe 2 types de clés : RSA et DSA.
Chacune pouvant être de longueur différentes : 1024, 2048, 4096 bits (les clés inférieures à 1024 bits sont à proscrire ...surtout les RSA).
Pour créer une clé DSA de 1024 bits : ssh-keygen -t dsa -b 1024 -C username@domain.tld
Le commentaire permet de distinguer les clés, utile quand on a plusieurs clé (notamment une perso et une pour le boulot). Ici la distinction se fait sur l'adresse e-mail. Si le commentaire est omis, il sera de la forme user@host.
[drpixel@sidewinder ~]$ ssh-keygen -t dsa -b 1024 -C username@domain.tld
Generating public/private dsa key pair.
Enter file in which to save the key (/home/drpixel/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/drpixel/.ssh/id_dsa.
Your public key has been saved in /home/drpixel/.ssh/id_dsa.pub.
The key fingerprint is:
cb:61:48:6b:b4:53:00:9b:d1:2a:cf:44:88:79:c2:19 username@domain.tld
2 fichiers ont été crées (dans le dossier ~/.ssh/) :
- id_dsa (ou id_rsa dans le cas d'une clé RSA) : contient la clé privée et ne doit pas être dévoilé ou mis à disposition
- id_dsa.pub (ou id_rsa.pub dans le cas d'une clé RSA) : contient la clé publique, c'est elle qui sera mise sur les serveurs dont l'accès est voulu.
4. Paramétrage de SSHd pour autoriser les authentifications par clé
Le fichier de configuration est /etc/ssh/sshd_config.
Par défaut ce comportement de sshd est interdit.
La ligne dans le fichier gérant l'authentification par clé est :
#PubkeyAuthentication yes
Le signe "#" signifie que la ligne est commentée. Il convient donc de la décommenter.
PubkeyAuthentication yes
Il suffit de demander au service sshd de relire sa configuration afin que le serveur soit en mesure d'accepter les authentifications par clé.
[root@amraam ~]# service sshd reload
Rechargement de sshd : [ OK ]
Cela ne suffit bien entendu pas car aucune clé publique n'a été envoyée sur le serveur (amraam)
L'authentification par mot de passe va être utilisée
- Première méthode de copie d'une clé :
[drpixel@sidewinder ~]$ cat ~/.ssh/id_dsa.pub | ssh amraam "cat - >> ~/.ssh/authorized_keys"
drpixel@amraam's password:
Cette commande va lire le fichier $HOME/.ssh/id_dsa.pub (clé publique), se connecter sur le serveur "amraam" et ajouter au fichier des clés autorisées ($HOME/.ssh/authorized_keys) le contenu de la clé lue.
- Deuxième méthode de copie d'une clé :
Il s'agit du même principe que la première méthode sauf que tout est décomposé (utile pour bien comprendre) :
[drpixel@sidewinder ~]$ scp ~/.ssh/id_dsa.pub amraam:/tmp
drpixel@amraam's password:
id_dsa.pub 100% 609 0.6KB/s 00:00
[drpixel@sidewinder ~]$ ssh amraam
[drpixel@amraam ~]$ cat /tmp/id_dsa.pub >> /root/.ssh/authorized_keys
[drpixel@amraam ~]$ rm /tmp/id_dsa.pub
- Troisième méthode :
Il s'agit de la méthode la plus automatisée et la plus simple (elle est a utiliser quand on a compris ce qu'elle va faire ... )
[drpixel@sidewinder ~]$ ssh-copy-id -i ~/.ssh/id_dsa amraam
root@durandal's password:
Now try logging into the machine, with "ssh 'amraam'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
ssh-copy-id va copier la clé publique (pas besoin de préciser le .pub) sur l'hôte distant. Pas besoin de taper de nombreuses lignes.
- Piège a éviter :
Il faut s'assurer dans le cas ou un fichier authorized_keys est présent, qu'il se termine bien par une nouvelle ligne. Sinon le rajout se fera à la volée et 2 clés (la dernière et celle rajoutée) seront inutilisables.
- Désactivation de l'authentification par mot de passe
Une fois que les clés sont générées, mises en place et que leur fonctionnement testé, il est souhaitable de desactiver l'authentification par mot de passe (ATTENTION, bien vérifier de pouvoir acceder physiquement au serveur ... au cas où ...). Cela se passe donc dans le fichier de conf (/etc/ssh/sshd_config)
PasswordAuthentication yes
devient
PasswordAuthentication no
On relance le service sshd :
[root@amraam ~]# service sshd reload
Rechargement de sshd : [ OK ]
Il n'est plus possible désormais de se connecter avec le couple login/password.
5. ssh-agent
Le serveur ssh est maintenant plus sécurisé, mais taper des passphrases à longueur de journée peut se révéler être très pénible surtout si on a choisi une "vraie" passphrase.
L'agent ssh permet de taper la passphrase une seule fois et de la conserver en mémoire pendant tout son fonctionnement. Les communications ssh fonctionneront donc de façon transparente.
- Mode texte
Il faut lancer l'agent avec un shell (le plus simple étant de le lancer avec la variable $SHELL qui contient le shell courant)
Ensuite le programme ssh-add permet de charger les clé présentes dans ~/.ssh/. La passphrase est demandée, toutes les connexions nécessitant les clés chargées par l'agent, seront transparentes.
[drpixel@sidewinder ~]$ ssh-agent $SHELL
[drpixel@sidewinder ~]$ ssh-add
Enter passphrase for /home/drpixel/.ssh/id_dsa:
Identity added: /home/drpixel/.ssh/id_dsa (/home/drpixel/.ssh/id_dsa)
[drpixel@sidewinder ~]$ ssh amraam
Last login: Mon Jul 3 17:21:20 2006 from amraam.home.lan
- Mode graphique
Prérequis : Le package openssh-askpass doit être installé (openssh-askpass-gnome dans les versions de Fedora < 5) Cela peu être vérifié en tapant rpm -q openssh-askpass.
[drpixel@sidewinder ~]$ rpm -q openssh-askpass
openssh-askpass-4.3p2-4
Il faut aller dans le gestionnaire de sessions : Bureau, Préférences, Préférences Supplémentaires, Sessions
Une fois le gestionnaire de session lancé, il faut aller dans l'onglet "Programme au démarrage", faire "ajouter" et taper /usr/bin/ssh-add
A la prochaine ouverture de session, une fenêtre demandera les passphrases de chaque clé trouvée dans ~/.ssh/
- Windows (avec putty)
L'utilisation de putty ne change pas grand chose au principe des clés. Putty a également son agent.
Pour des raisons de simplicité, il est préférable de générer des clés sous Linux et de les transférer sous Windows plutôt que d'utiliser le générateur de clé de Putty.
Putty utilise en effet un format "propriétaire" pour ses clés. La conversion est possible mais reste quelques fois houleuse dans le sens Windows -> Linux.
Après avoir généré la clé sous Linux, on peut la récupérer via ssh (avec winscp par exemple) ou avec n'importe quel autre moyen.
Il va falloir convertir la clé au format putty.
Il faut lancer "Putty Secure Key Generator" (puttygen.exe), puis faire Conversions, Import key.
Dans l'explorateur de fichier, il faut sélectionner la clé privée. La passphrase sera demandée.
Il faut changer la partie commentaire pour remettre ce qui avait été mis lors de la génération de la clé.
Pour terminer il faut cliquer sur "Save Private Key".
On aura donc une clé au format .ppk (Putty Private Key).
Une fois la clé au format putty générée, il faut la donner à l'agent.
Le lancement de putty agent (pageant.exe) est muet sauf si on précise la clé à a charger dans le raccourci. Dans ce cas, il demandera la passphrase (d'ailleurs il est judicieux de rajouter les clés dans le raccourci vers putty agent présent dans Menu Démarrer, Démarrage. Les chemins d'accès ayant des espaces tels que documents and settings, sont a mettre entre " ").
Si elles n'ont pas été spécifiées sur la ligne de commande, les clés se rajoutent en faisant un clic droit sur l'icône de putty agent dans la zone de notification de la barre des tâches, et en sélectionnant tionnant le menu "add key"
Dans l'explorateur de fichier, il faut sélectionner la clé privée au format ppk, la passphrase est demandée. Une fois renseignée, la clé est opérationnelle sans avoir besoin de saisir la passphrase à chaque connexion.
Le login est toujours demandé. Pour s'affranchir de cette demande, il suffit dans les propriétés de putty, lui spécifier le login a utiliser.
Si les clés ont été générées sur le serveur qui sera utilisé pour les connexions, il suffit alors de rajouter la clé publique dans le fichier ~/.ssh/authorized_keys par un :
[drpixel@amraam ~]$ cd .ssh
[drpixel@amraam .ssh]$ cat id_dsa.pub >> authorized_keys
Si les clés ne seront pas utilisées en tant que client ssh, elles peuvent être supprimées (id_dsa et id_dsa.pub) du serveur.
6. Troubleshooting
- Première connexion
Lors de la première connexion ssh vers un hôte, ce message peut apparaître :
The authenticity of host 'amraam (192.168.24.3)' can't be established.
RSA key fingerprint is c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c.
Are you sure you want to continue connecting (yes/no)?
Il faut répondre oui lors de cette première connexion.
Warning: Permanently added 'amraam' (RSA) to the list of known hosts.
La clé d'hôte sur le serveur est maintenant conservée (fichier ~/.ssh/known_hosts) .
- Changement de clé d'hôte sur le serveur
En cas de changement de clé le message suivant apparaitra :
[drpixel@sidewinder ~]# ssh amraam
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c.
Please contact your system administrator.
Add correct host key in /home/drpixel/.ssh/known_hosts to get rid of this message.
Offending key in /home/drpixel/.ssh/known_hosts:12
RSA host key for amraam has changed and you have requested strict checking.
Host key verification failed.
Un changement de clé peut avoir plusieurs cause :
- La clé de l'hôte a été changée volontairement par un administrateur
- Le serveur a subi une réinstallation sans sauvegarde de ses clés
- Ce n'est plus le même serveur (et il faut donc se renseigner si c'est normal ... car cela peut être le serveur d'un pirate ...)
Pour corriger le problème (en cas de changement non suspect uniquement !!!), il suffit soit :
- De supprimer la clé du serveur dans ~/.ssh/known_hosts (ici dans la 12eme place)
- De la modifier dans ~/.ssh/known_hosts afin de mettre la nouvelle clé de l'hôte si elle est connue
- Les clés ne fonctionnent pas
Il faut vérifier les droits sur les clés, ssh nécessite que le dossier .ssh ait les permissions 700 (rwx pour l'utilisateur, rien pour le groupe et les autres) , les clés privée ainsi que authorized_keys 600 (r pour l'utilisateur, rien pour le groupe et les autres) et les clés publiques 644 (rw pour l'utilisateur, read pour le groupe et les autres).
Il faut aussi vérifier que chaque clé tiens sur une ligne dans authorized_keys (même si elle apparait sur plusieurs ligne a l'écran, dans le fichier elle correspond qu'à une ligne).
- Caractères bizarres dans putty
Les versions actuelles de Fedora sont en UTF-8, et putty par défaut en ISO-8859-1. Il faut donc changer le charset dans les propriétés de la connexion (Window/Translation):
7. Conclusion
En n'autorisant que la connexion par clé publique, le service ssh se retrouve fortement sécurisé.
C'est une opération qui n'est pas très complexe, mais qui nécessite néanmoins de bien comprendre le fonctionnement afin de le mettre en place dans de bonnes conditions.
Pour aller plus loin :
- Site officiel d'openssh
- Un exemple de tunnel pour sécuriser vnc
- man sshd, man ssh, man ssh-keygen
- Documentation de putty
- Dans tout les exemples, le cas était que le login était le même dans tout les systèmes, si ce n'est pas le cas :
ssh -l login scp xxxx login@host:/path/
- les clés d'hôtes sont dans : /etc/sshd/ssh_host*
Commentaires
1. Le dimanche 9 juillet 2006 à 14:30, par Pingoomax
2. Le dimanche 9 juillet 2006 à 14:35, par drpixel
3. Le mercredi 12 juillet 2006 à 18:35, par Remi
4. Le jeudi 13 juillet 2006 à 07:47, par drpixel
5. Le jeudi 17 août 2006 à 20:05, par AllOverMe
6. Le jeudi 17 août 2006 à 21:53, par drpixel
Ajouter un commentaire
Les commentaires pour ce billet sont fermés.