Accès SSH par clé et durcissement
Une clé utilisateur prouve l’identité de la personne qui se connecte : sa partie privée reste dans WSL2 et sa partie publique est ajoutée à ~/.ssh/authorized_keys sur le VPS. Une clé d’hôte prouve quel serveur a répondu : sa partie privée reste sous /etc/ssh, tandis que le client enregistre 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 \
-o KbdInteractiveAuthentication=no \
"$VPS_USER@$VPS_PUBLIC_IPV4"
Ce test explicite doit réussir dans une deuxième session pendant que la session d’origine reste ouverte. ssh-copy-id ajoute les clés sans remplacer celles qui existent déjà. Vérifiez les permissions distantes :
stat -c '%a %U:%G %n' ~/.ssh ~/.ssh/authorized_keys
# directory 700, file 600
Ubuntu lit les fichiers /etc/ssh/sshd_config.d/*.conf. Pour la plupart des directives, OpenSSH conserve la première valeur obtenue ; un fichier tardif nommé 99-...conf ne remplace donc pas forcément un fragment cloud-init chargé plus tôt. Examinez les inclusions et les valeurs effectives avant de choisir le nom du fichier.
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication et KbdInteractiveAuthentication contrôlent des méthodes distinctes ; sous Ubuntu, l’authentification interactive via PAM peut encore demander le mot de passe du compte. AuthenticationMethods publickey exige explicitement une clé publique. Cette configuration vise un accès par clé seule : ne l’appliquez pas telle quelle si la politique exige aussi une étape MFA interactive.
sudo sshd -t
sudo sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods) '
Les valeurs attendues sont permitrootlogin no, passwordauthentication no, kbdinteractiveauthentication no, pubkeyauthentication yes et authenticationmethods publickey. En présence de blocs Match, examinez aussi la politique effective de la connexion réelle avec sudo sshd -T -C user=<login>,addr=<client-ip>,host=<client-hostname> en remplaçant les paramètres. Le seul affichage global ne vérifie pas une règle conditionnelle.
Une fois ces contrôles réussis, exécutez sudo systemctl reload ssh, puis ouvrez une troisième session neuve par clé publique seule. Ne supprimez ni utilisateur ni clé existante.
Face à une demande inconnue concernant la clé d’hôte, comparez l’empreinte par un chemin déjà fiable :
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
N’acceptez que si les empreintes correspondent exactement. En cas d’échec, gardez la session fonctionnelle ouverte et consultez sshd -t, sshd -T, journalctl -fu ssh.service et la sortie de ssh -vvv, après avoir masqué les adresses et les noms.