Se connecter en SSH avec des clés : ssh-keygen, agent et config

À la fin de ce tutoriel ssh clé, vous saurez générer une paire Ed25519 (ssh-keygen), poser ~/.ssh/ (700/600), installer la publique (ssh-copy-id), utiliser ~/.ssh/config et l’agent, puis aperçu durcissement sshd — sans coller de clé privée réelle.

Niveau : Débutant · Temps estimé : 40–50 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-10

Slug proposé : linux-ssh-cles · Série : P5 Linux Basics · Remplace / fusionne : N/A — création

Prérequis

• Avoir suivi Écrire vos premiers scripts bash (chemins, permissions, édition de fichiers)
• Client + serveur lab (VM, WSL ou second user) Ubuntu/Debian ou Rocky/Alma 9
• OpenSSH client/serveur ; aucune clé privée de production
• Réseau lab uniquement (local / VPC) — pas de prod

Coût estimé : 0 € en lab local. Sur cloud : Free Tier ; préférez souvent SSM plutôt qu’ouvrir SSH sur 0.0.0.0/0.

Ce que nous allons construire

Pourquoi clés > mots de passe
  → ssh-keygen -t ed25519 (+ passphrase)
  → ~/.ssh/ 700 · clés 600 · authorized_keys
  → ssh-copy-id / copie manuelle de la publique
  → ssh user@host · ~/.ssh/config (Host alias)
  → ssh-agent + ssh-add (bref)
  → Aperçu durcissement sshd (+ renvoi ufw/fail2ban)
  → Vérification · erreurs · quiz · FAQ

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « SSH Linux : ssh-keygen Ed25519, authorized_keys, agent et ~/.ssh/config — lab junior DevOps ».)

Dernier chapitre cœur de Linux Basics (8/8). Les scripts du tuto 7 partent désormais en distant. AWS : démarrer avec AWS + EC2/SSM ; évitez remote-exec opaque (Terraform).

Étape 1 — Pourquoi une ssh clé plutôt qu’un mot de passe

SSH chiffre la session. L’auth peut être un mot de passe (bruteforce / phishing) ou une paire de clés :

Élément	Rôle
Clé privée (id_ed25519)	Reste sur votre machine client ; ne quitte jamais le disque / l’agent
Clé publique (id_ed25519.pub)	Peut être copiée sur les serveurs (authorized_keys)
Passphrase	Chiffre la clé privée au repos (2ᵉ facteur local)

Avantages : pas de mot de passe à chaque login, révocation = supprimer une ligne dans authorized_keys, scripts/CI sans secret en clair. En 2026 : Ed25519 par défaut ; RSA seulement en legacy.

Règle lab : jamais de clé privée réelle dans un article, ticket ou Git — placeholders (VOTRE_USER, IP_OU_HOSTNAME).

Étape 2 — Générer la paire : ssh-keygen -t ed25519

Sur le client :

mkdir -p ~/.ssh && chmod 700 ~/.ssh
# Ed25519 + passphrase forte ; suffixe _lab pour ne pas écraser une clé pro
ssh-keygen -t ed25519 -a 100 -C "lab-devops@$(hostname)-2026" -f ~/.ssh/id_ed25519_lab
chmod 600 ~/.ssh/id_ed25519_lab
# Publique seulement (placeholder de forme) :
cat ~/.ssh/id_ed25519_lab.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI…placeholder… lab-devops@host-2026
ls -la ~/.ssh/

Option	Effet
-t ed25519	Algorithme moderne (court, rapide, sûr)
-a 100	Rounds KDF passphrase (plus coûteux à brute-forcer)
-C / -f	Commentaire ; chemin fichier (_lab = jetable)

Rocky/Alma : même ssh-keygen. RSA legacy (à éviter) : -t rsa -b 4096 seulement si la cible l’exige. Privée = 600, dossier = 700 — sinon OpenSSH : Permissions are too open.

Empreinte utile pour inventaire (ne révèle pas la privée) :

ssh-keygen -lf ~/.ssh/id_ed25519_lab.pub
# 256 SHA256:…placeholder… lab-devops@host-2026 (ED25519)

Étape 3 — Installer la publique : ssh-copy-id ou copie manuelle

Cible : user non-root (VOTRE_USER) avec accès temporaire (mot de passe lab ou console).

# Méthode A — ssh-copy-id (Ubuntu/Debian : paquet openssh-client)
ssh-copy-id -i ~/.ssh/id_ed25519_lab.pub VOTRE_USER@IP_OU_HOSTNAME

# Méthode B — manuelle (si ssh-copy-id absent, ex. minimal Rocky)
PUB="$(cat ~/.ssh/id_ed25519_lab.pub)"
ssh VOTRE_USER@IP_OU_HOSTNAME "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
  echo '$PUB' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

authorized_keys = une ligne publique par clé. Jamais la privée. Ubuntu/Debian : openssh-client / openssh-server. Rocky/Alma : dnf install openssh-clients openssh-server puis systemctl enable --now sshd.

Après ssh-copy-id, un second ssh sans -i peut encore échouer si l’agent propose d’autres clés : passez à l’étape config + IdentitiesOnly yes.

Étape 4 — Connexion et ~/.ssh/config (Host alias)

# Connexion explicite avec la clé lab
ssh -i ~/.ssh/id_ed25519_lab VOTRE_USER@IP_OU_HOSTNAME

# Config client : alias + IdentityFile (éditez avec nano/vim)
cat >> ~/.ssh/config << 'CONF'
Host lab-vm
    HostName IP_OU_HOSTNAME
    User VOTRE_USER
    IdentityFile ~/.ssh/id_ed25519_lab
    IdentitiesOnly yes
CONF
chmod 600 ~/.ssh/config

# Désormais :
ssh lab-vm

Directive	Intérêt
Host lab-vm	Alias court (pas l’IP à chaque fois)
HostName	IP ou DNS réel
User	Compte distant
IdentityFile	Quelle privée utiliser
IdentitiesOnly yes	N’essaie pas toutes les clés de l’agent (évite « Too many authentication failures »)

Plusieurs Host = labs / bastion (ProxyJump bastion en VPC). AWS : comparez EC2 + SSM sans SSH public.

Exemple bastion (lab VPC) — à adapter, placeholders seulement :

Host bastion
    HostName IP_BASTION
    User VOTRE_USER
    IdentityFile ~/.ssh/id_ed25519_lab
Host app-interne
    HostName 10.0.1.20
    User VOTRE_USER
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_lab
    IdentitiesOnly yes

Tip DevOps : scp lab-vm:/tmp/out.log . et ssh lab-vm 'journalctl -u mon-service -n 50' réutilisent la même config. Ne commitez jamais IdentityFile pointant vers une clé pro dans un dépôt partagé.

Étape 5 — Agent ssh-add (bref)

L’agent garde la clé déchiffrée en mémoire : passphrase une fois par session, pas à chaque ssh/scp/git.

# Démarrer l’agent si besoin (souvent déjà là sous desktop)
eval "$(ssh-agent -s)"

# Charger la clé lab (demande la passphrase)
ssh-add ~/.ssh/id_ed25519_lab

# Lister les empreintes chargées (pas le matériel de la clé)
ssh-add -l

Sous WSL, rechargez après reboot. Gardez la passphrase : protection si le disque fuit.

ssh-add -l doit lister l’empreinte lab ; ssh-add -D vide l’agent (utile en fin de session partagée). Ne désactivez pas la passphrase « pour aller plus vite » en CI : préférez un secret manager / rôle cloud plutôt qu’une clé sans protection sur un runner.

Étape 6 — Sécuriser sshd (aperçu lab + avertissement)

Sur le serveur, seulement après un login clé OK (et console/SSM de secours) :

# Aperçu — ne coupez pas votre seule session
sudo grep -E '^(PasswordAuthentication|PermitRootLogin|Port|#Port)'   /etc/ssh/sshd_config /etc/ssh/sshd_config.d/* 2>/dev/null || true
# Drop-in lab typique (/etc/ssh/sshd_config.d/99-lab-hardening.conf) :
#   PasswordAuthentication no
#   PermitRootLogin no
#   # Port 22  ← obscurité seule, pas un pare-feu
# sudo systemctl reload ssh    # Debian/Ubuntu
# sudo systemctl reload sshd   # Rocky/Alma

Paramètre	Conseil
PasswordAuthentication no	Après keys OK + secours (console / SSM)
PermitRootLogin no	User + sudo
Port	Cosmétique ; vraie barrière = SG / ufw + clés

Lock-out si vous coupez les mots de passe trop tôt. Bonus durci : ufw + fail2ban (hors cœur).

Étape 7 — Vérification et nettoyage lab

# 1) Publique bien présente côté serveur
ssh lab-vm "grep -c 'lab-devops@' ~/.ssh/authorized_keys || true"

# 2) Auth par clé (verbose utile en debug — Ctrl+C après succès)
ssh -v lab-vm "echo OK && hostname && whoami"

# 3) Permissions client
stat -c '%a %n' ~/.ssh ~/.ssh/id_ed25519_lab ~/.ssh/config 2>/dev/null || 
  stat -f '%Lp %N' ~/.ssh ~/.ssh/id_ed25519_lab ~/.ssh/config

# Nettoyage OPTIONNEL de la clé lab seulement (ne touchez pas vos clés pro)
# ssh-add -d ~/.ssh/id_ed25519_lab 2>/dev/null || true
# rm -f ~/.ssh/id_ed25519_lab ~/.ssh/id_ed25519_lab.pub
# Sur le serveur : retirez la ligne correspondante dans authorized_keys
echo "Lab SSH : vérifiez puis nettoyez la clé _lab si jetable — OK"

Validé si : ssh lab-vm ouvre une session sans mot de passe compte (passphrase locale éventuelle via agent), whoami = VOTRE_USER, permissions 700/600.

Erreurs fréquentes

Symptôme	Cause	Correction
Permissions are too open	~/.ssh ou privée en 755/644	chmod 700 ~/.ssh ; chmod 600 privée + config
Permission denied (publickey)	Mauvaise clé / user / authorized_keys	-i correct, IdentitiesOnly yes, ligne .pub sur le serveur
Too many authentication failures	Agent propose trop de clés	IdentitiesOnly yes + IdentityFile
Connexion OK puis lock-out après durcissement	PasswordAuthentication no trop tôt	Console / SSM de secours ; réactiver temporairement via console
Host key verification failed	IP réutilisée / autre machine	Vérifiez l’empreinte ; retirez l’ancienne ligne dans ~/.ssh/known_hosts après confirmation
RSA refusé / algo désactivé	Serveur moderne sans RSA	Régénérez en Ed25519
ssh-copy-id : connection refused	sshd down / mauvais port / SG	ss -tlnp | grep ssh ; SG/ufw ; console de secours
Agent vide après reboot WSL	Pas de relance auto	eval "$(ssh-agent -s)" puis ssh-add

Quiz (3 questions)

1. Différence clé privée / clé publique ?
– A. La privée va sur le serveur, la publique reste au client
– B. La privée reste au client ; la publique est dans authorized_keys sur le serveur
– C. Les deux sont identiques

2. Faut-il un mot de passe (passphrase) sur la clé ?
– A. Non, jamais — ça casse SSH
– B. Oui, recommandé : chiffre la privée au repos ; l’agent évite de la retaper sans cesse
– C. Uniquement avec RSA

3. À quoi sert ~/.ssh/config ?
– A. À stocker la clé privée du serveur
– B. À déclarer des alias Host, user, IdentityFile, options (ex. ProxyJump)
– C. À remplacer sshd_config

Réponses : 1‑B · 2‑B · 3‑B

FAQ

Différence clé privée et publique ?
La privée reste au client (jamais Git / ticket / capture). La publique = une ligne dans authorized_keys. Base d’une bonne pratique ssh clé.

Faut-il un mot de passe sur la clé ?
Oui : la passphrase chiffre la privée. Sans elle, vol de laptop = accès aux hôtes. ssh-agent / ssh-add : une saisie par session.

À quoi sert ~/.ssh/config ?
Alias client (Host), HostName, User, IdentityFile, ProxyJump bastion. chmod 600 recommandé.

Comment révoquer une clé perdue ?
Sur chaque serveur : éditez ~/.ssh/authorized_keys (ou le chemin AuthorizedKeysFile) et supprimez la ligne publique concernée. Côté client : retirez la privée locale et ssh-add -d. Pas besoin de régénérer les autres clés si chaque machine/humain a sa propre paire.

Pour aller plus loin

• man ssh, ssh-keygen, ssh_config, sshd_config
• Bonus : ufw + fail2ban
• Cloud : EC2 + SSM · Démarrer avec AWS
• IaC : éviter remote-exec opaque (Terraform overview)

Maillage série Linux Basics (P5)

← Précédent	Écrire vos premiers scripts bash : variables, tests et boucles
→ Suivant	Édition vim / nano sous Linux · bonus ufw + fail2ban
Hub	Linux Basics
Aussi	EC2 + SSM · Démarrer avec AWS · Terraform overview

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : SSH Linux : clés ssh-keygen, agent et ~/.ssh/config (2026)
• Meta description (≤ 155) : Générez une paire de clés, copiez la clé publique, configurez l’agent et ~/.ssh/config. Base sécurisée pour AWS EC2 et labs.
• Focus keyphrase : ssh clé
• KW secondaires : ssh-keygen, ssh-copy-id, ssh-agent, ssh config, connexion ssh linux
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-ssh-cles-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Débutant
• Slug : linux-ssh-cles