Utiliser des clés SSH

Utiliser des clés SSH
Judicaël Courant
Le 17 février 2014
NB : les indications ci-dessous sont données de bonne foi mais leur exactitude ne
saurait être garantie. À vous de faire preuve de bon sens dans son application.
Ce texte est distribué sous la licence Creative Commons CC-BY-SA 3.0.
1 Introduction
Vous devez ou devriez utiliser l’authentification par clés pour SSH si vous êtes dans
l’une des deux situations suivantes :
Vous êtes le responsable d’un site ouvert sur Internet Si vous autorisez une connexion
par SSH avec simple mot de passe, vous faites probablement une erreur. Si votre
système est bien configuré, allez faire un tour dans les logs du serveur SSH. Vous
verrez qu’il y a de nombreuses tentatives d’accès venant d’un peu tous les pays du
monde. Tentative simples avec des noms de login usuels et des mots de passe fréquents 1 . Si vous avez laissé traîné un compte avec un mot de passe par défaut (par
exemple ubuntu/ubuntu sur une distribution Ubuntu GNU/Linux), il ne faudra
pas longtemps avant qu’un petit malin s’invite chez vous. Vous devriez interdire
l’accès par mot de passe et autoriser uniquement l’accès par clés.
Le site auquel vous voulez vous connecter n’accepte pas les mots de passe Notamment,
si ssh vous renvoie le message suivant lorsque vous voulez vous connecter :
Permission denied (publickey).
alors, il est probable que l’accès se fasse uniquement par clés.
Même si le site auquel vous vous connectez accepte les mots de passe, se connecter par
clé peut être une bonne idée pour automatiser certaines tâches (je n’en parlerai pas ici,
voir la page de manuel de ssh-agent et ssh-add pour avoir des infos).
2 Principe de l’accès par clés
Imaginons qu’Alice veut se connecter sur le serveur de Bob, qui possède un accès SSH
et autorise l’authentification par clés.
1. La dernière fois que j’ai regardé, sur un serveur derrière une freebox, c’était environ une tentative
par minute, sur une moyenne d’une semaine.
1
2.1 Avant le premier accès
2.1.1 Génération d’une clé
Pour cela, elle va créer une clé cryptographique sur sa machine. Plus exactement,
cette clé possède deux morceaux : une partie qu’on appelle la clé publique, qu’elle va
donner à Bob et une partie appelée clé privée, qu’elle va précieusement garder à l’abri
des indiscrets.
Elle va lancer ouvrir un terminal sur sa machine. Elle va d’abord vérifier qu’elle a un
répertoire .ssh dans son $HOME et le créer sinon (mkdir .ssh).
Puis elle va faire en sorte d’être la seule à avoir accès en lecture et écriture à ce
répertoire :
chmod go-rxw .ssh
(il peut être bon de vérifier que tout va bien et qu’aucun droit supplémentaire n’a été
mis sous forme d’ACL avec getfacl)
Elle va alors pouvoir générer sa paire clé privée/clé publique :
cd .ssh
ssh-keygen -f alice-2014
ssh-keygen demande alors :
Enter passphrase (empty for no passphrase):
Elle va alors rentrer un mot de passe, en évitant d’utiliser un mot de passe qu’elle a pu
donner à quelqu’un d’autre. 2
ssh-keygen lui demande confirmation du mot de passe :
Enter same passphrase again:
Puis lui dit :
Your identification has been saved in cle-alice-2014.
Your public key has been saved in cle-alice-2014.pub.
The key fingerprint is:
Suivi de quelques informations et d’un joli dessin sans intérêt pour l’instant.
Generating public/private rsa key pair.
Dans son répertoire .ssh, elle peut vérifier que deux fichiers ont été créés : un fichier
cle-alice-2014, qui contient sa clé privée (chiffrée avec le mot de passe qu’elle a donné)
et un fichier cle-alice-2014.pub qui contient sa clé publique.
La clé publique n’a pas besoin d’être confidentielle mais la clé privée doit le rester.
Alice crée un lien symbolique de sa clé privée vers un fichier appelé id_rsa qui sera le
fichier utilisé par défaut par ssh lors de ses futures connexions :
ln -s cle-alice-2014 id_rsa
2. Donc surtout pas son mot de passe de messagerie, de google ou facebook. Gérer ses mots de passe
est difficile mais elle utilise keepassx pour cela.
2
2.1.2 Transmission de la clé publique à Bob
Alice fait alors parvenir à Bob sa clé publique, de préférence par un moyen sécurisé. Il y a au moins deux façons de faire. La première est de mettre la clé publique
cle-alice-2014.pub sur un support amovible (clé USB, CD-ROM) qu’elle donne à Bob,
de la main à la main.
La seconde est d’envoyer la clé publique à Bob par mail et de s’assurer que personne
n’a trafiqué la clé sur le trajet. Pour cela, lorsqu’il reçoit la clé publique, Bob la sauve
dans un répertoire, se place dans ce répertoire et lance la commande
sha512sum cle-alice-2014.pub
Pour obtenir une somme de contrôle cryptographique de ce fichier publique (une suite
assez longue mélangeant des chiffres et les lettres A à F)
Il appelle alors Alice par téléphone, s’assure que c’est bien elle qui répond, lui demande
de taper la même commande sur son ordinateur et lui lit la suite de chiffres et lettres
qu’il obtient : Alice s’assure que le résultat est le même que chez elle. Si c’est le cas, Bob
peut en conclure que la clé envoyée n’a pas été modifiée.
2.1.3 Mise en place de la clé sur le serveur de Bob
Bob va alors sur son serveur, dans le répertoire d’Alice (généralement, /home/alice).
Là, il crée un répertoire /home/alice/.ssh s’il n’existe pas déjà. Il s’assure qu’Alice
est propriétaire du répertoire et est la seule à y avoir des droits (lecture, écriture, exécution). Il y copie la clé publique d’Alice puis copie le contenu de celle-ci dans un fichier appelé authorized_keys (si ce fichier n’existe pas déjà, il suffit de copier le fichier
cle-alice-2014.pub, sinon il édite le fichier et y colle comme dernière ligne l’unique
(longue) ligne du fichier cle-alice-2014.pub.
Il vérifie au passage que la configuration de son serveur interdit la connexion par mot de
passe : en tant que super-utilisateur, il édite le fichier /etc/ssh/sshd_config et vérifie les
lignes contenant PubkeyAuthentication, RSAAuthentication, PermitEmptyPasswords,
PasswordAuthentication et UsePAM. Il s’agit en effet de s’assurer que l’authentification par RSA est autorisée et que les autres sont interdites. En résumé, ces lignes (pas
nécessairement contigües dans le fichier) doivent être au final :
# Autorisons l’authentification avec clefs.
PubkeyAuthentication yes
# Ceci vieille version du protocole, ne plus utiliser.
RSAAuthentication no
# surement pas de mots de passe vides !
PermitEmptyPasswords no
# pas de mots de passe du tout
PasswordAuthentication no
# pas d’usage de PAM qui autoriserait sans doute les mots de passe.
UsePAM no
3
(les lignes commençant par un dièse sont des commentaires)
S’il a dû modifier ces lignes, il demande au service ssh de prendre en compte ses
modifications :
service ssh reload
2.1.4 Connexion d’Alice
Alice peut maintenant se connecter avec sa clé sur le serveur de Bob
ssh le-serveur-de-bob
ssh lui demande alors son mot de passe. Si Alice rentre celui-ci correctement, la
connexion s’établit.
4