SSH : clés

L’authentification par clé remplace le mot de passe par une paire de clés : une clé privée (secrète, qui ne quitte jamais le poste) et une clé publique (déposée sur les serveurs). Les exemples utilisent des noms génériques.

Générer une clé

À faire sur le poste local :

ssh-keygen -t ed25519 -a 100 -C "prenom@poste-de-travail"

Option	Rôle
`-t ed25519`	Algorithme moderne, rapide et sûr (recommandé)
`-a 100`	Nombre de tours de dérivation de la phrase secrète : ralentit les attaques par force brute
`-C "…"`	Commentaire (qui, quel poste)
`-f ~/.ssh/id_projet`	Nom de fichier personnalisé

La commande demande une phrase secrète : la saisir (elle chiffre la clé privée). Elle crée :

Fichier	Contenu
`~/.ssh/id_ed25519`	Clé privée : ne jamais la partager ni la copier hors du poste
`~/.ssh/id_ed25519.pub`	Clé publique : à déposer sur les serveurs

Pour des raisons de compatibilité avec de très vieux systèmes uniquement : ssh-keygen -t rsa -b 4096. Les clés DSA ne sont plus prises en charge (voir Installation).

Déposer la clé publique sur le serveur

ssh-copy-id deploy@serveur.exemple.com
ssh-copy-id -i ~/.ssh/id_projet.pub -p 2222 deploy@serveur.exemple.com

La commande demande le mot de passe une dernière fois, puis ajoute la clé à ~/.ssh/authorized_keys du serveur. Vérifier :

ssh deploy@serveur.exemple.com               # ne demande plus que la phrase secrète de la clé

Sans ssh-copy-id (copie manuelle) :

cat ~/.ssh/id_ed25519.pub | ssh deploy@serveur.exemple.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Droits des fichiers

SSH refuse les clés si les droits sont trop larges :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_ed25519 ~/.ssh/config
chmod 644 ~/.ssh/id_ed25519.pub ~/.ssh/known_hosts
chmod go-w ~                                  # le dossier personnel ne doit pas être modifiable par d'autres

Si le dossier personnel est modifiable par le groupe ou les autres (chmod 777 ~), le serveur journalise Authentication refused: bad ownership or modes for directory /home/deploy et refuse la clé (StrictModes).

Agent SSH : saisir la phrase secrète une fois

eval "$(ssh-agent -s)"                       # démarre l'agent (souvent déjà actif dans une session graphique)
ssh-add ~/.ssh/id_ed25519                    # charge la clé (phrase secrète demandée une fois)
ssh-add -l                                   # clés chargées
ssh-add -D                                   # décharge toutes les clés

Pour charger automatiquement la clé à la première utilisation, dans ~/.ssh/config :

Host *
    AddKeysToAgent yes

Empreintes et vérification

ssh-keygen -lf ~/.ssh/id_ed25519.pub                 # empreinte SHA256 de la clé
ssh-keygen -lf ~/.ssh/authorized_keys                # empreintes de toutes les clés autorisées
ssh-keygen -y -f ~/.ssh/id_ed25519 > /tmp/pub        # recalcule la clé publique depuis la privée
ssh-keygen -p -f ~/.ssh/id_ed25519                   # change la phrase secrète

Plusieurs clés

Une clé par usage limite l’impact d’une fuite :

ssh-keygen -t ed25519 -f ~/.ssh/id_travail -C "travail"
ssh-keygen -t ed25519 -f ~/.ssh/id_perso -C "perso"

Les associer aux serveurs dans ~/.ssh/config (voir Configuration du client).

Clés matérielles FIDO2 (clé de sécurité USB)

ssh-keygen -t ed25519-sk -C "cle-usb"             # nécessite une clé de sécurité FIDO2 branchée

La clé privée est liée au matériel : un geste (toucher la clé) est requis à chaque connexion. Le serveur accepte ces clés (sk-ssh-ed25519@openssh.com figure dans ssh -Q key).

Restreindre une clé : options de `authorized_keys`

Chaque ligne de ~/.ssh/authorized_keys peut commencer par des options :

restrict,from="203.0.113.10",command="/usr/local/bin/sauvegarde.sh" ssh-ed25519 AAAAC3Nza… sauvegarde@poste

Option	Effet
`restrict`	Désactive les redirections, le terminal et autres fonctions (puis on réactive au besoin : `restrict,pty`)
`from="adresse"`	N’accepte la clé que depuis cette adresse ou ce réseau
`command="…"`	Exécute uniquement cette commande, quelle que soit celle demandée
`no-agent-forwarding`, `no-port-forwarding`, `no-pty`	Interdictions précises

Utile pour une clé dédiée à un script (sauvegarde, déploiement) : même volée, elle ne permet pas d’ouvrir un shell.

Retirer une clé

Sur le serveur, supprimer la ligne correspondante de ~/.ssh/authorized_keys :

ssh-keygen -lf ~/.ssh/authorized_keys           # repérer la clé par son empreinte
nano ~/.ssh/authorized_keys                      # supprimer la ligne

Si un poste est perdu ou volé, retirer sa clé publique de tous les serveurs.

Renouveler une clé

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_neuve
ssh-copy-id -i ~/.ssh/id_ed25519_neuve.pub deploy@serveur.exemple.com
# tester la connexion avec la nouvelle clé, puis retirer l'ancienne du serveur

Bonnes pratiques

Toujours une phrase secrète sur la clé privée.
Une clé par poste (jamais copiée d’un poste à l’autre).
Clé privée jamais envoyée par e-mail, messagerie ou stockage partagé.
Sauvegarder la clé privée chiffrée si nécessaire, et retirer les clés inutilisées.
Ne pas laisser de clé privée sur un serveur : utiliser ssh -J ou l’agent (ssh -A à éviter hors usage maîtrisé).

Dépannage

Symptôme	Piste
`Permission denied (publickey)`	Clé absente de `authorized_keys`, droits trop larges (voir plus haut), mauvaise clé ou mauvais utilisateur : `ssh -v`
`Too many authentication failures`	L’agent propose trop de clés : `IdentitiesOnly yes` et `IdentityFile` dans `~/.ssh/config`
`Load key … invalid format`	Fichier de clé corrompu ou mauvaise clé
`WARNING: UNPROTECTED PRIVATE KEY FILE!`	Droits de la clé privée : `chmod 600 ~/.ssh/id_ed25519`
La phrase secrète est redemandée à chaque fois	Charger la clé dans l’agent (`ssh-add`)

Pour aller plus loin

Manuel : man ssh-keygen, man sshd (section AUTHORIZED_KEYS FILE FORMAT)
Suite : Configuration du client