Accès SSH par clé et durcissement

Distinguer les clés utilisateur et les clés d’hôte

• La clé utilisateur identifie la personne qui se connecte. La clé privée reste dans WSL2 ; ajoutez la clé publique au fichier ~/.ssh/authorized_keys du compte utilisateur sur le VPS.
• La clé d’hôte permet de vérifier que vous avez atteint le serveur attendu. Sa clé privée reste dans /etc/ssh/ sur le VPS ; le client conserve normalement la clé publique d’hôte dans ~/.ssh/known_hosts et affiche son empreinte pour vérification.

La clé privée n’a pas de suffixe .pub. Ne copiez jamais votre clé privée sur le VPS, un site web ou dans une conversation. Pour vérifier l’identité, affichez l’empreinte de la clé publique :

[LOCAL: WSL2]

test -f "$LOCAL_SSH_PUBLIC_KEY"
ssh-keygen -lf "$LOCAL_SSH_PUBLIC_KEY"

Installer la clé publique utilisateur

[LOCAL: WSL2]

ssh-copy-id -i "$LOCAL_SSH_PUBLIC_KEY" "$VPS_USER@$VPS_PUBLIC_IPV4"

ssh-copy-id ajoute la clé publique ; il ne doit pas remplacer le fichier authorized_keys existant. Les permissions distantes sont normalement les suivantes :

[REMOTE: VPS]

stat -c '%a %U:%G %n' ~/.ssh ~/.ssh/authorized_keys
# Valeurs attendues : répertoire 700, fichier 600

Tester explicitement l’accès par clé publique seule

Une connexion ssh ordinaire peut encore réussir grâce à un mot de passe. Excluez l’authentification par mot de passe avec des options explicites côté client :

[LOCAL: WSL2]

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 doit réussir dans une deuxième session neuve, pendant que la session d’origine, dont le fonctionnement est confirmé, reste ouverte.

Durcir sshd avec un fragment de configuration

Ubuntu prend en charge /etc/ssh/sshd_config.d/*.conf. Pour la plupart des directives, OpenSSH conserve la première valeur obtenue et lit les noms de fichiers correspondant au motif dans l’ordre lexicographique. Un fichier tardif nommé 99-...conf ne remplace donc pas forcément un réglage cloud-init chargé plus tôt. Vérifiez l’ordre réel des inclusions et les valeurs effectives :

[REMOTE: VPS]

grep -nE '^[[:space:]]*Include|^[[:space:]]*(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication|PubkeyAuthentication|AuthenticationMethods)' \
  /etc/ssh/sshd_config
sudo find /etc/ssh/sshd_config.d -maxdepth 1 -type f -print

Une fois cet ordre confirmé, créez un fragment dédié qui sera lu assez tôt, par exemple :

/etc/ssh/sshd_config.d/00-personal-infra.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

PasswordAuthentication et KbdInteractiveAuthentication contrôlent des méthodes d’authentification distinctes. Sous Ubuntu, l’authentification interactive au clavier via PAM peut encore demander le mot de passe du compte. AuthenticationMethods publickey exige explicitement une clé publique. Cette configuration vise un serveur accessible par clé seule ; elle ne peut pas être appliquée telle quelle si la politique existante exige aussi une étape MFA interactive au clavier. Ne supprimez ni utilisateur ni clé publique existante.

Vérifier, recharger, puis vérifier à nouveau

[REMOTE: VPS]

sudo sshd -t
sudo sshd -T | grep -E \
  '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods) '

Les valeurs effectives attendues sont :

permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
pubkeyauthentication yes
authenticationmethods publickey

La syntaxe n’est validée que si sshd -t ne produit aucune sortie et se termine avec le code 0. En présence de blocs Match, utilisez aussi sudo sshd -T -C user=<login>,addr=<client-ip>,host=<client-hostname> pour examiner la politique effective dans les conditions réelles de connexion, en remplaçant les valeurs de substitution. L’affichage global de la configuration ne remplace pas cette vérification conditionnelle.

Une fois ces contrôles réussis, lancez sudo systemctl reload ssh pour recharger la configuration ; il n’est pas nécessaire de redémarrer tout le VPS. Ouvrez ensuite une troisième session neuve par clé publique seule depuis WSL2.

Vérifier l’empreinte d’hôte à la première connexion

Face au message « authenticity can't be established », ne saisissez pas automatiquement yes. Lisez l’empreinte de la clé publique d’hôte du VPS par un accès déjà fiable :

[REMOTE: known-good session]

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

N’acceptez que si elle correspond exactement à celle qu’affiche le client. Une réinstallation du système peut légitimement changer la clé d’hôte ; un changement imprévu peut en revanche indiquer la réutilisation d’une adresse, une attaque de l’homme du milieu ou une connexion à la mauvaise machine.

Dépannage

[REMOTE: keep known-good session open]

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods) '
sudo journalctl -fu ssh.service

Côté client, ajoutez l’option -vvv à ssh (ssh -vvv) pour suivre la négociation. Les journaux peuvent contenir des noms d’utilisateurs, des adresses et des chemins ; masquez ces informations avant toute diffusion publique. Si une nouvelle connexion échoue, cessez de restreindre le pare-feu et gardez la session existante ouverte.

Mes lectures