Le protocole SSH – Authentification par clés

Comme nous l’avons vu dans le précédent article sur le protocole SSH, la création d’une session SSH passe par plusieurs étapes afin de garantir une communication sécurisée entre le client et le serveur SSH et permet ainsi de garantir l’intégrité et la confidentialité des données.

Méthodes d’authentification SSH

On a vu aussi que quelque-soit la méthode d’authentification utilisée pour SSH, la communication sera cryptée augmentant ainsi sa sécurité.

La méthode d’authentification par mot de passe est celle qui est définie par défaut. Vous utilisez ainsi un login/mot de passe pour vous connecter à votre compte système.

Or, cette méthode d’authentification n’est pas recommandée car elle reste toujours vulnérable à une attaque par force brute. En effet, ce type d’attaque est très répondu aujourd’hui et plusieurs outils automatisés existent pour faciliter le travail du pirate.

Sécuriser un mot de passe SSH

Si vous avez tout de même une raison pour choisir ce type d’authentification, tâchez de définir des mots de passe puissants comme suit :

• Tout d’abord, le mot de passe doit être long avec au moins 15 caractères (plus long, mieux c’est).
• Ensuite, évitez d’utiliser votre nom, date de naissance, information personnelle et toute suite logique comme 123, abc …
• D’autre part, utilisez une combinaison de numéros, lettres à la fois majuscules, minuscules et caractères spéciaux.

Voici un exemple de mot de passe : ?MoN_mOt/-2-/P@0Sse.;

Vous pouvez aussi vous servir des générateurs de mot de passe en ligne comme celui disponible sur le site officiel de SSH . Si vous vous souciez par contre de la manière de garder vos mots de passe, utilisez le logiciel keypass.

Mise en place d’une authentification par clés

Sinon, il faut éviter au mieux d’utiliser cette méthode d’authentification et passer plutôt par une authentification par clés.

Pour cela, utilisez la commande ssh-keygen pour générer une pair de clés RSA publique/privé.

[utilisateur@localhost ~]$ ssh-keygen -b 4096
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/utilisateur/.ssh/id_rsa):Entrée
 Enter passphrase (empty for no passphrase):Entrée
 Enter same passphrase again:Entrée
 Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
 Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
 The key fingerprint is:
 SHA256:92QQKzEDgAroIQgdMu4EvaoFZD9gK3eQ5mEiDJiPIK0 utilisateur@localhost.localdomain
 The key's randomart image is:
 +---[RSA 4096]----+
 |&=.+….+ .      |
 |#X@      + o     |
 |@%=+    . o      |
 |Eo=o.    . .     |
 |.= ..   S . o    |
 |. .      . +     |
 |..          .    |
 |.                |
 |                 |
 +----[SHA256]-----+

Cette commande va générer deux fichiers dans le répertoire choisi :

• id_rsa correspondant à la clé privée
• id_rsa.pub correspondant à la clé publique

L’option -b permet de définir la longueur de la clé générée à 4096 qui est mieux que la valeur par défaut de 2048.

Pour info : la passphrase est un mot de passe permettant de crypter votre clé privé, nous ne l’avons pas spécifié pour ce tutoriel mais son utilisation est recommandée car avec elle, même un pirate ayant pu récupérer votre clé privé ne pourra pas l’utiliser.

Maintenant qu’on possède notre pair de clés public / privé, il faudra copier la clé publique dans le fichier authorized_keys du serveur.

La commande ssh-copy-id permet aussi de le faire comme suit :

[utilisateur@localhost .ssh]$ ssh-copy-id -i id_rsa.pub utilisateur@localhost
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "id_rsa.pub"
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:oZLX2xzvHhLMmkYgT+JkHCEO9407JMAvtQEGBYaUPqw.
ECDSA key fingerprint is MD5:f4:61:17:4c:ee:f4:99:69:7f:bc:59:13:38:06:08:ff.
Are you sure you want to continue connecting (yes/no)? yes
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

utilisateur@localhost's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'utilisateur@localhost'"
and check to make sure that only the key(s) you wanted were added.

En vérifiant sous le répertoire /home/utilisateur/.ssh on s’aperçoit qu’un fichier authorized_keys est disponible et contient notre clé publique.

[utilisateur@localhost .ssh]$ cd .ssh
[utilisateur@localhost .ssh]$  ll
 total 16
 -rw-------. 1 utilisateur utilisateur  754  3 mai   07:46 authorized_keys
 -rw-------. 1 utilisateur utilisateur 3243  3 mai   07:31 id_rsa
 -rw-r--r--. 1 utilisateur utilisateur  754  3 mai   07:31 id_rsa.pub
 -rw-r--r--. 1 utilisateur utilisateur  348  3 mai   07:45 known_hosts 
[utilisateur@localhost .ssh]$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+gixhK67e3FScoa+sj8E4u679aK7vXJ……………………………………………………YFv3a1mcE/fYLBUV642fjiziwSPmRPkxuILCOLA0EuZTuI6+UavG12Rry9iYbiUI1vqkOzb8lw== utilisateur@localhost.localdomain

Ensuite, récupérez la clé privé (id_rsa) sur votre poste de travail. Dès lors, vous pourrez supprimer les deux fichiers (id_rsa et id_rsa.pub) de votre serveur distant.

Dorénavant, le serveur distant acceptera toute connexion de l’utilisateur possédant la bonne clé privée.

Test du résultat

Pour confirmer ceci, démarrez une nouvelle connection SSH à l’aide de votre client SSH préféré. Spécifiez ensuite la clé privé que vous détenez à présent. Voici un test concluant en utilisant le client MobaXterm.