Créer et gérer des clés SSH

L'authentification par clé SSH est plus sûre qu'un mot de passe et permet d'automatiser les connexions. C'est le préalable à tout ce qui suit dans le parcours SSH, sans clé configurée, pas de connexion sans mot de passe, pas d'Ansible fiable, pas de pipeline CI/CD.

C'est un objectif direct RHCSA (domaine Manage Security, "Configure key-based authentication for SSH") et LFCS (domaine Networking, "Configure the OpenSSH server and client").

Ce que vous allez apprendre

• Générer une paire de clés Ed25519 (ou RSA 4096) avec une passphrase
• Déployer la clé publique sur un serveur avec ssh-copy-id
• Gérer authorized_keys manuellement quand nécessaire
• Utiliser ssh-agent pour mémoriser la passphrase en session
• Corriger les permissions de ~/.ssh/ qui bloquent silencieusement l'authentification
• Travailler avec plusieurs clés pour plusieurs serveurs ou rôles

Dans quel contexte ?

Situation	Technique
Se connecter sans mot de passe à un serveur	ssh-keygen + ssh-copy-id
Lancer Ansible sans être interrompu	clé sans passphrase ou ssh-agent
Accéder à GitHub / GitLab en SSH	clé dédiée + config ~/.ssh/config
Examen RHCSA, tâche "configure key-based auth"	ssh-keygen + authorized_keys
Poste client sans ssh-copy-id (OpenSSH de Windows)	copie manuelle de la clé publique

Glissez pour voir

---

Générer une paire de clés

ssh-keygen produit deux fichiers : la clé privée, qui ne quitte jamais votre poste, et la clé publique en .pub, destinée à être copiée sur les serveurs. Le choix de l'algorithme se fait ici et ne se change pas après coup.

Ed25519, recommandé

ssh-keygen -t ed25519 -C "bob@workstation"

La commande pose deux questions. À Enter file, appuyez sur Entrée pour garder l'emplacement par défaut (~/.ssh/id_ed25519). À Enter passphrase, saisissez une phrase secrète : elle chiffre la clé privée sur le disque, et un vol du fichier ne suffit plus à se connecter. Sortie mesurée sur Debian 13 (OpenSSH 10.0), empreinte propre à chaque clé :

Generating public/private ed25519 key pair.
Your identification has been saved in /home/bob/.ssh/id_ed25519
Your public key has been saved in /home/bob/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:wzADwtgppDzS9xC3BfogrcBzlncuuUHV7l0+w0Y1n+I bob@workstation

Ed25519 vs RSA

Ed25519 existe depuis OpenSSH 6.5 (2014) et c'est le type par défaut de ssh-keygen depuis OpenSSH 9.5 (2023) : sur Debian 13 comme sur AlmaLinux 10, ssh-keygen sans -t produit déjà une clé Ed25519 (mesuré). Clé plus courte, plus rapide, aussi sûre qu'un RSA 4096. Utilisez RSA 4096 uniquement face à des systèmes très anciens qui ne le supportent pas.

RSA 4096, compatibilité maximale

RSA reste utile face à un équipement ancien qui ne connaît pas Ed25519 : la clé est plus longue à générer et plus lourde à vérifier, mais elle est acceptée partout.

ssh-keygen -t rsa -b 4096 -C "bob@workstation"

Clé nommée pour un usage spécifique

L'option -f choisit le nom du fichier : une clé par usage limite les dégâts si l'une d'elles fuit, et permet de la révoquer sans toucher aux autres. Le commentaire -C rappelle à quoi sert la clé dans authorized_keys.

# Clé dédiée au serveur de backup
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup@workstation"

# Clé pour GitHub
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_github -C "bob@github"

---

Déployer la clé publique sur un serveur

Déployer une clé revient à ajouter son contenu public au fichier ~/.ssh/authorized_keys du compte cible. Les permissions de ce fichier et de son répertoire comptent autant que son contenu : trop ouvertes, le serveur SSH refuse la clé sans le dire au client.

Avec ssh-copy-id (méthode recommandée)

ssh-copy-id bob@192.168.1.10

ssh-copy-id se connecte par mot de passe, crée ~/.ssh/authorized_keys sur le serveur si nécessaire, et y ajoute votre clé publique.

Avec un port non standard ou une clé spécifique :

ssh-copy-id -p 2222 bob@192.168.1.10
ssh-copy-id -i ~/.ssh/id_ed25519_backup.pub bob@backup.example.com

Vérifier que ça fonctionne :

ssh bob@192.168.1.10
# doit se connecter sans demander de mot de passe (ou avec la passphrase de clé)

Manuellement (RHCSA, sans ssh-copy-id)

ssh-copy-id est livré avec le client OpenSSH, dans openssh-client sur Debian et openssh-clients sur RHEL (mesuré sur Debian 13 et AlmaLinux 10). La méthode manuelle reste à connaître : un poste sans ssh-copy-id, comme le client OpenSSH de Windows, ou un serveur où la connexion par mot de passe est déjà fermée, vous obligent à écrire authorized_keys vous-même :

1. Afficher la clé publique sur la machine cliente

   cat ~/.ssh/id_ed25519.pub

   Copiez la ligne entière (commence par ssh-ed25519).

2. Sur le serveur distant, préparer authorized_keys

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   echo "ssh-ed25519 AAAA... bob@workstation" >> ~/.ssh/authorized_keys
   chmod 600 ~/.ssh/authorized_keys

3. Vérifier la connexion

   ssh bob@192.168.1.10

Attention aux permissions

Posez chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys : c'est la bonne cible, sans marge d'erreur, et c'est ce qu'un audit attend.

Sachez toutefois ce qui fait réellement refuser, parce que la règle « tout ce qui n'est pas 600 est rejeté » est fausse et vous ferait chercher au mauvais endroit. Onze connexions réelles mesurées sur AlmaLinux 10 avec OpenSSH 9.9p1 :

Mode d'authorized_keys	Connexion
600, 644, 640	acceptée
660, 664, 606, 666	refusée

Glissez pour voir

Le discriminant est le droit d'écriture par le groupe ou par les autres, jamais la lisibilité. StrictModes refuse qu'un tiers puisse modifier le fichier, ce qui reviendrait à lui laisser ajouter sa propre clé. La même règle vaut pour ~/.ssh : mesuré sur AlmaLinux 10, 700, 750 et 755 passent, 770, 775 et 777 sont refusés.

Debian modifie cette règle. Son OpenSSH tolère l'écriture par le groupe quand ce groupe est le groupe privé de l'utilisateur et ne contient que lui : mesuré sur Debian 13, ~/.ssh en 770 ou 775 passe, seul 777 est refusé. Ne comptez pas sur cette tolérance, elle disparaît sur RHEL.

Le contrôle remonte aussi d'un cran au-dessus de ~/.ssh : un répertoire personnel en 770 suffit à faire échouer la connexion, alors que ~/.ssh et authorized_keys sont parfaits. Le serveur le dit, encore faut-il lire son journal :

Authentication refused: bad ownership or modes for directory /home/bloc25

Et si le fichier appartient à root, le message est tout autre, ce qui oriente vers un chown et non vers un chmod :

Could not open user 'bloc25' authorized keys '/home/bloc25/.ssh/authorized_keys': Permission denied

---

Permissions obligatoires de ~/.ssh/

C'est le premier point à vérifier si l'authentification par clé échoue :

# Répertoire SSH
chmod 700 ~/.ssh

# Clé privée : lisible uniquement par le propriétaire
chmod 600 ~/.ssh/id_ed25519

# Clé publique : peut être lue par tous
chmod 644 ~/.ssh/id_ed25519.pub

# Fichier de clés autorisées : critique
chmod 600 ~/.ssh/authorized_keys

# Fichier de configuration client
chmod 600 ~/.ssh/config

# Hôtes connus
chmod 644 ~/.ssh/known_hosts

Vérification rapide :

ls -la ~/.ssh/

Résultat attendu :

drwx------ 2 bob bob  4096 Apr  9 10:00 .
-rw------- 1 bob bob   411 Apr  9 10:00 id_ed25519
-rw-r--r-- 1 bob bob    97 Apr  9 10:00 id_ed25519.pub
-rw------- 1 bob bob   582 Apr  9 10:00 authorized_keys
-rw------- 1 bob bob   180 Apr  9 10:00 config

---

ssh-agent, mémoriser la passphrase en session

Si votre clé est protégée par une passphrase, SSH la demande à chaque connexion. ssh-agent mémorise la passphrase déverrouillée pour toute la session.

# Démarrer l'agent (si pas déjà démarré par le bureau)
eval "$(ssh-agent -s)"

# Ajouter la clé : demande la passphrase une seule fois
ssh-add ~/.ssh/id_ed25519

# Vérifier les clés chargées
ssh-add -l

La sortie de ssh-add -l donne la taille de la clé, son empreinte, son commentaire et son type. Mesurée sur Debian 13 :

256 SHA256:wzADwtgppDzS9xC3BfogrcBzlncuuUHV7l0+w0Y1n+I bob@workstation (ED25519)

ssh-agent dans les systèmes de bureau

Sur la plupart des distributions avec GNOME ou KDE, un agent SSH est démarré automatiquement à l'ouverture de session. La commande ssh-add -l vous dira si des clés sont déjà chargées.

Durée de vie limitée

Une clé chargée dans l'agent reste utilisable par tout processus de votre session. L'option -t borne cette exposition : passé le délai, l'agent oublie la clé et la passphrase sera redemandée.

# Clé mémorisée pendant 4 heures
ssh-add -t 4h ~/.ssh/id_ed25519

---

Gérer plusieurs clés

Quand vous utilisez plusieurs clés (serveurs de production, serveurs de backup, GitHub, GitLab), déclarez-les dans ~/.ssh/config :

# GitHub
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

# Serveurs de backup
Host backup.example.com
    User backupuser
    IdentityFile ~/.ssh/id_ed25519_backup

# Serveurs de prod (toutes les IP du sous-réseau)
Host 10.0.1.*
    User admin
    IdentityFile ~/.ssh/id_ed25519_prod

Sans cette configuration, SSH essaie les clés par défaut (id_ed25519, id_rsa...) dans l'ordre. Avec plusieurs clés, la déclaration explicite évite les erreurs "Too many authentication failures".

---

Désactiver l'authentification par mot de passe (côté serveur)

Une fois les clés déployées, désactivez les connexions par mot de passe pour réduire la surface d'attaque. Le piège est l'endroit où l'écrire : sshd_config commence par Include /etc/ssh/sshd_config.d/*.conf, et la première valeur lue l'emporte. Un fichier de ce répertoire qui dit PasswordAuthentication yes annule la ligne ajoutée plus bas dans sshd_config : mesuré sur Debian 13 et AlmaLinux 10 avec un tel fichier, sshd -T affiche toujours yes. Le cas n'a rien d'exotique : l'image AlmaLinux 10 livre déjà un 25-permitrootlogin.conf qui fixe PermitRootLogin yes. Écrivez donc la règle dans un fichier au numéro bas, lu en premier :

# Sur le serveur
echo 'PasswordAuthentication no' | sudo tee /etc/ssh/sshd_config.d/10-durcissement.conf
sudo sshd -t                                   # syntaxe : aucune sortie si tout va bien
sudo sshd -T | grep -i '^passwordauthentication'   # valeur effective : no

# Recharger le service
sudo systemctl reload ssh         # Debian/Ubuntu
sudo systemctl reload sshd        # RHEL/Fedora

Avant de désactiver les mots de passe

Vérifiez que votre clé fonctionne depuis une autre session avant de fermer la session en cours. Si vous perdez l'accès, il faudra accéder au serveur via la console (KVM, iLO, iDRAC...).

---

Dépannage

Symptôme	Cause probable	Action
Permission denied (publickey)	Permissions ~/.ssh/ incorrectes	Corriger avec chmod 700 ~/.ssh && chmod 600 authorized_keys
Permission denied (publickey)	Clé publique absente de authorized_keys	Vérifier avec cat ~/.ssh/authorized_keys côté serveur
SSH demande toujours le mot de passe	PasswordAuthentication yes lu en premier dans sshd_config.d/	sudo sshd -T | grep -i passwordauthentication, puis un drop-in 10-*.conf
Too many authentication failures	Trop de clés essayées	Ajouter IdentitiesOnly yes dans ~/.ssh/config
ssh-add -l : "Could not open a connection to your authentication agent"	ssh-agent non démarré	eval "$(ssh-agent -s)"
Clé acceptée en lab mais refusée sur RHEL	SELinux contexte incorrect sur ~/.ssh/	restorecon -Rv ~/.ssh

Glissez pour voir

---

Mettre en pratique

Configurer l'accès par clé pour son propre compte est une chose ; le faire proprement pour un utilisateur de service en est une autre. Sur une VM, ce lab vous fait générer une paire Ed25519, déployer la clé publique dans authorized_keys avec les bonnes permissions, puis durcir la connexion de ce compte.

Lab guidé Pratique

Apprendre à faire

Mettre en place un accès SSH par clé durci pour un utilisateur de service

$ dsoxlab run l4-ssh-key-auth-harden

Environnement : VM·Durée : ~20 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start l4-ssh-key-auth-harden vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run l4-ssh-key-auth-harden
dsoxlab check l4-ssh-key-auth-harden

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• Ed25519 est le choix recommandé en 2026, compact, rapide, sûr
• Les permissions ~/.ssh/ sont non négociables : 700 sur le dossier, 600 sur authorized_keys et les clés privées
• ssh-copy-id est la méthode rapide ; la copie manuelle dans authorized_keys sert quand l'outil manque, par exemple depuis Windows
• PasswordAuthentication no s'écrit dans un drop-in lu en premier, et se vérifie avec sshd -T
• ssh-agent élimine la saisie répétée de passphrase sans sacrifier la sécurité
• Sur RHEL, penser à restorecon si SELinux est actif et bloque l'authentification par clé

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →