Configurer le serveur OpenSSH (sshd) pour LFCS/RHCSA

Le client SSH ne suffit pas pour une préparation certif crédible. Les objectifs LFCS demandent explicitement de configurer le serveur et le client OpenSSH. Ce guide couvre la partie serveur : modifier sshd_config, valider la configuration avant redémarrage, et appliquer un durcissement minimal sans se verrouiller hors du serveur.

Ce que vous allez apprendre

• Localiser et modifier la configuration de sshd
• Activer l'authentification par clé et réduire l'usage du mot de passe
• Empêcher la connexion root directe via SSH
• Vérifier la syntaxe avec sshd -t avant reload
• Contrôler la configuration effective avec sshd -T
• Diagnostiquer les erreurs de service SSH avec systemctl et journalctl

Dans quel contexte ?

Vous configurez sshd dans des situations réelles très fréquentes :

• durcir un nouveau serveur avant mise en production ;
• migrer d'un accès mot de passe vers clé publique ;
• interdire le compte root en connexion distante ;
• ouvrir un port SSH dédié dans un environnement filtré ;
• corriger un incident "SSH refused" après changement de config.

Alignement certification

Ce guide couvre l'objectif LFCS "Configure OpenSSH server and client" et reste utile en RHCSA pour l'authentification SSH par clé et le durcissement de base.

Prérequis

• un accès console local ou KVM/IPMI en cas d'erreur ;
• un utilisateur sudo non-root ;
• une clé SSH déjà en place côté client.

Risque de lockout

Ne redémarrez jamais sshd sans validation préalable. Utilisez toujours sshd -t avant systemctl reload.

Base de configuration sshd

Le fichier principal est /etc/ssh/sshd_config. Les directives d'un socle de durcissement, à leur première apparition :

• PasswordAuthentication no : refuse les mots de passe, n'accepte que les clés.
• PubkeyAuthentication yes : active l'authentification par clé publique.
• PermitRootLogin no : interdit la connexion directe du compte root.

Exemple minimal, sans changement de port pour l'instant :

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Le changement de port est traité à part, plus bas, car il réserve deux pièges qui coupent l'accès au serveur : sur RHEL à cause de SELinux, sur Ubuntu à cause de l'activation par socket. Ce n'est pas une directive « optionnelle » qu'on ajoute à la légère.

Validation avant application

Étape 1 : vérifier la syntaxe

sudo sshd -t

Si la commande ne retourne rien, la syntaxe est valide. Attention à ce que cette validation ne dit pas : sshd -t contrôle la grammaire du fichier, pas la capacité du service à démarrer. Un Port refusé par SELinux passe sshd -t sans erreur, puis fait échouer le redémarrage. La syntaxe correcte n'est pas la preuve d'un service qui démarre.

Étape 2 : vérifier la config effective

sudo sshd -T | grep -E '^(port|passwordauthentication|permitrootlogin|pubkeyauthentication) '

port 22
permitrootlogin no
pubkeyauthentication yes
passwordauthentication no

sshd -T affiche la configuration telle que sshd la comprend. Retenez ce piège, prouvé plus bas : sur Ubuntu avec activation par socket, sshd -T peut afficher port 2222 alors que le serveur écoute réellement sur le 22. Ce que sshd croit et ce que le système fait sont deux choses différentes.

Étape 3 : recharger le service

sudo systemctl reload sshd
sudo systemctl status sshd --no-pager

Un reload relit la configuration sans couper les connexions établies, ce qui est exactement ce qu'on veut pour ne pas se verrouiller dehors. Sur Debian et Ubuntu, le service s'appelle historiquement ssh ; les versions récentes acceptent l'alias sshd. Sous Debian 13 « Trixie », notez deux évolutions qui déroutent en audit : OpenSSH passe en 10.0p2, et les échecs d'authentification sont désormais journalisés par un processus nommé sshd-session, pas sshd.

Gardez toujours une session ouverte et une console de secours

Avant de recharger sshd, ouvrez une seconde session SSH que vous ne fermerez qu'après avoir vérifié que la nouvelle configuration fonctionne. Et sur une machine distante, assurez-vous d'avoir un accès console (KVM, IPMI, console du fournisseur cloud) : c'est votre seul recours si sshd refuse de redémarrer. Le lab de cette page a coupé l'accès SSH plus d'une fois ; sans console, la seule issue était de monter le disque depuis l'hôte.

Changer le port SSH : les deux pièges qui coupent l'accès

Déplacer sshd sur un autre port que le 22 est un réflexe de durcissement courant, et c'est un objectif RHCSA. Mais Port 2222 dans sshd_config ne suffit pas, et selon la distribution, l'appliquer naïvement rend le serveur injoignable. Les deux cas qui suivent ont été reproduits en VM, SELinux en enforcing d'un côté, activation par socket de l'autre.

Sur RHEL, Rocky et AlmaLinux : SELinux garde le port

SELinux n'autorise sshd à écouter que sur des ports étiquetés ssh_port_t, et par défaut cette liste ne contient que le 22. Ajouter Port 2222 et redémarrer produit exactement ceci, mesuré sur une AlmaLinux 10 en enforcing :

# sshd -t ne voit AUCUN problème
sudo sshd -t          # (silencieux)

# mais le redémarrage échoue
sudo systemctl restart sshd

Job for sshd.service failed because the control process exited with error code.

Le journal donne la vraie raison, que sshd -t avait tue :

sudo journalctl -u sshd -n 20 --no-pager | grep -i bind

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.
fatal: Cannot bind any address.

Le serveur SSH est mort, et plus rien n'écoute. Permission denied sur un bind, alors que la commande tourne en root, est la signature d'un refus SELinux, pas d'un problème de permissions Unix.

La correction consiste à déclarer le port à SELinux avant de toucher à sshd :

1. Ajouter le port au type ssh_port_t. Sur une installation minimale, semanage n'est pas là : il vient du paquet policycoreutils-python-utils.

   sudo dnf install -y policycoreutils-python-utils
   sudo semanage port -a -t ssh_port_t -p tcp 2222

2. Vérifier que SELinux connaît désormais le port.

   sudo semanage port -l | grep '^ssh_port_t'

   ssh_port_t                     tcp      2222, 22

3. Seulement maintenant, changer le port et redémarrer.

   echo 'Port 2222' | sudo tee -a /etc/ssh/sshd_config
   sudo sshd -t && sudo systemctl restart sshd
   ss -tlnp | grep :2222

4. Ouvrir le port dans le pare-feu, sans quoi il écoute mais reste injoignable de l'extérieur.

   sudo firewall-cmd --permanent --add-port=2222/tcp
   sudo firewall-cmd --reload

N'éditez jamais sshd_config depuis un disque monté à froid

Réparer un serveur en montant son disque depuis l'hôte et en éditant sshd_config avec sed détruit le contexte SELinux du fichier, qui repasse à un type inconnu. Au redémarrage, sshd ne peut plus le lire et reste en échec. Si vous devez réparer hors ligne, déposez un fichier /.autorelabel à la racine du système avant de redémarrer : SELinux réétiquette alors tout le disque au boot suivant. Rencontré, et résolu ainsi, pendant l'écriture de cette page.

Sur Ubuntu 24.04 : le port de sshd_config est ignoré

Ici le piège est inverse : rien ne plante, mais le changement n'a aucun effet. Depuis Ubuntu 22.10, sshd est démarré par activation par socket : c'est une unité ssh.socket de systemd qui ouvre le port et passe la connexion à sshd. Le Port de sshd_config n'est alors jamais lu.

La preuve, mesurée sur une Ubuntu 24.04 après avoir ajouté Port 2222 et redémarré :

sudo sshd -T | grep '^port'      # ce que sshd croit
ss -tlnp | grep -E ':22 |:2222 ' # ce que le système fait

port 2222
LISTEN 0 4096 0.0.0.0:22 ... users:(("sshd",...),("systemd",pid=1,...))

sshd annonce le port 2222, mais c'est le 22 qui écoute, ouvert par systemd (pid=1). Un administrateur qui se fie à sshd -T, ferme le 22 dans son pare-feu et rouvre le 2222 se coupe l'accès sans qu'aucune commande n'ait signalé d'erreur.

Le vrai port se change donc sur le socket, pas dans sshd_config :

1. Surcharger ssh.socket avec systemctl edit.

   sudo systemctl edit ssh.socket

   [Socket]
   ListenStream=
   ListenStream=2222

   La première ligne vide efface la valeur héritée (sinon le service écouterait sur les deux ports), la seconde fixe le nouveau port.

2. Recharger et redémarrer le socket, puis vérifier.

   sudo systemctl daemon-reload
   sudo systemctl restart ssh.socket
   ss -tlnp | grep :2222

Désactiver l'activation par socket, l'autre option

Si vous préférez le modèle classique où sshd gère lui-même son port, désactivez le socket et repassez au service : sudo systemctl disable --now ssh.socket puis sudo systemctl enable --now ssh. Le Port de sshd_config redevient alors la source de vérité, comme sur les versions antérieures et sur RHEL.

Tester une configuration sans toucher au service en place

Vous pouvez valider une configuration sshd dans un fichier séparé, sans jamais redémarrer le service du système. C'est le moyen le plus sûr de s'exercer avant l'examen ou avant d'appliquer sur un vrai serveur.

mkdir -p /tmp/sshd-lab && cd /tmp/sshd-lab
ssh-keygen -t ed25519 -N '' -f ssh_host_ed25519_key
printf '%s\n' \
  'ListenAddress 127.0.0.1' \
  'HostKey /tmp/sshd-lab/ssh_host_ed25519_key' \
  'PidFile /tmp/sshd-lab/sshd.pid' \
  'PasswordAuthentication no' \
  'PermitRootLogin no' \
  'PubkeyAuthentication yes' \
  'AuthorizedKeysFile .ssh/authorized_keys' \
  'UsePAM no' > sshd_config.test
sshd -t -f /tmp/sshd-lab/sshd_config.test
sshd -T -f /tmp/sshd-lab/sshd_config.test | grep -E '^(passwordauthentication|permitrootlogin|pubkeyauthentication|usepam) '

usepam no
permitrootlogin no
pubkeyauthentication yes
passwordauthentication no

La directive Protocol n'existe plus

Beaucoup de vieux tutoriels ajoutent Protocol 2 à sshd_config. C'est inutile depuis OpenSSH 7.6 (2017) : le protocole SSH-1, vulnérable, a été purement supprimé du code. La directive est ignorée, elle n'a plus aucun effet, et sa présence trahit un guide daté.

Dépannage rapide

Symptôme	Cause probable	Correction
sshd -t OK mais restart échoue, Bind to port ... Permission denied	SELinux interdit le port (RHEL/Rocky/Alma)	semanage port -a -t ssh_port_t -p tcp <port> avant de redémarrer
Changement de port sans effet, sshd -T dit le bon port mais ss montre le 22	activation par socket (Ubuntu 24.04)	changer le port dans ssh.socket, pas dans sshd_config
Permission denied (publickey) alors que la clé est bonne	compte verrouillé (usermod -L) sur RHEL	déverrouiller, ou utiliser usermod --expiredate ; le comportement diffère de Debian
Connection refused	service arrêté ou port fermé	systemctl status sshd, vérifier le pare-feu et le port réellement ouvert avec ss -tlnp
sshd: bad configuration option	faute de frappe dans sshd_config	corriger puis relancer sshd -t
Déconnexion après changement, plus aucun accès	directive bloquante ou port coupé	reprendre par la console ; en dernier recours, monter le disque et poser /.autorelabel

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• sshd se configure dans /etc/ssh/sshd_config ; la base de durcissement est : clé publique, root interdit, mot de passe désactivé.
• sshd -t valide la syntaxe, pas le démarrage. Un port refusé par SELinux le passe sans broncher, puis le service refuse de démarrer.
• Changer de port n'est pas anodin. Sur RHEL, SELinux n'autorise que le 22 : il faut semanage port -a avant de redémarrer. Sur Ubuntu 24.04, c'est ssh.socket qui décide du port, pas sshd_config.
• sshd -T dit ce que sshd croit, pas ce que le système fait : sous activation par socket, les deux divergent. Vérifiez le port réel avec ss -tlnp.
• Ouvrez toujours le port dans le pare-feu (firewall-cmd sur RHEL) : SELinux et le service peuvent être bons, le pare-feu bloque quand même.
• Gardez une session ouverte et une console de secours. Un restart malheureux tue sshd sans filet ; sans console, il faut monter le disque depuis l'hôte.

Pour aller plus loin

• Retrouver l'accès SSH à un serveur : le jour où un durcissement vous verrouille dehors, dont le piège SELinux du port non standard.
• Compétences LFCS essentielles : Vérifier les objectifs officiels réseau et accès utilisateur couverts par ce guide.

×

📖 Voir la documentation →