Cours Ubuntu 26.04 / Configurer OpenSSH et vérifier l’authentification par clé

Pour configurer l’authentification SSH par clé sur Ubuntu, vérifiez le serveur et son identité, installez uniquement la clé publique du client, puis testez une nouvelle connexion et les droits d’administration. Restreignez les autres méthodes seulement après ces contrôles, en conservant l’ancienne session et la console pour récupérer l’accès.

Préparer le serveur, le client et le chemin réseau

Secure Shell, ou SSH, chiffre une connexion distante et authentifie le serveur et l’utilisateur. Le serveur Ubuntu du laboratoire est 192.168.56.20, le client Linux 192.168.56.10 sur le réseau privé configuré avec Netplan. Les deux conservent leur interface NAT. Ce parcours garde le port SSH existant ; les commandes de connexion ci-dessous supposent le port 22 déjà constaté.

Sur le serveur, vérifiez les paquets et le point d’écoute. Si openssh-server manque, installez-le après lecture des résultats APT :

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
ip -br address

Une erreur de mise à jour des index doit être résolue avant la suite. L’installation peut démarrer un service d’écoute : faites cet exercice sur la VM prévue, avec l’accès réseau voulu. Comparez adresse, port et processus ; l’état d’une seule unité ne décrit pas tout le chemin d’activation.

Ubuntu peut utiliser l’activation SSH par socket systemd : le socket écoute et peut déclencher le service. Ne démarrez pas un second démon pour corriger une unité inactive. Vérifiez les unités et le véritable port en écoute.

Sur le client Linux, vérifiez command -v ssh et command -v ssh-copy-id. Si nécessaire, préparez openssh-client avec sudo apt update puis sudo apt install openssh-client. Remplacez labuser dans les exemples par le compte ordinaire réellement créé sur le serveur. Une politique existante doit autoriser l’enregistrement initial de la clé, ou un administrateur doit la placer par la console ; ne réactivez pas arbitrairement les mots de passe d’un serveur de production.

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

La clé d’hôte identifie le serveur. Elle est distincte de la clé personnelle du client. Depuis la console de confiance du serveur, lisez l’empreinte de sa clé publique Ed25519 existante :

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

Comparez l’algorithme et l’empreinte SHA256 avec ceux présentés au client lors de sa première connexion. Si le serveur utilise un autre type de clé, comparez la clé réellement présentée par une source de confiance. Une clé absente ou une empreinte différente demande une investigation, pas la génération aveugle d’une nouvelle identité.

Ne contournez pas cette vérification avec StrictHostKeyChecking=no. Après une réinstallation ou un changement de VM, une nouvelle clé peut être légitime, mais confirmez-en la cause et l’identité avant de modifier l’entrée connue. Une alerte de clé d’hôte ne concerne pas le mot de passe du compte.

Créer une clé sur le client et ne copier que sa partie publique

Dans le terminal du client Linux, choisissez un nom de fichier de clé libre. Vérifiez que ni le fichier ni sa version .pub n’existent déjà ; si l’outil propose un écrasement, refusez et choisissez un autre nom. Le manuel ssh-keygen décrit la création et les empreintes.

if [ ! -d "$HOME/.ssh" ]; then
    mkdir -m 700 "$HOME/.ssh"
fi
ssh-keygen -t ed25519 -f "$HOME/.ssh/ubuntu-lab-ed25519"

Définissez une phrase secrète pour protéger la clé privée, et conservez-la de manière sûre. Le fichier sans suffixe contient la clé privée ; le fichier .pub est sa partie publique. Les commandes suivantes désignent ce même nom : si vous en choisissez un autre, adaptez tous les chemins.

Copiez la clé publique depuis le client vers le compte cible :

ssh-copy-id -i "$HOME/.ssh/ubuntu-lab-ed25519.pub" labuser@192.168.56.20

Vérifiez l’identité du serveur avant d’accepter sa première connexion, puis utilisez le moyen d’authentification initial autorisé. ssh-copy-id ajoute la clé à authorized_keys du compte distant ; l’option -i évite de choisir par défaut une autre clé présente dans le client ou son agent. Ne copiez jamais la clé privée sur le serveur.

Windows peut fournir ssh sans ssh-copy-id ; cet exemple de copie vise donc le client Linux préparé. Si une politique cryptographique impose d’autres algorithmes ou plusieurs facteurs, suivez cette politique plutôt que de la désactiver pour reproduire Ed25519.

Valider une authentification nouvelle par cette clé

Gardez l’ancienne session ouverte et utilisez un nouveau terminal sur le client :

ssh -F /dev/null -i "$HOME/.ssh/ubuntu-lab-ed25519" \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  -o ControlMaster=no -o ControlPath=none \
  labuser@192.168.56.20

Pour ce chemin direct de laboratoire, -F /dev/null écarte les profils de configuration habituels afin qu’une autre IdentityFile ne masque pas le résultat ; il ne désactive pas le contrôle de la clé d’hôte. IdentitiesOnly limite les identités proposées à celles configurées, et la préférence publickey cible ici l’authentification par clé. ControlPath=none évite de réutiliser silencieusement une ancienne connexion partagée. Le manuel de configuration du client SSH précise le partage de connexion et les options d’identité.

Une demande de phrase secrète pour le fichier privé se produit sur le client ; elle n’est pas le mot de passe du compte serveur. Pour un laboratoire simple, la connexion doit aboutir au compte prévu. Une politique existante à plusieurs facteurs peut exiger une étape supplémentaire ; le test publickey seul ne doit pas servir à la contourner.

Dans la nouvelle session distante, vérifiez l’identité et l’administration attendues :

whoami
sudo -v

whoami doit retourner le compte cible ; sudo -v valide les autorisations d’authentification sudo sans exécuter une tâche d’administration supplémentaire. Le mot de passe éventuellement demandé par sudo est encore distinct de la phrase secrète de la clé. Un compte sans sudo peut être volontaire : ne lui accordez pas ce droit uniquement pour faire réussir l’exercice.

En cas d’échec, vérifiez utilisateur, adresse, chemin de clé et propriétaire et permissions du dossier personnel, de .ssh et d’authorized_keys. Le compte doit contrôler ses clés sans rendre ces fichiers modifiables par d’autres. Un mode 777 ne répare pas une authentification SSH. Consultez aussi sudo journalctl -u ssh.service --since today --no-pager et les journaux d’authentification réellement présents.

Sauvegarder puis limiter la politique du seul laboratoire prévu

La politique ci-dessous vise une nouvelle VM de laboratoire destinée à l’authentification par une clé, après le succès du test précédent et de l’accès console. Elle remplace les méthodes permises pour les connexions concernées : ne l’appliquez pas telle quelle à un serveur avec authentification multifacteur, comptes de service ou règles d’organisation.

(
set -eu
ssh_backup=$(sudo mktemp -d /root/ssh-auth-backup.XXXXXX)
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.d "$ssh_backup/"
printf 'Sauvegarde : %s\n' "$ssh_backup"
)

Notez le chemin de sauvegarde après réussite, ainsi que les valeurs effectives avant changement. Inspectez /etc/ssh/sshd_config et les fichiers inclus. Avec sudoedit, créez /etc/ssh/sshd_config.d/00-lab-auth.conf seulement si ce nom est libre ; si le fichier existe, examinez-le et préservez ses réglages au lieu de l’écraser :

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
PermitRootLogin no

AuthenticationMethods publickey exige cette méthode pour les connexions auxquelles la règle s’applique. PasswordAuthentication no interdit la méthode password ; ce réglage seul ne décrit pas toute la politique interactive. PermitRootLogin no empêche la connexion directe du compte root : utilisez le compte ordinaire autorisé.

Le manuel sshd_config d’Ubuntu indique que la première valeur lue est retenue pour de nombreuses directives et que les fichiers inclus peuvent précéder le fichier principal. Le préfixe 00 ne dispense pas de vérifier la position des Include, les autres fichiers et les blocs Match.

Contrôler syntaxe et paramètres effectifs pour le bon client

Sur le serveur, utilisez le chemin complet de sshd pour ne pas dépendre du PATH du compte :

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|permitrootlogin) '

Une validation réussie par -t se termine normalement sans message ; en cas d’erreur, corrigez-la avant tout rechargement. -T affiche les valeurs effectives, mais une consultation globale ne couvre pas automatiquement toutes les conditions Match.

Pour le compte et le chemin réseau de cet exemple, contrôlez aussi les conditions de connexion. Adaptez le compte, les adresses et le port aux valeurs réelles :

sudo /usr/sbin/sshd -T \
  -C user=labuser,addr=192.168.56.10,laddr=192.168.56.20,lport=22 \
  | grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|permitrootlogin) '

La documentation de sshd et de l’option -C distingue addr, l’adresse source du client, de laddr, l’adresse locale du serveur. Si des règles Match Host interviennent, renseignez aussi host avec le nom source effectivement résolu ; ne lui donnez pas arbitrairement le nom du serveur. Examinez chaque profil d’accès utile, sans généraliser le résultat d’un seul compte.

Recharger, retester et conserver une voie de récupération

Après syntaxe correcte et paramètres attendus, si ssh.service est réellement en cours d’exécution, rechargez ses paramètres d’authentification :

sudo systemctl reload ssh.service

Si le service n’est pas actif alors qu’un socket gère l’accès, analysez l’état et le fonctionnement attendu avant une action supplémentaire. Ce parcours ne modifie ni Port ni ListenAddress ; une modification des points d’écoute sous activation par socket demande une procédure distincte sur les unités générées et leur rechargement.

Avant de fermer l’ancienne session, répétez la connexion par clé avec le partage désactivé, l’identité du compte et la validation sudo nécessaire. Contrôlez que les méthodes non autorisées ne sont pas offertes pour les conditions testées. Une tentative qui échoue seulement parce qu’elle ne propose aucun mot de passe ne démontre pas à elle seule que le serveur refuse la méthode password : rapprochez les diagnostics clients des paramètres effectifs du serveur.

Planifiez ensuite un redémarrage et répétez les mêmes contrôles. Si l’accès est perdu, utilisez la console, restaurez uniquement le fichier ou les directives de cette intervention à partir de la sauvegarde, puis validez et rechargez. Ne remplacez pas l’ensemble des clés d’hôte ou d’authorized_keys pour annuler un changement d’authentification. Le guide OpenSSH d’Ubuntu rassemble l’installation et les précautions de validation des réglages.