Renforcement de la sécurité SSH et gestion des clés : serveurs bastion, autorités de certification et rotation des clés

Dans de nombreux environnements, SSH reste l’accès opérationnel principal pour Linux-serveurs, hôtes virtuels, passerelles réseau et aussi pour les hôtes Docker. C’est précisément pourquoi le durcissement SSH n’est pas une tâche « définir une fois et oublier », mais une interaction entre durcissement du protocole, chemins d’accès, identités (clés/certificats) et un cycle de vie robuste pour le matériel de clés. Qui ne règle que quelques éléments (p. ex. « désactivation de la connexion root »), mais tolère la prolifération de clés, l’absence de rotation ou des chemins de saut non contrôlés, ne fait que déplacer les risques.

Cet article présente une architecture cible opérationnelle avec Bastion-Host (Jump Host comme point d’entrée central), SSH Certificate Authority (CA pour la signature de certificats SSH de courte durée) et Key-Rotation en tant que processus opérationnel planifié. L’accent est mis sur l’exploitation, l’administration, l’auditabilité, le dépannage, les écueils typiques et une stratégie de repli que vous n’aurez pas à improviser en cas d’incident.

Pourquoi le durcissement SSH échoue souvent sans gestion des clés

SSH lui-même est cryptographiquement robuste, mais la pratique échoue généralement à trois niveaux :

• Chaos d’identités : clés personnelles de longue durée sans expiration, souvent copiées à multiples reprises, sans vue centrale.
• Chemins non contrôlés : accès directs depuis n’importe quel réseau vers des systèmes en production, souvent complétés par des exceptions VPN ou des ouvertures temporaires de pare-feu.
• Faible discipline opérationnelle : pas de rotation, impossible de révoquer en quelques minutes, pas de modifications traçables de authorized_keys.

La conséquence est une élévation progressive des privilèges, des processus d’offboarding compliqués, un MTTR élevé en cas d’incident (car il est incertain quelle clé fonctionne encore) et des lacunes par rapport aux exigences de conformité et d’audit.

Vision cible : Bastion-Host, SSH-CA et accès éphémères

Une vision cible opérationnelle n’est pas un « Big Bang », mais peut être introduite de manière incrémentale :

• Bastion-Host : point d’entrée durci et étroitement surveillé par lequel transitent les connexions SSH vers les segments internes. Le Bastion-Host réduit la surface d’attaque, centralise les logs et simplifie les règles réseau.
• Certificats SSH (OpenSSH Certificates) : au lieu de distribuer des clés publiques sur chaque système cible, des certificats utilisateur de courte durée sont signés par une SSH Certificate Authority. Le système cible fait confiance à la CA et décide des droits d’accès via les attributs du certificat et les politiques locales.
• Key-Rotation : les clés d’hôte, les clés de CA et (là où c’est encore nécessaire) les clés utilisateur sont renouvelées selon des règles définies. La rotation est un processus opérationnel avec points de mesure, pas seulement un sujet cryptographique.

Important : « Zero Trust » est souvent utilisé comme mot à la mode ; dans le contexte SSH, cela signifie concrètement que vous privilégiez l’identité, le contexte et la validité (durées courtes) plutôt que « qui est sur le réseau a déjà le droit ».

Durcissement de base d’OpenSSH : sshd_config, paramètres cryptographiques, surface d’attaque

La base reste le durcissement soigné du démon SSH (sshd). Objectif : seules les fonctions nécessaires, paramètres cryptographiques sûrs, voies d’authentification claires.

Principe minimal pour l’authentification et les fonctionnalités

De nombreux risques proviennent d’une configuration « compatible à tout prix ». Mesures typiques :

• Désactiver l’authentification par mot de passe (si possible d’un point de vue organisationnel) au profit des clés ou des certificats.
• Contrôler la connexion root (idéal : désactiver ; en alternative : uniquement via certificat et fortement restreint).

# Exemple : durcissement conservateur de sshd (adapter à vos politiques)
# Fichier: /etc/ssh/sshd_config

Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Autoriser uniquement de manière ciblée, si vous en avez vraiment besoin
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Réduire la surface d'attaque exposée
MaxAuthTries 4
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Contrôler l'accès par politique (exemple)
AllowGroups ssh-admins ssh-ops

# Journalisation : pour la traçabilité (sans inondation de logs)
LogLevel VERBOSE

Pourquoi cela fonctionne : Chaque méthode d’authentification désactivée équivaut à un vecteur d’attaque en moins (credential stuffing, mots de passe faibles, phishing). Des options de forwarding réduites empêchent que SSH soit utilisé comme « tunnel universel » pour les mouvements latéraux.

Quand cela échoue : Si vous avez en parallèle des automatisations anciennes (p. ex. sauvegardes/déploiements) qui nécessitent encore la connexion par mot de passe ou la redirection de ports. Donc : recenser les dépendances avant la désactivation et basculer à titre d’essai sur des hôtes pilotes.

Clés d’hôte : empreintes, algorithmes, remplacer le Trust On First Use planifié

Beaucoup d’équipes vivent avec le « Trust On First Use » (TOFU) : au premier contact SSH, la clé d’hôte est acceptée puis mise en cache. Dans de grands environnements, cela est risqué car un attaquant Man-in-the-Middle au premier contact est difficile à détecter. Mieux : certificats d’hôte via une SSH-CA ou au minimum une distribution gérée de known_hosts.

Si vous faites tourner les clés d’hôte ou migrez de RSA vers des valeurs par défaut plus modernes, planifiez la cascade : monitoring/automation, Bastion, gestion de configuration, postes de développeurs et clients break-glass.

Bastion-Host (Jump Host) : architecture, exploitation et écueils typiques

Un Bastion-Host est un serveur dédié dans un segment strictement contrôlé, qui sert de seul point d’entrée SSH dans un réseau interne. Il ne remplace pas le durcissement des systèmes cibles, mais il concentre les contrôles d’accès et la télémétrie.

Principes réseau et pare-feu

• Entrant uniquement depuis des réseaux admin définis (p. ex. VPN, Privileged Access Segment) vers le port 22 (ou un port alternatif fixe, mais sans le considérer comme de la « security by obscurity »).
• Sortant du Bastion-Host uniquement vers les sous-réseaux/ports cibles nécessaires (généralement 22). Pas de « le Bastion peut aller partout ».
• Aucune accessibilité directe des hôtes de production depuis le réseau utilisateur/bureau.

Piège fréquent : lorsque vous exploitez des hôtes Docker, ceux-ci se trouvent souvent dans des réseaux « plus ou moins accessibles », car les accès de build/registry se sont constitués historiquement. Séparez strictement les accès de gestion (SSH) des voies de données (Registry, APIs) et empêchez qu’un runner de build compromis puisse se connecter directement en SSH à la production.

Contrôle des sessions et traçabilité

Pour les audits, il ne suffit pas de savoir « qui était autorisé », il faut aussi savoir « qui a fait quoi et quand ». Approches classiques :

• SSH-LogLevel VERBOSE pour des informations exploitables sur les clés/certificats.
• Routage centralisé des logs (p. ex. via journald/rsyslog) vers un SIEM ou un backend de logs.
• Enregistrement de session (saisie clavier/sortie terminal) uniquement si les aspects juridiques et organisationnels sont clarifiés ; utile techniquement surtout pour les accès hautement privilégiés.

Important : le logging depuis la bastion ne remplace pas les logs locaux sur les systèmes cibles. En cas d’incident, vous aurez besoin des deux perspectives (ingress et événements côté hôte).

Étapes de vérification : valider l’hôte bastion au quotidien

# 1) Auf dem Bastion: eingehende SSH-Verbindungen prüfen (Linux)
ss -tnp | grep ':22 '

# 2) Journald: Authentifizierungsereignisse
journalctl -u ssh -S -2h --no-pager

# 3) Fail2ban/Rate-Limits (falls eingesetzt)
sudo fail2ban-client status sshd 2>/dev/null || true

Si vous constatez déjà « du bruit » (nombreux échecs provenant de réseaux inattendus), c’est un signal : les règles d’entrée et les contrôles en amont (VPN, MFA, Conditional Access) sont trop ouverts.

SSH Certificate Authority : la distribution de clés appartient au passé

OpenSSH prend en charge les certificats SSH : un utilisateur conserve une paire de clés, mais au lieu de déposer la clé publique sur chaque serveur dans authorized_keys, on émet un certificat. Ce certificat contient notamment l’identité (Principals), la période de validité (NotBefore/NotAfter) et éventuellement des restrictions. Le serveur fait confiance à la CA via une entrée TrustedUserCAKeys.

Avantages en exploitation

• Accès à courte durée de vie (p. ex. 8–24 heures) réduisent sensiblement le risque lié aux clés volées.
• L’offboarding devient immédiat : arrêter l’émission par la CA, ou réduire la durée des certificats. Plus besoin de modifier les « authorized_keys » sur 200 hôtes.
• Politique centralisée : les Principals peuvent refléter des rôles (p. ex. « ops », « db-admin »), au lieu de gérer des listes par hôte.
• Auditabilité : les numéros de série des certificats et les Principals apparaissent dans les logs.

Configuration de base sur les hôtes cibles

Sur les systèmes cibles, vous définissez la confiance envers la User-CA et mappez les Principals sur des droits locaux (typiquement via des groupes Unix et des règles sudo). Concept d’exemple :

• La clé publique de la CA est présente sous forme de fichier sur l’hôte.
• TrustedUserCAKeys y fait référence.
• AuthorizedPrincipalsFile ou AuthorizedPrincipalsCommand détermine quels Principals sont acceptés pour quel compte.

# Datei: /etc/ssh/sshd_config.d/10-ca.conf (Beispielpfad, distroabhängig)

# Vertrauen in die User-CA
TrustedUserCAKeys /etc/ssh/trusted-user-ca.pub

# Principals pro Ziel-User definieren
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# Zertifikate erzwingen (optional, abhängig von Ihrer Übergangsphase)
AuthenticationMethods publickey

# Principals-Dateien anlegen (Beispiel)
sudo install -d -m 0755 /etc/ssh/auth_principals

echo 'ops' | sudo tee /etc/ssh/auth_principals/admin >/dev/null
echo 'breakglass' | sudo tee /etc/ssh/auth_principals/emergency >/dev/null

sudo chmod 0644 /etc/ssh/auth_principals/*

# sshd neu laden
sudo systemctl reload sshd

Pourquoi cela fonctionne : L’hôte ne vérifie plus « la clé publique figure-t‑elle dans mon fichier », mais « ce certificat est‑il signé par ma CA et le Principal est‑il autorisé pour ce compte ». La CA devient ainsi la racine de confiance centrale.

Quand cela échoue : En cas de dérive temporelle. Les certificats ont des limites temporelles ; avec une heure système incorrecte, ils seront « pas encore valides » ou « expirés ». NTP/Chrony n’est donc pas optionnel. Vérifiez la stabilité temporelle en particulier après des snapshots/RESTaurations de VM.

Protéger la clé CA: c’est votre « Master Key »

La User-CA est hautement critique. Quiconque possède la clé privée de la CA peut signer des accès arbitraires. Exigences minimales :

• Hors ligne ou fortement isolée (idéalement pas sur l’hôte bastion lui‑même).
• Signature via un workflow contrôlé (p. ex. ticket/approbation, durées courtes, journalisation).
• Sauvegarde et récupération avec un contrôle d’accès clair.

Beaucoup d’équipes utilisent ici une PKI interne ou une plateforme de gestion de secrets. L’important n’est pas l’outil, mais que l’émission, la durée de validité et la révocation/arrêt soient opérationnalisés de manière rigoureuse.

Key-Rotation: Host-Keys, User-Keys, CA-Keys – und was dabei gerne bricht

La rotation des clés est le remplacement planifié des clés avant qu’elles ne soient compromises. Dans l’environnement SSH, il y a trois classes que vous devez considérer séparément :

• Host Keys: identité du serveur vis‑à‑vis des clients. La rotation concerne known_hosts, l’automatisation et le monitoring.
• User Keys / Zertifikate: identité des utilisateurs/automatisations vis‑à‑vis des serveurs. Avec les certificats SSH, vous faites principalement évoluer la politique de CA et la base de clés utilisateur moins fréquemment.
• CA Keys: racine de confiance. La rotation est possible, mais doit être planifiée comme une fenêtre de migration (faire confiance à plusieurs CAs en parallèle).

Rotation sans interruption: confiance parallèle et fenêtre de migration

Une approche pratique consiste en « autoriser en parallèle, puis couper » :

• Introduire une nouvelle CA et lui faire confiance en plus sur les hôtes cibles (TrustedUserCAKeys kann mehrere Keys enthalten, entweder in einer Datei oder über mehrere Dateien, je nach Aufbau).
• Les clients reçoivent de nouveaux certificats émis par la nouvelle CA.
• Après l’expiration des anciens certificats et la date butoir définie, retirer la confiance accordée à l’ancienne CA.

Pour les clés d’hôtes, le même principe s’applique via des known_hosts gérés ou via des certificats d’hôte.

Pièges typiques lors de la rotation

• Automatisations oubliées : CI-Runner, serveurs de sauvegarde, contrôles de monitoring, gestion de configuration. Ils utilisent souvent leurs propres clés.
• Clients embarqués : appliances ou anciennes images avec des entrées known_hosts codées en dur.
• « Accepté une fois » : postes d’administration où les avertissements concernant la clé d’hôte ont été fermés d’un clic. Cela se paie lors d’une rotation réelle.
• Dérive temporelle (pour les certificats) et incohérences DNS/IP (incompatibilité de clé d’hôte).

Mise en œuvre par étapes : des gains rapides vers une architecture cible propre

Si vous avez aujourd’hui un environnement hétérogène (serveurs classiques, VMs, hôtes Docker, éventuellement nœuds Kubernetes), un plan par étapes est plus réaliste qu’une migration complète.

Étape 1 : Visibilité et hygiène

• Inventorier : où le port 22 est-il ouvert ? Quels systèmes sont directement accessibles ?
• Hygiène des clés : quels authorized_keys se trouvent où ? Qui en est propriétaire ? Existe-t-il des clés partagées ?
• Centraliser la journalisation : au minimum le bastion et les classes de serveurs critiques vers un backend de logs.

# Grober Check: Welche Accounts haben authorized_keys?
sudo find /home /root -maxdepth 2 -type f -name authorized_keys -print

# Inhalte prüfen (Vorsicht: sensible Daten)
# Tipp: nur Fingerprints der Public Keys extrahieren
sudo awk '{print $1" "$2}' /home/*/.ssh/authorized_keys 2>/dev/null | sort -u | head

Étape 2 : forcer l’utilisation d’un hôte bastion

Techniquement, vous l’imposez via des règles réseau (Security Groups/pare-feu) et via des politiques SSH sur les hôtes cibles (seule l’IP du bastion doit pouvoir atteindre le port 22). Sur le plan organisationnel, les outils d’administration et les runbooks doivent être adaptés (ProxyJump, ProxyCommand).

# Beispiel: Client-Konfiguration ~/.ssh/config
Host bastion
  HostName bastion.example.net
  User admin

Host internal-*
  User admin
  ProxyJump bastion
  ServerAliveInterval 60

Piège : si vous exploitez le bastion comme point de défaillance unique (Single Point of Failure), vous échangez un risque contre un autre. Prévoyez au minimum de la redondance (p. ex. deux bastions, domaines de défaillance séparés) et une procédure Break-Glass documentée.

Étape 3 : introduire une SSH-CA pour les accès utilisateurs

Démarrez avec un segment pilote. Fixez des durées courtes (p. ex. une journée de travail) et définissez les principals de façon qu’ils correspondent à vos rôles. Mettez en place parallèlement un mécanisme de révocation : si vous pouvez arrêter l’émission, le dommage maximal causé par un certificat compromis est limité à sa durée de validité.

Étape 4 : modéliser proprement les automatisations (pas de « clé admin pour tout »)

Les automatisations ont besoin d’identités propres. Séparez :

• Accès administrateur humain (interactif, éphémère, traçable)
• Accès machine (non interactif, strictement limité, idéalement lui aussi via une logique de certificats ou des clés de déploiement clairement isolées)

Si vous administrez des hôtes Docker via SSH (par ex. pour les situations d’urgence), définissez des principals/comptes dédiés et évitez que les systèmes CI utilisent le même chemin d’accès.

Dépannage : lorsque les certificats SSH ou les connexions via bastion ne fonctionnent pas

Sur le terrain, il faut des étapes de vérification rapides utilisables sans expertise spécialisée.

1) Le certificat a expiré ou n’est pas encore valide

Symptôme : la connexion échoue malgré une configuration correcte. La cause est souvent une dérive de l’heure. Vérifier :

# Auf Client und Zielhost: Zeit prüfen
date -u

# NTP/Chrony Status (Beispiel, distroabhängig)
chronyc tracking 2>/dev/null || true
timedatectl status

Si l’heure est incorrecte : résoudre d’abord le problème d’heure, puis retester. L’authentification par certificat échouera systématiquement en cas d’heure incorrecte.

2) Le serveur fait confiance à la mauvaise CA (ou à aucune)

Vérifiez que la clé publique de la CA est correcte et chargée :

sudo sshd -T | grep -i 'trustedusercakeys|authorizedprincipals'

# Datei vorhanden?
sudo ls -l /etc/ssh/trusted-user-ca.pub

Piège courant : configuration répartie via sshd_config.d et ordre des lectures. Validez toujours avec sshd -T, car cela affiche la configuration effective.

3) Le proxy bastion se coupe (réseau/pare-feu)

Si ProxyJump se bloque ou se coupe, ce n’est souvent pas un problème SSH mais un problème de routage/pare-feu. Vérifiez depuis la bastion le port cible :

# Auf dem Bastion-Host: Zielhost erreichbar?
TARGET=internal-host-01
nc -vz $TARGET 22

# Alternativ mit bash TCP (ohne nc)
timeout 3 bash -c "</dev/tcp/$TARGET/22" && echo OK || echo FAIL

Si cela échoue, les journaux SSH côté client apportent peu. Le chemin réseau et les Security Groups sont alors le bon niveau d’investigation.

Liste de contrôle : durcissement SSH en environnements d’entreprise (pensé pour l’exploitation)

• Réseau : le port 22 accessible uniquement depuis le segment admin/la bastion, aucune exception directe « temporaire » sans date d’expiration.
• Auth : connexion par mot de passe désactivée ou fortement limitée ; contrôle clair par groupes (AllowGroups).
• Bastion : durci, version logicielle minimale, trafic sortant RESTreint, logs centralisés, processus Break-Glass défini.
• Certificats : SSH-CA déployée, durées courtes, Principals basés sur les rôles, heure/NTP stable.
• Rotation : Host-Keys/CA-Keys/User-Keys gérés selon un plan, confiance parallèle durant la fenêtre de migration, automatisations inventoriées.
• Audit : LogLevel, corrélation centralisée des logs, traçabilité des accès administrateurs.

Stratégie de repli : que faire si la nouvelle authentification bloque ?

Toute mesure de durcissement peut, en cas d’erreur, provoquer une « Self-Inflicted Outage ». Planifiez donc explicitement une stratégie de repli :

• Accès hors bande : console/iDRAC/IPMI/Cloud-Serial-Console – mais sécurisé et testé.
• Compte Break-Glass : compte dédié avec accès strictement contrôlé, idéalement uniquement via la bastion et activé pour une durée limitée.
• Déploiement par étapes : d’abord pilote, puis vagues. Ne jamais basculer toute la flotte simultanément.
• Changements de configuration atomiques : déployer les modifications de façon à permettre un reload (et éviter un redémarrage forcé en cas d’erreur).

Pratique recommandée : avant toute modification de sshd_config, conserver une deuxième session déjà ouverte, vérifier la syntaxe (sshd -t), puis recharger.

# Sichere Prüfsequenz vor dem Reload
sudo sshd -t && echo "Config OK" || echo "Config ERROR"

# Erst wenn OK:
sudo systemctl reload sshd

Conclusion : le durcissement SSH devient réellement maîtrisable avec une CA et la rotation

Le durcissement SSH est le plus efficace lorsque vous n’opérationnalisez pas seulement « durcir sshd », mais l’ensemble du chemin d’accès : les hôtes bastion réduisent la surface d’attaque et centralisent la télémétrie ; une autorité de certification SSH rend les identités contrôlables et éphémères ; la rotation des clés passe d’une exception contraignante à un processus planifié. Il est essentiel d’intégrer dès le départ la stabilité temporelle (NTP), les dépendances (automatisations) et une stratégie de repli testée. Ainsi, SSH devient non seulement plus sûr, mais aussi plus simple à administrer au quotidien.

Pour ce sujet, Ssh Key Management et Ssh Zertifikate sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui compte dans la pratique quotidienne.