Authentification SSH par clés
Jusqu'à présent, nous avons pris pour habitude d’utiliser comme seul facteur d'authentification le mot de passe. Il faut néanmoins savoir qu'il est également possible d'utiliser un autre facteur, une clé. Cela est parfois préféré car la clé permet de ne pas avoir à retenir systématiquement des mots passe différents. Nous allons ici voir le fonctionnement général de cette méthode d'authentification.
Il est courant sur des serveurs SSH de n’autoriser uniquement l’authentification par clé afin de sécuriser ce protocole. La plupart du temps la génération de la clé se fait sous Linux sans trop de problème étant donné qu’OpenSSH y est nativement présent. Sous Windows toutefois, quelques manipulations sont à effectuer afin de générer et d’envoyer notre clé au serveur.
L'authentification par clés se fait donc via une paire de clés, le client va donc générer une paire de clés, une publique et une privée. Il va bien entendu garder sa clé privée pour lui et envoyer la clé publique au serveur SSH qui la stockera dans un endroit prévu cet effet.
Si vous souhaitez avec plus d'informations sur le système de clé privée/clé publique, je vous invite à lire ce cours écrit par Florian Burnel :
Sommaire
I. Génération de la clé
Étant donné qu'un client SSH peut être un client Linux ou un client Windows, nous allons voir comment générer cette paire de clés sous Linux en ligne de commande, et sous Windows via PuttyGen.
Générer une paire de clés sous Linux
Voyons tout d'abord comment générer une paire de clés sous Linux en ligne de commande. Pour cela, nous allons utiliser la commande "ssh-keygen" :
ssh-keygen
Si aucune option n'est spécifiée, une clé RSA de 2048 bits sera créée, ce qui est acceptable aujourd'hui en termes de sécurité. Si vous souhaitez spécifier une autre taille de clé, vous pouvez utiliser l'option "-b" :
ssh-keygen -b 4096
Par défaut, la clé va être stockée dans le répertoire .ssh/ de l'utilisateur courant (Exemple : /root/.ssh pour l'utilisateur root).
Note : Pour une sécurité correcte de vos communications, il est aujourd'hui recommandé d'utiliser des clés de 4096 bits.
Il va ensuite nous être proposé de saisir une passphrase, je vous recommande d'en mettre une ! Concrètement, nous avons vu qu'une clé pourra être envoyé à plusieurs serveurs pour éviter d'avoir à saisir un mot de passe, en tant que possesseur de la clé privée correspondant à la clé publique envoyée au serveur SSH sur lequel on souhaite se connecter, le serveur nous acceptera directement.
Néanmoins, si un tiers parvient à nous dérober notre clé privée, il arrivera à se connecter aux serveurs sans mot de passe. Ainsi, une passphrase permet la protection de notre clé privée via un mot de passe, ou plutôt une phrase de passe ("passphrase"). L'avantage par rapport à un mot de passe SSH est que vous n'avez qu'un mot de passe à retenir, celui de votre clé privée et pas un mot de passe par serveur SSH.
Une fois créées, vous pourrez donc voir vos clés dans le répertoire ".ssh" de l'utilisateur :
root@itc-serveur-01:~# ls -al .ssh total 20 drwx------ 2 root root 4096 juin 8 11:15 . drwx------ 10 root root 4096 juin 8 11:11 .. -rw------- 1 root root 3247 juin 8 11:18 id_rsa -rw-r--r-- 1 root root 745 juin 8 11:18 id_rsa.pub -rw-r--r-- 1 root root 444 avril 23 03:34 known_hosts
Pour rappel, nous nous situons toujours ici sur un Linux client, on remarque l'existence d'un autre fichier "known_hosts", il s'agit ici d'un fichier permettant d'identifier un serveur. Si vous vous connectez en SSH à plusieurs serveurs depuis votre utilisateur ("root" dans mon cas), votre fichier known_host va peu à peu se remplir. Cela entraîne entre autre le fait qu'une demande validation de la clé serveur est demandée à la première connexion du serveur mais pas lors des connexions suivantes.
Générer une paire de clés sous Windows
La plupart des connexions SSH sous Windows sont initialisées avec le client Putty qui est simple et efficace. L'outil PuttyGen permet de générer facilement un jeu de clés qui nous permettra de nous authentifier sur un serveur en les utilisant. On doit donc commencer par télécharger PuttyGen sur la page de téléchargement de Putty : http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Une fois téléchargé, nous l’exécuterons en cliquant sur l’exécutable :
Il faudra ensuite entrer notre passphrase si nous en avons saisi une lors de la création de la clé puis l’authentification se fera toute seule à l’aide des clés.
Il nous faut ensuite sélectionner le type de clé que nous voulons générer, “SSH-1 (RSA)” et “SSH-2-RSA” correspondent à la version du protocole pour des clés RSA et “SSH-2- DSA” pour la création d’une clé DSA.
Note : DSA et RSA sont similaires, RSA serait légèrement plus lent que DSA en termes de vérification mais plus rapide en termes de génération de signature. La différence entre les deux est assez minime pour des clés de même taille.
On peut également choisir le nombre de bits pour notre clé (au minimum 2048 !). On cliquera ensuite sur “Generate“. Il faudra alors bouger la souris pour générer de l’entropie et cela jusqu’à ce que la barre de chargement soit pleine :
Note : L’entropie est le fait de se servir d’événements aléatoires dans le système (mouvement de souris..) pour générer un chiffrement. Cela permet de rendre le chiffrement beaucoup dur.
Une fois terminé, nous aurons cet affichage :
On voit donc bien notre clé générée. On peut également, avant de l’enregistrer, ajouter un commentaire et une passphrase. La passphrase permet d’ajouter une couche de sécurité. C’est le même principe qu’un mot de passe. Si votre clé privée se retrouve dans les mains d’un attaquant, il lui faudra la passphrase pour l’utiliser. Il est possible de ne pas mettre de passphrase. Nous aurons alors un avertissement comme quoi il est préférable d’entrer une passphrase mais nous pourrons continuer. Il faut donc finir par cliquer sur “Save private key” et “Save public key”. Nous pourrons ensuite fermer PuttyGen.
II. Mettre la clé sur le serveur
Il nous faut maintenant faire l’opération consistant à envoyer notre clé publique sur le serveur afin de pouvoir s’y authentifier, sous Linux, une commande est prévue à cet effet. (“ssh-copy-id” sous Linux). Il nous faut pour cela établir une connexion SSH sur le serveur par mot de passe (une dernière fois) avec la commande "ssh-copy-id" :
ssh-copy-id utilisateur@serveur
Par exemple si je souhaite, en tant que client, ajouter ma clé sur le serveur SSH 192.168.240.132 pour l'utilisateur root :
ssh-copy-id [email protected]
Notez que par défaut, cette commande va envoyer la clé publique ".ssh/id_rsa.pub". On peut néanmoins, si l'on possède plusieurs paires de clés, spécifier la clé publique à envoyer au serveur, par exemple :
ssh-copy-id -i ~/.ssh/id_rsa_groupeServeurA.pub [email protected]
On devra donc saisir une dernière fois le mot de passe SSH de l'utilisateur visé sur le serveur SSH, puis nous aurons quelques messages de validation :
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Number of key(s) added: 1
Ici, on voit donc qu'une nouvelle clé a été ajoutée au serveur. Le message qui suit nous le valide :
Now try logging into the machine, with: "ssh '[email protected]" and check to make sure that only the key(s) you wanted were added.
En effet, maintenant que notre clé publique est présente sur le serveur que nous possédons dans notre répertoire .ssh sa clé privée associée, nous allons pouvoir nous connecter au serveur juste en saisissant la commande suivante :
ssh utilisateur@serveur
La passphrase de la clé publique nous sera demandée, puis on sera connecté en SSH à notre serveur.
L'avantage est le suivant : si cette même clé publique est envoyée à 30 autres serveurs, la passphrase sera la même pour toutes les connexions alors qu'il faudra retenir 30 mots de passe différents si vous utilisez la méthode d'authentification habituelle par mot de passe.
Dans le cas où vous êtes sous Windows ou alors que la méthode précédemment proposée n'est pas envisageable, on peut aussi faire cette manipulation manuellement. Il nous suffira alors simplement de copier le contenu de notre clé publique (par défaut ".ssh/id_rsa.pub") dans le fichier ".ssh/authorized_keys" de l'utilisateur du serveur visé.
Nous supposons ici que nous voulons une connexion sur le compte "root" (c’est bien sûr déconseillé dans un cadre réel). Nous allons donc aller dans le dossier "home" de cet utilisateur et créer le dossier ".ssh" s'il n’existe pas déjà :
mkdir .ssh
Le dossier ".ssh" est là où vont se situer les informations relatives aux comptes et aux connexions SSH de l’utilisateur. Nous y créerons le fichier "authorized_keys" s’il n’existe pas. Ce fichier contient toutes les clés publiques que permettent d’établir des connexions avec le serveur et l’utilisateur dans lequel il se trouve (selon le dossier "home" dans lequel il se trouve). Nous allons ensuite dans ce fichier mettre notre clé publique (éviter de mettre les "=== BEGIN===" et "===END===" générés automatiquement par PuttyGen).
Note : Sous Windows, il est possible de récupérer le contenu de la clé publique en l'ayant ouverte avec un simple bloc-notes pour le transférer dans le fichier "authorized_keys".
Il nous faudra ensuite donner les droits les plus restreints à ce fichier par sécurité et pour les exigences d’OpenSSH :
chmod 700 ~/.ssh -Rf
Notre clé est maintenant présente sur le serveur, il nous reste plus qu’à nous connecter pour tester !
Pour les curieux, vous pourrez aller voir sur votre serveur SSH le contenu du fichier "authorized_keys" qui se situe dans le répertoire .ssh de l'utilisateur destinataire. Oui, notez bien qu'une connexion SSH est une autorisation faite sur un utilisateur précis de la machine serveur. On peut avoir les identifiants pour se connecter à une machine Linux en tant qu'utilisateur "mickael" par exemple, mais pas en tant que root, ou inversement. Il s'agit en fait de l'accès à un compte sur une machine plutôt qu'à une machine, simple précision technique. 🙂
III. Lancer une authentification SSH par clé avec Putty
Maintenant que notre paire de clés est créé et que la clé publique a été envoyée au serveur SSH, nous allons pouvoir nous authentifier sur notre serveur SSH à l'aide de cette paire de clés.
Authentification SSH par clé sous Linux
Nous allons à présent nous authentifier sur notre serveur SSH depuis nos clients Linux, en ligne de commande et via l'utilisation de l'authentification par clés. Sous Linux en tant que client, nous utiliserons toujours la commande "ssh" pour se connecter à un serveur, cependant si un échange de clé a déjà été fait, aucun mot de passe nous sera demandé, il suffira alors de saisir la commande suivante :
ssh utilisateur@serveur
Par exemple :
ssh [email protected]
Nous serons alors directement orientés vers une session ouverte sur le serveur. Si, comme je l'ai proposé plus haut, vous disposez de plusieurs paires de clés et que vous souhaitez utiliser une clé privée précise, on peut alors utiliser l'option "-i" :
ssh -ri ~/.ssh/id_rsa_groupeServeurA [email protected]
Authentification SSH par clé sous Windows
Putty a maintenant besoin de savoir où se situe notre clé privée pour établir une communication valable avec le serveur. Après l’avoir lancé et avoir renseigné l’IP de notre serveur, nous nous rendrons dans la partie "Connexion" > "SSH" > "Auth" puis nous cliquerons sur "Browse" pour aller chercher notre clé privée à côté du champ "Private key file for authentication" :
Nous pourrons alors lancer la connexion en cliquant sur "Open". Il nous sera alors demandé l’utilisateur avec lequel nous voulons nous connecter. Il faut bien sûr saisir celui dont le "home" contient le ".ssh/authorized_keys" que nous venons de modifier.
Il faudra ensuite entrer notre passphrase si nous en avons saisi une lors de la création de la clé puis l’authentification se fera toute seule à l’aide des clés.
Note : Dans le reste du cours, sauf mention contraire, nous continuerons d'utiliser l'authentification par mot de passe. Sachez qu'en général, les commandes avec authentification avec clés et avec mot de passe sont les mêmes, c'est le processus d'authentification qui change.
