Accès SSH par clé et durcissement
La clé utilisateur prouve qui se connecte : la partie privée reste dans WSL2, la partie publique est ajoutée à ~/.ssh/authorized_keys. La clé d’hôte prouve quel serveur répond : sa partie privée reste sous /etc/ssh, le client mémorise son empreinte publique.
ssh-keygen -lf "$LOCAL_SSH_PUBLIC_KEY"
ssh-copy-id -i "$LOCAL_SSH_PUBLIC_KEY" "$VPS_USER@$VPS_PUBLIC_IPV4"
ssh -i "$HOME/.ssh/id_ed25519" \
-o IdentitiesOnly=yes \
-o PreferredAuthentications=publickey \
-o PasswordAuthentication=no \
"$VPS_USER@$VPS_PUBLIC_IPV4"
Ce test explicite doit réussir dans une deuxième session pendant que la première reste ouverte. Vérifiez les permissions : répertoire .ssh en 700, authorized_keys en 600.
Ubuntu charge /etc/ssh/sshd_config.d/*.conf. OpenSSH conserve généralement la première valeur obtenue : un fichier tardif 99-...conf peut donc perdre face à cloud-init. Inspectez l’ordre réel avant de choisir le nom.
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
sudo sshd -t
sudo sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo systemctl reload ssh
Attendez no, no, yes, puis ouvrez une troisième session neuve par clé. Ne supprimez ni utilisateur ni clé existante.
Face à une nouvelle empreinte d’hôte, comparez-la depuis un chemin déjà fiable avec sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. En cas d’échec, gardez la session fonctionnelle et examinez sshd -t, sshd -T, journalctl -fu ssh.service et, après anonymisation, ssh -vvv.