Clés SSH : l’authentification sans mot de passe

L’authentification SSH par clé sépare deux éléments : la clé privée reste sur votre poste, tandis que la clé publique rejoint le compte. Générez une clé Ed25519 protégée par passphrase, vérifiez l’identité du serveur, testez une session, puis désactivez le mot de passe seulement avec un secours ouvert.

Deux clés, deux responsabilités

La clé privée ne doit jamais être copiée sur le serveur. Elle prouve votre identité et mérite les mêmes protections qu’un secret durable. Le fichier portant l’extension .pub est la clé publique : il peut être installé dans authorized_keys pour le compte distant visé.

Générer une clé Ed25519

Sur votre poste client, choisissez un nom qui indique l’usage plutôt que de remplacer aveuglément une clé existante :

ssh-keygen -t ed25519 -a 64 -C "admin@poste-2026" \
  -f ~/.ssh/id_ed25519_hostscout_admin

Saisissez une passphrase longue dans l’invite ; ne la passez pas en argument de commande. Le paramètre -a augmente le travail de dérivation appliqué au fichier de clé privée. Ed25519 constitue un choix moderne compact avec les versions actuelles d’OpenSSH.

Contrôlez les fichiers sans afficher la clé privée :

ls -l ~/.ssh/id_ed25519_hostscout_admin*
ssh-keygen -lf ~/.ssh/id_ed25519_hostscout_admin.pub

Une passphrase protège le fichier volé, pas une session déjà déverrouillée. Verrouillez votre poste et maîtrisez la durée de vie de l’agent.

Vérifier la clé d’hôte avant la première connexion

Le message de première connexion ne prouve rien si vous acceptez l’empreinte sans comparaison. Obtenez l’empreinte de la clé d’hôte par un canal indépendant : console fournisseur, inventaire signé ou administrateur déjà connecté.

Sur le serveur, une personne disposant d’un canal fiable peut afficher :

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Comparez cette empreinte à celle proposée par le client. La clé utilisateur authentifie le client ; la clé d’hôte authentifie le serveur. Ce sont deux contrôles différents.

Installer la clé publique avec ssh-copy-id

Tant que l’accès par mot de passe fonctionne, installez explicitement le bon fichier public :

ssh-copy-id -i ~/.ssh/id_ed25519_hostscout_admin.pub admin@server.example

ssh-copy-id ouvre une connexion, détecte les clés déjà présentes puis ajoute celles qui manquent. Il ne doit recevoir que le chemin .pub.

Testez aussitôt en nommant la clé privée :

ssh -i ~/.ssh/id_ed25519_hostscout_admin admin@server.example

Installation manuelle et permissions

Si ssh-copy-id n’est pas disponible, créez le répertoire avec le compte distant puis ajoutez une seule ligne publique :

install -d -m 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Transférez le contenu du fichier .pub par un canal contrôlé et ajoutez-le sans écraser les autres clés. Le propriétaire doit être le compte cible. Avec StrictModes, sshd refuse normalement un home, un répertoire .ssh ou un fichier authorized_keys modifiable par d’autres utilisateurs.

chown -R "$(id -un):$(id -gn)" ~/.ssh
chmod go-w ~

Utiliser une passphrase avec ssh-agent

ssh-agent garde une identité déverrouillée en mémoire pour éviter de saisir la passphrase à chaque connexion. Chargez la clé pour une durée bornée :

eval "$(ssh-agent -s)"
ssh-add -t 1h ~/.ssh/id_ed25519_hostscout_admin
ssh-add -l

Sur un poste partagé, une durée courte et la commande ssh-add -D en fin d’intervention réduisent l’exposition. Ne transférez pas l’agent vers une machine que vous ne contrôlez pas. Agent forwarding élargit la frontière de confiance.

Tester avant de désactiver le mot de passe

Voici la séquence qui évite le verrouillage :

1. Gardez la session SSH actuelle ouverte.
2. Ouvrez un second terminal et connectez-vous avec la clé explicite.
3. Vérifiez sudo ou le mécanisme d’élévation nécessaire.
4. Confirmez un accès console ou rescue indépendant.
5. Sauvegardez la configuration sshd et préparez le rollback.

Vérifiez ensuite la syntaxe et la configuration effective avant tout reload :

sudo sshd -t
sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication'

Ne fermez jamais la session de secours pendant ce changement. Un test dans la même session ne valide pas une nouvelle authentification.

Désactiver le mot de passe avec rollback

Ajoutez un fichier de configuration dédié si votre distribution charge sshd_config.d :

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Validez puis rechargez sans redémarrage brutal :

sudo sshd -t
sudo systemctl reload ssh

Dans un troisième terminal, testez une connexion sans réutiliser une session existante. Vérifiez ensuite la valeur effective avec sshd -T. Selon la distribution, le nom du service peut être sshd plutôt que ssh ; utilisez celui réellement présent, sans mélanger les commandes.

Si le nouveau test échoue, restez dans la session de secours, restaurez le fichier précédent, relancez sshd -t puis rechargez le service. Si la session est perdue, utilisez la console ou le mode rescue préparé avant l’opération.

Révoquer et renouveler une clé

Supprimez uniquement la ligne publique concernée dans authorized_keys, puis testez qu’elle ne permet plus une nouvelle connexion. Une session déjà établie peut rester ouverte. Les commentaires et empreintes facilitent l’inventaire : personne, poste, usage, date de rotation et ticket de révocation.

Pour un nouveau poste, créez une nouvelle paire au lieu de copier la clé privée existante. Cela permet de révoquer un appareil sans interrompre les autres.

Pour administrer un VPS, conservez aussi un accès console indépendant et documentez qui peut réinitialiser les clés d’hôte après reconstruction.

À conserver dans la fiche d’exploitation :

• empreinte de la clé publique et propriétaire ;
• empreinte de la clé d’hôte vérifiée ;
• comptes et serveurs autorisés ;
• procédure de révocation et accès console de secours.