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
Connexion à un serveur RHEL depuis RHEL (sans ssh-copy-id)	copie manuelle de la clé publique

Glissez pour voir

---

Générer une paire de clés

Ed25519, recommandé

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

Options interactives :

• Enter file : appuyez sur Entrée pour l'emplacement par défaut (~/.ssh/id_ed25519)
• Passphrase : entrez une phrase secrète (fortement recommandé)

Résultat :

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:abc123... bob@workstation

Ed25519 vs RSA

Ed25519 est l'algorithme recommandé depuis OpenSSH 6.5 (2014). Clé plus courte, plus rapide, aussi sûre qu'un RSA 4096. Utilisez RSA 4096 uniquement si vous devez interagir avec des systèmes très anciens qui ne supportent pas Ed25519.

RSA 4096, compatibilité maximale

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

Clé nommée pour un usage spécifique

# 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

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)

Sur RHEL, ssh-copy-id n'est pas toujours disponible. La méthode manuelle est aussi celle testée à l'examen :

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

SSH refuse silencieusement l'authentification par clé si les permissions de ~/.ssh/ ou authorized_keys sont trop larges. chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys sont impératifs.

---

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   103 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

Sortie de ssh-add -l :

256 SHA256:abc123... 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

# 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, il est recommandé de désactiver les connexions par mot de passe pour réduire la surface d'attaque :

# Sur le serveur
sudo vim /etc/ssh/sshd_config

PasswordAuthentication no
PubkeyAuthentication yes

# Redémarrer le service
sudo systemctl restart ssh        # Debian/Ubuntu
sudo systemctl restart 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 toujours actif	Vérifier /etc/ssh/sshd_config côté serveur
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 pratique

Durcir l'accès SSH par clé d'un utilisateur de service

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

Environnement : VM·Durée : ~20 min

Validé : 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.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

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.

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

À 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 est la méthode RHCSA
• 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é

Pour aller plus loin

• Exécuter des commandes distantes via SSH : ssh user@host cmd, pipes distants, scripts batch et collecte multi-serveurs.
• Durcir l'accès SSH : sshd_config : désactiver root, AllowUsers, fail2ban, réduire la surface d'attaque.
• Transférer des fichiers avec SFTP : Session SFTP interactive et batch, nécessite une authentification par clé configurée.

×

📖 Voir la documentation →