Dernière mise à jour de l'article : 15/10/2018.

Cet article est le deuxième d'une série de quatre :

1. SSH, pour se connecter en ligne de commande à un ordinateur distant
2. SSH, se connecter sans mot de passe à l'aide de la cryptographie
3. Reverse SSH, pour se connecter à un ordinateur distant protégé par un pare-feu
4. SSH, des tunnels pour tous les services

Dans le précédent épisode, nous avons montré comment se connecter en ligne de commande à un serveur distant, parfois par l'intermédiaire d'un — ou potentiellement plusieurs — serveur relais. Pour chaque serveur et à chaque connexion, un mot de passe différent est requis. Outre la nécessité rébarbative d'avoir à taper des mots de passe, il ne s'agit peut-être pas de la méthode la plus sécurisée. Une seule compromission suffit ; toute personne ayant connaissance du mot de passe peut se connecter.

L'authentification par clefs cryptographiques limite la possibilité de se connecter au seul propriétaire d'une clef. Souvent, cette clef est utilisée par un unique poste client. Ainsi, seule la connexion depuis ce poste client est possible. Néanmoins, le vol du poste client ou une copie malintentionnée de la clef cryptographique sont de l'ordre du possible. Si la clef est protégée par un mot de passe, le serveur distant ne peut être compromis — ou plus difficilement, tout du moins.

Grâce à l'authentification cryptographique, il n'est ainsi plus nécessaire de connaître ni d'avoir à taper les mots de passe des différents serveurs distants ; seul celui qui protège la clef importe. Pour ne pas avoir à taper systématiquement ce dernier, plusieurs mécanismes sont envisageables ; comme celui permettant de ne le taper qu'une seule fois par session, par exemple.

Le principe de la cryptographie asymétrique à clef publique a été énoncé dans un précédent article. Dans le cas qui nous concerne, la clef protégée par mot de passe est la clef privée de l'utilisateur. Cette clef est la seule à même de déchiffrer les messages envoyés par les serveurs distants, sur lesquels la clef publique correspondante a préalablement été enregistrée. C'est par ce mécanisme que les serveurs s'assurent de l'authenticité de leur correspondant.

Générer les clefs de chiffrement

Afin de pouvoir utiliser cette authentification cryptographique, il est d'abord nécessaire de générer une clef privée sur l'ordinateur CLIENT, puis d'enregistrer la clef publique correspondante sur les serveurs distants auxquels ont souhaite se connecter — ici, SERVEUR_B. On pourra alors potentiellement désactiver l'authentification par mot de passe, pour plus de sécurité. Cette dernière étape n'est pas forcément indispensable. En effet, si le mot de passe n'est que très rarement tapé sur un clavier — car remplacé par une authentification cryptographique — le risque de compromission est moindre.

On commence par générer un couple de clefs sur le poste client :

ssh-keygen -t ed25519

Puis on copie la clef publique sur le serveur distant :

ssh-copy-id -i .ssh/id_ed25519.pub USER_B@IP_SERVEUR_B

On peut alors se connecter au serveur, comme nous l'avons déjà vu :

ssh USER_B@IP_SERVEUR_B

Si un mot de passe a été donné lors de la création de la clef privé — ce qui n'est pas une obligation — il est ici demandé afin de pouvoir la déverrouiller. Sinon, nous voilà d'ores-et-déjà connectés, sans besoin de taper le mot de passe de USER_B.

Désactiver l'authentification par mot de passe

Une fois sur le serveur distant, il est possible de désactiver l'authentification par mot de passe. Pour cela, il faut d'abord se connecter en tant que super-utilisateur :

su -

Puis changer l'option de configuration correspondante :

sed -i "s/#PasswordAuthentication yes/PasswordAuthentication no/" /etc/ssh/sshd_config

Enfin, recharger la configuration du serveur SSH :

systemctl reload ssh

Sans oublier de se déconnecter :

exit

Article sous licence Creative Commons BY-SA 3.0 France.