Foxency
Sécurité Informatique et Réseaux

Durcissement SSH et gestion des accès administratifs

Les comptes d'administration sont la cible favorite des attaquants. Durcissement d'OpenSSH, bastion, MFA, certificats SSH à courte durée et traçabilité : comment protéger les accès privilégiés.

Par Rédaction Foxency Publié le 5 min de lecture

Administrateurs accédant aux serveurs uniquement à travers un bastion SSH avec authentification forte

Un attaquant qui obtient un accès administrateur contrôle le système, et souvent bien davantage. Les accès privilégiés méritent donc une protection supérieure à celle des comptes ordinaires. SSH, outil principal d'administration des serveurs Linux et des équipements réseau, est au centre de ce dispositif.

Objectif : durcir la configuration d'OpenSSH et organiser les accès administratifs autour d'un bastion, de l'authentification forte, de certificats et de la traçabilité. Les bases (clés, configuration client, tunnels) sont dans SSH : configuration et sécurisation.

Les principes de la gestion des accès privilégiés

  1. Comptes nominatifs : chaque administrateur utilise son propre compte, jamais un compte partagé comme root ou admin. L'élévation de privilèges passe par sudo, journalisé.
  2. Moindre privilège : des droits limités au périmètre de chacun. Voir Contrôle d'accès et principe du moindre privilège.
  3. Point d'entrée unique et maîtrisé : un bastion.
  4. Authentification forte : clés ou certificats, complétés par un second facteur.
  5. Traçabilité : qui s'est connecté, où, quand, et qu'a-t-il fait ?
  6. Révocation rapide au départ d'un administrateur ou à la perte d'un appareil.

Durcir la configuration d'OpenSSH

Les réglages suivants constituent une base solide pour un serveur récent. Placez-les dans un fichier de /etc/ssh/sshd_config.d/ :

# /etc/ssh/sshd_config.d/60-durcissement.conf — exemple
# Authentification
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30
AllowGroups ssh-admins

# Fonctions non nécessaires
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
PermitUserEnvironment no

# Sessions
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 4

# Journalisation détaillée (empreinte de la clé utilisée)
LogLevel VERBOSE

Sur le bastion, AllowTcpForwarding doit au contraire autoriser le rebond (au minimum local), puisque c'est son rôle.

Les algorithmes

Les versions récentes d'OpenSSH désactivent par défaut les algorithmes faibles. Plutôt que de recopier une liste figée qui vieillira mal, maintenez OpenSSH à jour et auditez périodiquement les algorithmes proposés :

sudo sshd -T | grep -E '^(kexalgorithms|ciphers|macs|hostkeyalgorithms)'

Supprimez les clés d'hôte DSA éventuelles et privilégiez Ed25519 (RSA 3 072 bits minimum si nécessaire). Si des équipements anciens imposent des algorithmes faibles, isolez-les et limitez l'exception aux seuls hôtes concernés.

Testez toujours avec sshd -t et gardez une session ouverte pendant les modifications.

Protéger contre la force brute

Avec l'authentification par mot de passe désactivée, les tentatives de devinette deviennent inefficaces, mais elles encombrent les journaux. Mesures complémentaires :

  • Restreindre l'accès par le réseau : le port SSH des serveurs n'est joignable que depuis le bastion ou le réseau d'administration. C'est la mesure la plus efficace.
  • Fail2ban ou un mécanisme équivalent bannit temporairement les adresses qui multiplient les échecs.
  • Limitation de débit des nouvelles connexions sur le pare-feu.
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

Le bastion

Un bastion (jump host) est le point de passage obligé vers les ressources administrées.

Poste d'administration ──SSH (MFA)──▶ Bastion ──SSH──▶ Serveurs / équipements
                                         │
                                         └─ journaux, enregistrement des sessions

Règles de conception :

  • les serveurs et équipements n'acceptent SSH que depuis le bastion (pare-feu et AllowUsers user@adresse si nécessaire) ;
  • le bastion est durci, minimal, maintenu à jour et supervisé ;
  • l'authentification sur le bastion est multifacteur ;
  • les administrateurs utilisent ProxyJump depuis leur poste : leur clé privée ne quitte jamais leur machine ;
  • les sessions sont journalisées, voire enregistrées par une solution de gestion des accès privilégiés (PAM).

Le bastion devient lui-même une cible de très grande valeur : il mérite le plus haut niveau de protection et de surveillance.

L'authentification multifacteur

Plusieurs approches existent :

  • Clés matérielles FIDO2/U2F : OpenSSH (depuis la version 8.2) prend en charge les types de clés ed25519-sk et ecdsa-sk. La clé privée est liée à un jeton physique, et chaque utilisation peut exiger une présence physique (contact) ou un code PIN. Excellente résistance à l'hameçonnage et au vol de fichiers.
  • Codes à usage unique (TOTP) via un module PAM, en complément de la clé publique :
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes

combiné à la configuration PAM correspondante. - Authentification déléguée à un fournisseur d'identité via une solution d'accès privilégié.

# Générer une clé liée à un jeton FIDO2
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin@poste-admin01"

Les certificats SSH

Gérer des fichiers authorized_keys sur des centaines de serveurs devient vite ingérable : clés oubliées, anciens collaborateurs toujours autorisés. Les certificats SSH résolvent ce problème :

  1. Une autorité de certification SSH (une paire de clés dédiée, très protégée) signe la clé publique de l'administrateur, avec une durée de validité courte (quelques heures) et des principaux autorisés.
  2. Les serveurs font confiance à l'autorité, et non à chaque clé individuelle.
# Signer la clé publique d'un administrateur, valable 8 heures, pour le principal "admin-linux"
ssh-keygen -s ca_admin -I "jdupont-20261029" -n admin-linux -V +8h id_ed25519.pub

# Sur chaque serveur : /etc/ssh/sshd_config.d/70-ca.conf
TrustedUserCAKeys /etc/ssh/ca_admin.pub
AuthorizedPrincipalsFile /etc/ssh/principaux/%u

Avantages : plus de distribution de clés, expiration automatique, rattachement à une identité, révocation simplifiée. Les certificats peuvent aussi authentifier les serveurs auprès des clients, supprimant les questions d'empreinte lors de la première connexion. Dans la pratique, la signature est souvent automatisée par un service qui vérifie d'abord l'identité de l'administrateur (avec MFA).

Traçabilité

  • Journaux SSH centralisés, avec LogLevel VERBOSE pour enregistrer l'empreinte de la clé utilisée.
  • Journalisation de sudo (Defaults logfile, ou envoi vers syslog), voire enregistrement des sessions (sudo avec l'option log_output, ou outil dédié).
  • auditd pour tracer les commandes et accès sensibles sur les serveurs critiques.
  • Alertes sur les connexions inhabituelles : horaires, sources, comptes.

Voir Journalisation et supervision des événements de sécurité.

Équipements réseau

Les mêmes principes s'appliquent aux routeurs et commutateurs : SSH version 2 uniquement, Telnet désactivé, lignes VTY limitées par ACL au réseau d'administration, authentification centralisée par TACACS+ ou RADIUS (avec un compte local de secours protégé), journalisation des commandes (comptabilité TACACS+).

Erreurs courantes

  • Comptes partagés et mots de passe connus de toute l'équipe.
  • Ports SSH exposés sur Internet sans restriction de source.
  • Clés d'anciens administrateurs toujours présentes dans les fichiers authorized_keys.
  • Agent forwarding activé vers des serveurs partagés.
  • Bastion non maintenu, devenu le maillon faible.

Conclusion

Protéger les accès d'administration, c'est combiner une configuration OpenSSH stricte, un point d'entrée unique, une authentification forte, des certificats à courte durée et une traçabilité complète. Ces mesures réduisent fortement le risque de compromission par vol d'identifiants, première cause d'intrusion dans de nombreux incidents.

Références