Configurer les clés SSH

Une clé SSH remplace un mot de passe par une paire cryptographique : la clé privée reste sur votre machine, la clé publique sur le serveur. Une fuite du serveur ne révèle alors pas votre secret de connexion. La mise en place est simple, mais la dernière étape, désactiver le mot de passe, est celle qui verrouille les imprudents.

Générer une paire de clés

ssh-keygen -t ed25519 -a 100 -C "utilisateur@poste"

ed25519 produit une clé courte et robuste. -a 100 augmente le coût de dérivation de la phrase secrète ; -C ajoute un commentaire pour retrouver la clé. Acceptez le chemin par défaut ~/.ssh/id_ed25519 ou choisissez un nom explicite.

Protégez la clé privée par une phrase secrète. Elle ne quitte jamais votre poste : ne la copiez pas sur le serveur, ne la mettez pas dans un dépôt Git. La clé publique, elle, se termine par .pub et peut être diffusée.

Installer la clé publique

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@VOTRE_IPV6

La commande ajoute la clé à ~/.ssh/authorized_keys du compte distant et crée les dossiers avec les bons droits. Si ssh-copy-id n'est pas disponible, ajoutez la ligne manuellement :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Vérifier les permissions et tester

SSH refuse une clé si les droits sont trop larges. Sur le serveur :

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Le répertoire personnel ne doit pas être accessible en écriture au groupe ni aux autres, ~/.ssh doit être en 700 et authorized_keys en 600. Corrigez avec chmod, jamais avec chmod 777. Vérifiez aussi que le chemin dans AuthorizedKeysFile correspond à l'emplacement réel.

Gardez ensuite la session SSH ouverte et ouvrez une seconde fenêtre :

ssh -i ~/.ssh/id_ed25519 utilisateur@VOTRE_IPV6

L'authentification doit se faire par clé. Pour le confirmer, lancez ssh -v : la négociation doit mentionner publickey et non password. Si la clé ne fonctionne pas, ne modifiez pas sshd_config : corrigez d'abord les droits ou le chemin.

Désactiver le mot de passe

Dans /etc/ssh/sshd_config :

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Puis :

sudo sshd -t
sudo systemctl reload ssh

sshd -t valide la syntaxe. Le rechargement conserve les sessions actives. Testez immédiatement une nouvelle connexion ; si elle échoue, la session ouverte permet de revenir en arrière en remettant PasswordAuthentication yes.

Garder une solution de secours

• Conservez une deuxième clé ou un accès par console.
• Sauvegardez ~/.ssh hors du serveur.
• Utilisez ssh-agent pour éviter de retaper la phrase secrète.
• Révoquez une clé en supprimant sa ligne dans authorized_keys.

Une clé sans phrase secrète sur un poste partagé est un risque. Une clé avec phrase secrète et un agent correctement configuré offre le meilleur compromis. Pour un accès très sensible, une clé matérielle FIDO2 (ed25519-sk) ajoute une vérification physique.