Suite à un précédent article concernant la sécurisation d’un serveur linux, j’étais resté vague sur la mise en place de l’authentification ssh par clé privée.
L’authentification par clé privée augmente la sécurité d’un serveur au niveau du processus de connexion. Au lieu d’un simple couple identifiant / mot de passe, il faut désormais être en possession de deux informations secrètes à la fois :
- une clé privée (un fichier que tu dois conserver précieusement et surtout secrètement)
- un mot de passe que nous appelleront passphrase (pour décrypter la clé, et ainsi pouvoir l’utiliser)
Génération des clés
Pour mettre en place ce type d’authentification, il va falloir générer 2 clés : La clé privée et la clé publique.
La clé publique n’a pas besoin d’être secrète. C’est une clé qui est capable de reconnaître sa clé privée (cryptographie asymétrique). Cette clé sera donc placée sur le serveur afin qu’elle puisse vérifier notre clé privée lorsque nous voudrons nous connecter.
Sous linux
Générons notre paire de clé :
ssh-keygen -t rsa -b 4096 -C votre@email.com
Une passphrase est demandé, gardes la bien dans ta tête ou dans un gestionnaire de mot de passe. Elle sera utile par la suite !
Ici on génère une clé RSA de 4096 bits avec en commentaire ton adresse mail (juste afin de s’y retrouver si tu as plusieurs clés à générer)
Par défaut ssh-keygen génère une clé RSA de 2048 bits avec en commentaire : ton@email.com
A toi de voir si tu préfère utiliser un algorithme RSA ou DSA. Il n’y a pas de plus ou moins costaud mais DSA est plus récent.
Pour la taille de la clé, il est recommandé de faire au moins du 2048 bits pour le RSA. En DSA, la clé fait obligatoirement 1024 bits.
Tes deux clés sont générées par défaut dans : ~/.ssh/
Tu y retrouve tes deux clés :
- id_rsa.pub : La clé publique
- id_rsa : La clé privée
Sous windows
Utilise la suite putty et génère tes clés avec PuTTYgen.
Mise en place de la clé publique sur le serveur
Il faut maintenant envoyer la clé publique sur le serveur et la placer dans le fichier ~/.ssh/authorized_keys. Ce fichier est utilisé lors de l’authentification pour déterminer si la clé privée de l’utilisateur est conforme à la clé publique inscrite dans le fichier.
Envoi de la clé si le serveur autorise l’authentification par mot de passe (sous client linux)
Nous allons utiliser ssh-copy-id qui permet d’envoyer notre clé publique automatiqument dans le fichier ~/.ssh/authorized_keys en remettant les bons droits d’écriture sur le fichier.
ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<ipaddress>
Si le port SSH n’est pas sur le port standard (22) :
ssh-copy-id -i ~/.ssh/id_rsa.pub -p <num_port> <username>@<ipaddress>
Autre méthode
Copie le contenu de ta clé publique dans ~/.ssh/authorized_keys sur le serveur.
Configuration sur le serveur
Côté serveur, nous allons maintenant indiquer à ssh que nous souhaitons permettre la connexion par clés.
RSAAuthentication yes
PubkeyAuthentication yes
StrictModes yes
Avec StrictMode = yes, donne les bons droits à ton homedir sinon l’authentification risque d’échouer :
chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Gardons pour le moment la possibilité de nous connecter avec un mot de passe ssh classique au cas où. Nous verrons pas la suite comment n’autoriser que l’authentification par clé.
Recharge le serveur ssh :
service sshd reload
Connexion avec ta clé privée
Sous linux
Modifie ou crée le fichier ~/.ssh/config et adapte le avec l’exemple ci-dessous :
Host serveur1
HostName serveur1.domain.tld
User remi
Port 22
IdentityFile /home/remi/.ssh/id_rsa
Host serveur2
HostName 192.168.1.120
User remi
Port 22
IdentityFile /home/remi/autre_cle/private_key
HostName : Adresse ip ou nom de domaine du serveur
User : Utilisateur à utiliser en login
Port : Numéro du port à utiliser
IdentifyFile : Chemin vers ta clé privée à utiliser
Maintenant connecte-toi au serveur :
ssh serveur1
Indique ta passphrase (la clé de déverrouillage de la clé privée que nous avons généré)
Si tout va bien tu es maintenant connecté au serveur.
Tu peux ajouter ta clé privée dans ton agent ssh pour éviter de devoir taper ta passphrase à chaque fois (il faudra quand même le refaire à chaque ouverture de session) :
ssh-add ~/.ssh/id_rsa
Indiquez ta passphrase pour déverrouiller la clé.
Maintenant connecte-toi au serveur :
ssh serveur1
La passphrase ne t’es pas demandée et tu es connecté.
Il est possible aussi de se connecter directement sans passer par le fichier de config :
ssh <username>@<ipaddress>
Petite astuce : Avec le gestionnaire de mot de passe keepassXC, il est possible de déverrouiller automatiquement les clés privées qui sont enregistré dans votre base de mot de passe à son ouverture. Pour une fois que sécurité et praticité s’entendent !
Sous windows
Utilise la suite putty et ajoute ta clé publique sur Pagent.
Désactiver l’authentification par mot de passe
Attention ! Sois sûr que ton accès par clé privée est bien opérationnel sinon tu perdra tout accès ssh à votre machine !
Seul les authentifications par clé seront possibles !
Modifie la configuration du fichier /etc/ssh/sshd_config :
ChallengeResponseAuthentication no
PasswordAuthentication no
Puis redémarre le serveur ssh :
service sshd reload
Terminé !
14 septembre 2021 à 12h06
Bonjour,
Une question théorique : La clé rsa est composée par 2 nombres publics qu’on appelle e et n , et d’une d’un nombre d que l’on gardé privé. e et n étant premiers entre eux et e et d étant congrus à 1 modulo n.
Mais dans la clé rsa id_rsa, on ne voit qu’une clé ! La clé publique contient elle 2 nombres ?
Plus exactement, la clé publique contient un texte et pas un nombre. Comment se fait la transformation ?
Ou peut on trouver le source
11 décembre 2024 à 17h16
Oui la clé publique contient bien les deux nombre e et n. Ils sont encodés dans une suite de format : d’abord un format de structure de donnée, puis un format binaire, puis une format Base64, puis on ajoute les délimiteurs BEGIN et END.
Pour retrouver les deux nombres, on fait l’encodage inverse, on passe du Base64 au binaire, puis du binaire au format structurel qui contient les deux nombres.
1 octobre 2020 à 14h12
Bonjour,
je suis débutant.
j’ai des utilisateur qui ont dèja leur clés ssh (.pkk) que faire sur le serveur (centos 7.7) pour autoriser la connexion avec leurs clé ssh.
Merci d’avance
1 octobre 2020 à 14h27
Résolu Merci a vous
4 septembre 2020 à 15h08
Bonjour,
Un petit message pour vous remercier de la clarté de ce tuto !
22 avril 2020 à 11h36
Bonjour,
C’est vraiment un tuto très clair et très opérationnel. Il manque d’indiquer après la commande keygen que c’est là qu’est demandé une passphrase dont il sera question plus loin.
Sur Ubuntu 18 le fichier config ne semble pas pris en compte mais avec ssh root@serveur, ça fonctionne sans souci.
Enfin je ne suis pas sûr de bien comprendre. Vous dites « un mot de passe (pour décrypter la clé, et ainsi pouvoir l’utiliser) » Mais n’est-ce pas la passphrase qui permet de décoder la clé et pas le mot de passe?
Mais en tout cas merci. Si tous les tutos pouvaient être comme celui-là….
22 avril 2020 à 15h01
Bonjour Jean-Claude,
Merci pour votre commentaire très positif !
Pour le mot de passe, effectivement, il s’agit de la passphase, et il est plus cohérent de l’appeler ainsi tout le long du tuto.
Je mettrai à jour très prochainement le post avec vos commentaires, merci 🙂
9 mai 2021 à 15h08
Excellent tutoriel. Merci Monsieur.
Je comprends ici qu’il vaut mieux utilisé le terme passphrase pour éviter de confondre avec le « mot de passe » de l’utilisateur sur la machine distante. La connexion via ce mot de passe est désactivée en fin de tutoriel.
Aussi, n’est ce pas une mauvaise pratique d’autoriser la connection ssh par l’utilisateur « root » ? comme on voit dans le commentaire de Jean-Claude. Peut-être que cela vaut le coup d’aborder l’option de la configuration du serveur ssh dans ce tutoriel étant donné que vous expliquez très bien 🙂
11 mai 2021 à 11h48
Bonjour Arthur,
Je viens de mettre à jour le tuto pour que ce soit plus clair entre mot de passe et passphrase.
Pour répondre à votre question, oui il vaut mieux éviter de laisser l’accès root en ssh. Un pirate commencera toujours par tenter de forcer l’accès root. S’il est désactivé, c’est une vulnérabilité de moins. Aussi, on peut éviter de créer des utilisateurs qui s’appelle « admin » ou tout autre nom trop commun que les pirates tenteront de forcer.
J’aborde ces sujets dans cet autre tuto qui concerne la sécurisation d’un serveur linux ici : https://www.remipoignon.fr/securiser-son-serveur-linux/
J’aborde aussi le changement du numéro de port SSH qui permet de réduire considérablement les tentatives d’attaques SSH