Réseau - Web - GNU/Linux

2018 17 janvier

Configuration SSH du poste client

Rédigé par Marc GUILLAUME | Aucun commentaire

Installation de openssh-client

Il suffit d'installer le paquet openssh-client, qui contient entre autre les utilitaires ssh-agent et ssh-add utiles pour alléger le maniement des clés chiffrées par passphrase. Pour l'installation reportez-vous à la documentation du gestionnaire de paquet de votre distribution. Sur Debian et dérivés un simple :

apt install openssh-client

suffira.

Configuration du client ssh

Les configurations de openSSH se situent dans /etc/ssh/. Un des fichiers de configuration concerne les options du client ssh, il s'agit de /etc/ssh/ssh_config. C'est dans ce fichier que l'on configure les types de clés que l'on peut utiliser. Les options définies dans ce fichier peuvent être surchargées par un fichier dans le dossier de l'utilisateur (~/.ssh/config). Le fichier de configuration contient de nombreuses options qui sont à lire dans la page man ssh_config. Nous allons nous attarder sur deux options qui peuvent être utiles à placer dans son fichier config local.

Une de ces options est user. En effet si vous devez vous connecter en tant qu'un autre utilisateur que le votre sur de nombreux serveurs cela vous permettra de simplifier votre commande de connexion.

L'autre est IdentityFile qui vous permet de décalrer une clé n'ayant pas un nom standard ou se trouvant ailleurs que dans le répertoire par défaut (~/.ssh). Si vous devez vous connecter en tant qu'utilisateur support depuis votre compte personnel sur de nombreuses machines en utilisant la clé ~/.ssh/macle_ecdsa_a_moi vous pouvez écrire dans votre fichier ~/.ssh/config :

user support
IdentityFile ~/.ssh/macle_ecdsa_a_moi

Et vous pourrez vous connecter avec la commande

toto $ ssh my.remote.host

au lieu de

toto $ ssh support@my.remote.host -i ~/.ssh/macle_ecdsa_a_moi

Génération des clés de chiffrement

Un utilitaire fourni avec le paquet, ssh-keygen, sert à générer des clés de chiffrement utilisables par SSH. La première version du protocole ssh (SSHv1) n'acceptait que les clés utilisant l'algorythme rsa. Jusqu'en 2000 rsa faisait l'objet d'un brevet aux État-Unis. Il est maintenant retombé dans le domaine public. Mais lorsque la deuxième version du protocole ssh (SSHv2) a été implémentée dans OpenSSH, rsa était toujours breveté et c'est un autre algorithme, dsa, uniquement destiné à la signature numérique qui a été utilisé.

Depuis le retour de rsa dans le domaine public il existe le choix dans OpenSSH de générer des clés soit avec dsa soit avec rsa. À longueur de clé égale les deux sont sensiblement aussi sûrs l'un que l'autre. Par contre OpenSSH ne permet de générer que des clés dsa de 1024 bits alors qu'il permet de créer des clés rsa jusqu'à 4096 bits (le standard actuel est de 2048 bits, le meilleur compromis entre la sécurité et le temps de calcul). Les clés dsa d'openSSH sont maintenant inutilisables car consdiérées comme non sûres avec leurs 1024 bits, il est donc inutile de générer actuellement des clés dsa. Régulièrement de nouveaux algorithmes sont intégrés. Il est maintenant possible de créer des clés ecdsa plus compactes et tout aussi sûres.

La génération de clés se fait pour chaque utilisateur désirant s'identifier sur une machine distante. En prenant pour exemple un utilisateur « adele » sur la machine pc-00180 désirant créer sa paire de clés rsa avec une clé de 4096 bits, la commande qu'elle devra taper est : ssh-keygen -t rsa -b 4096 qui indique qu'il faut créer un jeu de clés de type (option -t) rsa d'une longueur de 4096 bits (option -b) (voir man ssh-keygen ou ssh-keygen -h pour davantage d'informations sur la création des clés).

adele@pc-00180:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/adele/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/adele/.ssh/id_rsa.
Your public key has been saved in /home/adele/.ssh/id_rsa.pub.
The key fingerprint is:
84:df:f3:e6:3c:46:c2:a9:42:2e:6e:7e:88:aa:45:d3 adele@pc-00180
The key's randomart image is:
+--[ RSA 4096]----+
|                 |
|       .         |
|      . .        |
|   .   o .       |
|  o E   S.o.     |
| . .  .   +o.    |
|  .. +   . oo    |
| .. + + .  +o    |
|+. +oo .   .o.   |
+-----------------+

La création du jeu de clé a réussi et la fingerprint (empreinte digitale) est la signature de cette clé permettant de l'identifier lors de certains échanges. L'empreinte sous forme randomart est pratique pour ceux qui ont une bonne mémoire visuelle, et qui ainsi d'un coup d'oeil peuvent contrôler l'image de la clé présentée par un serveur.

Deux fichiers sont générés par la commande :

adele@pc-00180:~/.ssh$ ls -l
total 12
-rw------- 1 adele adele 3243 déc.  19 02:30 id_rsa
-rw-r--r-- 1 adele adele  738 déc.  19 02:30 id_rsa.pub

Deux clés ont été crées, la clé privée id_rsa et la clée publique (celle que vous devrez distribuer) id_rsa.pub. Vous pouvez supprimer les droits d'écriture sur ces fichiers et permettre la lecture par tous de la clé publique et du seul utilisateur pour la clé privée.

adele@pc-00180:~/.ssh$ chmod 400 id_rsa
adele@pc-00180:~/.ssh$ chmod 444 id_rsa.pub
adele@pc-00180:~/.ssh$ ls -l
total 12
-r-------- 1 adele adele 3243 déc.  19 02:30 id_rsa
-r--r--r-- 1 adele adele  738 déc.  19 02:30 id_rsa.pub

Si les droits sur la clé privée ne sont pas assez restrictifs (lecture pour tous par exemple) ssh vous alertera par un message et refusera d'utiliser la clé.

Lors de la génération des clés deux questions vous sont posées ; où voulez-vous stocker la clé et sous quel nom. Sauf impératif particulier, gardez les valeurs par défaut, c'est à dire création d'un répertoire caché .ssh et id_rsa pour le nom de la clé.

Vous pouvez éventuellement modifier le nom pour le personnaliser un peu, par exemple /home/adele/.ssh/id_rsa-adele qui générera un fichier id_rsa-adele clé privée et id_rsa-adele.pub clé publique. Il est possible dans la commande de préciser un nom de fichier avec son chemin en utilisant l'option -f. On peut également modifier le commentaire qui figurera à la fin de la clé publique en utilisant l'option -C.

L'autre question Enter passphrase (empty for no passphrase): mérite davantage d'attention.

Avec ou sans passphrase ?

SSH veut savoir si vous voulez chiffrer la clé privée avec une « passphrase ». Pour comprendre l'enjeu de cette question il faut rappeler que le fait d'utiliser l'identification rsa (ou dsa) vous identifie auprès du serveur distant sans avoir à fournir d'autres informations (sauf si le serveur est configuré pour exiger une identification en plusieurs étapes, par exemple en demandant également un mot de passe, mais c'est une autre histoire). Si quelqu'un réussit à vous voler votre clé privée, il pourra l'utiliser comme vous le feriez et se connecter à tous les serveurs ou vous vous connectez sans autre forme de procès. L'identification n'est pas en fait celle de l'utilisateur mais de sa clé privée, étant entendu que normalement seul le bon utilisateur possède la clé privée.

Les droits d'accès sur id_rsa sont très stricts, mais quantité de raisons peuvent permettre de tout de même voler ce fichier (toute personne ayant accès à votre ordinateur en votre absence pourra le démarrer par exemple sur un liveCD et ainsi lire ce qu'il veut sur le disque). Si votre clé est sur un ordinateur portable c'est encore plus facile, il suffit de voler l'ordinateur, à moins que vous n'oubliez celui-ci dans un train (je vous assure que c'est hélas possible). Même si vous avez bloqué le BIOS avec un mot de passe et n'avez pas autorisé le démarrage sur un disque ou un support usb il n'est pas impossible de tout de même accéder aux données, par exemple en mettant le disque sur une autre machine non bloquée, ou en réinitialisant le BIOS. Le chiffrement de la partition contenant la clé est une bonne précaution, mais n'est pas non plus une solution imparable.

Il faut donc rajouter un élément de sécurité en encodant la clé privée elle-même. Vous n'aurez toujours pas besoin de mot de passe pour lancer des connexion, mais vous aurez besoin de la passphrase pour déchiffrer la clé avant de l'utiliser. Vous me direz quelle curieuse idée de supprimer les mots de passe de connexion pour les remplacer par un autre... C'est remplacer une astreinte par une autre ?

En fait la passphrase n'est pas égale à un mot de passe, comme son nom l'indique il s'agit d'une chaîne plus longue qu'un simple mot de passe, et son rôle ne consiste pas à identifier un utilisateur mais à déchiffrer la clé. En utilisant un agent ssh, la valeur déchiffrée de la clé est stockée en mémoire et utilisable pour toutes vos connexion ssh. Si vous ne connaissez pas la passphrase, la clé est inutilisable.

Pour vous faire comprendre l'enjeu et l'intérêt des clés encodée par passphrase, admettons que l'on vous aie volé vos clés. Le voleur essaie de se connecter via ssh à votre serveur distant, si vous avez créé une clé encodée par passphrase, openSSH lui demande alors la passphrase. S'il ne la connaît pas il ne peut rien faire de la clé privée. Si vous avez créé une clé sans passphrase il est par contre immédiatement identifié sur le serveur distant.

IL EST DONC PLUS QUE PRUDENT DE TOUJOURS UTILISER DES CLÉS AVEC PASSPHRASE. ET C'EST TOTALEMENT IMPÉRATIF POUR UNE POSTE TEL UN PORTABLE, TRÈS FACILEMENT VOLABLE OU PIRATABLE. BIEN ENTENDU LA PASSPHRASE NE DOIT FIGURER NULLE PART AILLEURS QUE DANS VOTRE TÊTE...

Rajouter une passphrase ou modifier la passphrase existante

Si vous avez créé une clé SSH sans passphrase utilisée sur de nombreux serveurs que va-t-il se passer si vous voulez maintenant bénéficier d'une passphrase ? Il n'y a pas besoin de créer une nouvelle clé et remplacer l'ancienne par celle-ci, ce qui représenterait un gros travail. ssh-keygen a une option qui permet de rajouter une passphrase à une clé SSH 

$ ssh-keygen -p
 Enter file in which the key is (/home/adele/.ssh/id_rsa):
 Key has comment '/home/adele/.ssh/id_rsa'
 Enter new passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved with the new passphrase.

De la même façon si vous voulez changer la passphrase existante il vous sera simplement demandé, avant de saisir la nouvelle phrase de montrer que vous connaissez l'ancienne en la saisissant.

Gérer la passphrase avec ssh-agent et ssh-add

Quand vous, utilisateur légitime, voulez vous connecter à votre serveur distant via SSH avec une clé chiffrée, le client ssh (openSSH dans notre cas) vous demande la passphrase pour rendre la clé utilisable. Il faut alors taper la passphrase à chaque utilisation de ssh. C'est très lourd me direz-vous ? C'est pourquoi existent ssh-agent et ssh-add.

openSSH fournit un utilitaires appelé ssh-agent, qui sert à stocker en mémoire votre clé décodée et ssh-add qui permet d'ajouter des clés à l'agent. Vous saisissez la passphrase au début de votre session, et votre clé déchiffrée reste utilisable durant toute la session. Lorsque vous quittez la session ou éteignez la machine, elle est effacée de la mémoire et il faudra ressaisir la passphrase lors de la prochaine connexion. l'utilitaire ssh-agent est bien entendu utilisable avec les bureaux graphiques comme Gnome ou KDE et vous n'aurez qu'à saisir votre passphrase à la connexion pour toute la durée de votre session de travail.

En ligne de commande voici ce que donnerait le lancement de ssh-agent, l'ajout de la clé et le contrôle que tout a bien marché.

adele@pc-00180:~$ ssh-agent /bin/bash

Les outils graphiques prennent cela en charge, mais en ligne de commande il ne faut surtout pas oublier de lancer ssh-agent avec un shell, ici bash.

On peut alors vérifier le paramètrage de l'environnement :

adele@pc-00180:~/.ssh$ env | grep -i SSH
SSH_AGENT_PID=6237
SSH_CLIENT=192.168.135.30 37851 22
SSH_TTY=/dev/pts/0
SSH_AUTH_SOCK=/tmp/ssh-acCLKr6236/agent.6236
CVS_RSH=ssh

Les deux éléments importants pour nous ici sont SSH_AGENT_PID et SSH_AUTH_SOCK. Ces informations vont permettre à d'autres applications de se connecter à ssh-agent et d'utiliser ses services. Le premier programme à l'utiliser est ssh-add qui lui fournit les clés à stocker.

Pour rajouter sa clé à l'agent, l'utilisateur adele devra simplement taper :

adele@pc-00180:~/.ssh$ ssh-add
Enter passphrase for /home/adele/.ssh/id_rsa:
Identity added: /home/adele/.ssh/id_rsa (/home/adele/.ssh/id_rsa)

La passphrase demandée est bien entendu celle saisie lors de la création de la clé. Cette passphrase peut-être n'importe quoi, de pas trop évident contenant des signes non alphabétiques et des chiffres assez long et pourtant mémorisable. Une technique classique est de choisir une phrase facile à mémoriser et de la torturer un peu ! Par exemple la phrase « il a pas les deux pieds dans le même sabot » pourrait donner Yl-aPale;2PdLmS!.

Une technique encore plus rigoureuse, simple et astucieuse, est exposée dans la page diceware (n'oubliez pas de lire la FAQ de cette page qui est très instructive). La page de diceware propose un lien vers une traduction française pour ceux que l'anglais rebute.

Si l'on vérifie avec l'option -l de ssh-add la clé entrée on constate que son empreinte (fingerprint) est la même que celle donnée lors de la génération de la clé.

adele@pc-00180:~$ ssh-add -l
1024 0f:91:b1:e7:77:e7:15:07:ce:3e:16:5b:d4:60:83:62 /home/adele/.ssh/id_rsa (DSA)

Pour connaître le fingerprint d'une installation ssh sur une machine il faut utiliser les options l et f de ssh-keygen. L'empreinte de la clé de l'utilisateur adele s'obtient par :

adele@pc-00180:~/.ssh$ ssh-keygen -lf id_rsa
4096 84:df:f3:e6:3c:46:c2:a9:42:2e:6e:7e:88:aa:45:d3  adele@pc-00180 (RSA)

On peut vérifier qu'il s'agit bien de la même empreinte que celle qui a été affichée lors de la génération du jeu de clés.

REMARQUE IMPORTANTE :  Pour que l'identification fonctionne, il manque tout de même un important petit quelque chose, l'installation de votre clé publique sur le serveur destinataire ! Nous allons voir cet aspect dans le chapitre suivant sur la configuration du serveur.

Écrire un commentaire

Quelle est la première lettre du mot cahu ?

Fil RSS des commentaires de cet article

À propos

Yakati.com - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.028s  Compression GZIP activée - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.com
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml