Gestion des Identités : Bannir les mots de passe statiques en implémentant SSH avec clés éphémères et MFA

Pourquoi les mots de passe SSH statiques sont (encore) un gros problème

Imaginez la scène. Classique.

Un compte admin ou ops créé un vendredi soir, un mot de passe dit « temporaire », parce qu’il faut dépanner vite. Et puis ça passe dans le bruit. Deux semaines plus tard, plus personne ne se souvient qui l’a mis. Deux ans plus tard, il est toujours là.

Entre temps, quelqu’un s’est connecté. Pas en cassant la crypto. Pas en faisant du bruit. Juste... en utilisant ce secret qui traînait. Et comme il s’agit d’un accès SSH, souvent peu surveillé correctement, la compromission peut rester silencieuse longtemps. Trop longtemps.

SSH, c’est la porte d’entrée. Serveurs Linux, bastions, appliances réseau, VM dans le cloud, conteneurs via des nœuds, jobs CI/CD qui exécutent des scripts d’admin... Bref, dès qu’on parle d’exploitation, SSH est partout. Et du coup, c’est un endroit où les pratiques IAM approximatives deviennent dangereuses, très vite.

Le piège, c’est de croire que « fort » veut dire « sûr ». Un mot de passe long, aléatoire, dans un coffre, ça semble solide. Sauf que dans la vraie vie, il y a :

• la réutilisation (même partielle, même « juste pour un compte »)
• le phishing, et le phishing qui s’améliore chaque année
• le keylogging côté poste utilisateur
• les fuites de coffres, ou d’exports, ou de tokens d’API qui donnent accès au coffre
• le bruteforce quand on laisse des surfaces exposées
• le credential stuffing quand un secret fuit ailleurs et qu’on tente sa chance partout

Et surtout, le problème IAM derrière tout ça n’est pas « le mot de passe » en soi. Le vrai risque, c’est l’identité opérationnelle.

Dans un SI, une identité n’est pas une personne. C’est une combinaison : un compte + des secrets + des autorisations. Si je récupère un des secrets et que les autorisations sont larges, j’ai une identité exploitable. Même si personne ne s’est « fait pirater » au sens humain.

L’objectif de cet article est simple, et franchement assez radical : supprimer les secrets statiques côté humain pour SSH, en combinant clés éphémères, MFA, et contrôle d’accès centralisé. Moins de secrets qui dorment. Plus de preuves. Et un accès qui expire tout seul.

Ce qu’on vise vraiment : une authentification SSH moderne, traçable et à durée de vie courte

Avant de parler outils, on doit être clair sur le résultat attendu. Sinon on met juste un nouveau vernis sur l’ancien monde.

Le résultat attendu, je le résume en trois points :

1. pas de mot de passe SSH
2. pas de clé longue durée qui traîne sur les postes (ou alors, pas utilisable seule)
3. chaque accès est prouvé, attribuable, et journalisé

Pour arriver là, on assemble quelques briques qui existent déjà très bien :

• des clés éphémères, souvent via des certificats SSH
• du MFA, idéalement fort
• un SSO ou IdP (Identity Provider) pour porter l’identité et le cycle de vie
• des politiques d’accès (RBAC, ABAC) pour décider qui a le droit de faire quoi
• un bastion ou un agent, selon le modèle réseau et le niveau d’audit voulu

Et au passage, on arrête de confondre deux verbes qu’on mélange en permanence :

• authentifier : qui es tu
• autoriser : qu’as tu le droit de faire, où, et pendant combien de temps

Le SSH moderne doit gérer la notion de session. Pas juste « un login qui passe ». Une session, c’est une durée. Parfois une élévation. Parfois un enregistrement. Et toujours, une traçabilité.

Qui s’est connecté, à quel host, avec quel rôle, à quelle heure, pour combien de temps. Et idéalement, avec quel contexte : ticket d’incident, fenêtre de maintenance, approbation.

Les approches possibles (et pourquoi la clé éphémère + MFA est la plus saine)

Il existe plusieurs façons « d’améliorer SSH ». Certaines sont des progrès. D’autres sont juste des compromis.

Approche A : mots de passe + MFA

C’est mieux que mot de passe seul. Clairement.

Mais selon le contexte, ça reste phishable ou relayable. Typiquement, un attaquant qui maîtrise un proxy de phishing peut capturer un facteur et relayer la session. Tout dépend du MFA et de l’implémentation. Et si vous avez encore des mots de passe, vous avez encore… des secrets statiques. Donc du stockage, du partage potentiel, des copies, des erreurs humaines.

Approche B : clés SSH statiques

C’est souvent présenté comme la solution, surtout dans les équipes infra : « pas de mot de passe, donc c’est bon ».

Sauf que les clés statiques, c’est une autre forme de secret long terme. Rotation compliquée. Fuite silencieuse si une clé est exfiltrée. Partage de clés entre collègues « pour dépanner ». Absence d’expiration réelle. Et côté audit, c’est souvent flou : on voit un utilisateur local, pas forcément l’identité réelle, et pas le contexte.

Approche C : clés ou certificats SSH éphémères + MFA + politiques centralisées

C’est la plus saine, parce que ça colle à la réalité IAM.

On enlève le secret statique côté humain. Ou au minimum, on fait en sorte que la clé locale ne suffit pas, il faut un certificat court signé, obtenu après MFA. Et ce certificat expire.

Clarification importante : « clé éphémère » peut vouloir dire deux choses.

• soit une paire de clés générée à la volée, utilisée puis jetée
• soit une clé locale stable, mais qui reçoit un certificat éphémère signé par une CA SSH

En pratique, le second modèle est souvent plus fluide. La clé privée reste sur le poste, protégée, mais ne donne aucun accès sans certificat court. Et le certificat, lui, est délivré juste à temps, après authentification forte, et expire rapidement.

Opérationnellement, c’est aussi là que ça devient agréable : onboarding et offboarding simplifiés, accès juste à temps, réduction massive du périmètre de secrets à gérer. Moins de « qui a quelle clé sur quel serveur ». Plus de « qui a quel rôle dans l’IdP ».

Les concepts à maîtriser avant d’implémenter

On peut implémenter vite, oui. Mais il faut comprendre deux trois notions, sinon on construit une usine fragile.

Certificats SSH et CA

Un certificat SSH, ce n’est pas « une clé ». C’est une affirmation signée par une autorité de certification (CA) : « cette clé publique appartient à telle identité, avec tels droits, jusqu’à telle date ».

On a donc :

• une clé utilisateur : la clé publique et la clé privée
• un certificat : signé par la CA, qui contient des informations d’identité et de droits
• une CA SSH : qui signe les certificats et dont la clé publique est distribuée aux serveurs

Champs critiques à connaître :

• principals
• valid_aftervalid_before

Principals vs usernames

opsadminubuntu

L’idée est d’éviter les comptes partagés, ou au minimum de faire en sorte que l’identité réelle soit portée ailleurs (dans le certificat, dans les logs, dans la session bastion). Beaucoup d’organisations utilisent des usernames locaux standardisés, mais attachent un principal lié à l’identité IdP. Le but est de ne pas dépendre d’un compte « humain » créé à la main sur chaque serveur.

Bastion vs accès direct

Deux modèles principaux :

• accès direct : l’utilisateur obtient un certificat court et se connecte directement aux serveurs
• bastion : l’utilisateur se connecte au bastion (certificat court), puis le bastion relaye vers les cibles, souvent avec enregistrement

Le bastion ajoute du contrôle réseau et de l’audit. Il ajoute aussi un point central, donc un composant critique à sécuriser. L’accès direct peut être très propre aussi, si le réseau est bien segmenté et les logs bien collectés.

MFA : TOTP, push, WebAuthn

Tous les MFA ne se valent pas.

• TOTP : mieux que rien, mais phishable
• push : pratique, mais attention au push fatigue et au relay
• WebAuthn, FIDO2 : recommandé dès qu’on veut résister sérieusement au phishing, surtout pour les accès sensibles

Si vous avez un environnement prod critique, l’option WebAuthn mérite d’être la valeur par défaut. Quitte à garder TOTP pour certains cas de secours, très encadrés.

Journaux et corrélation

Un bon modèle SSH moderne doit permettre de corréler :

• l’identité IdP (utilisateur, groupes)
• le certificat émis (TTL, rôle, identifiant)
• l’événement SSH sur le serveur (auth success, session opened)
• éventuellement l’activité dans la session (si bastion ou auditd)

Sans ça, vous aurez un système « moderne » mais impossible à prouver.

Architecture de référence : SSH sans mot de passe statique, avec SSO + MFA + certificats courts

Voici le flux de bout en bout, dans une architecture type.

1. l’utilisateur demande un accès SSH
2. il s’authentifie via le SSO ou l’IdP, avec MFA
3. un service d’émission délivre un certificat SSH court (signé par la CA)
4. l’utilisateur utilise ce certificat pour se connecter au serveur cible, ou au bastion

Composants typiques :

• IdP : OIDC ou SAML, avec MFA et gestion de groupes
• SSH certificate issuer : un service qui parle à l’IdP et signe des certificats selon des politiques
• CA SSH : la clé privée de signature, hautement protégée
• TrustedUserCAKeys
• bastion (optionnel) : point de passage, audit, enregistrement

Durées de vie recommandées. Ça dépend, mais on peut donner des repères :

• 5 à 15 minutes pour les tâches sensibles, ou les rôles admin prod
• 1 à 8 heures maximum pour un usage standard, par exemple une journée de devops en non prod, avec renouvellement simple

Le point clé : si vous émettez des certificats valables 7 jours, vous avez recréé une clé statique, juste signée. Donc non.

Contrôle d’accès, en termes simples :

• groupes IdP → rôles SSH
• rôles SSH → principals autorisés
• principals → accès à des hosts, des labels, des environnements

Et idéalement, le certificat inclut des métadonnées : identifiant utilisateur, groupe ou rôle, TTL, et parfois une référence ITSM (ticket de change, incident). Ça change tout quand on enquête.

Mise en place côté serveurs : préparer OpenSSH pour accepter des certificats (sans casser l’existant)

Côté serveurs, l’objectif est d’ajouter le support des certificats sans couper brutalement les accès existants. On veut un déploiement progressif, pilotable.

Pré requis

• vérifier les versions OpenSSH, surtout sur les distributions anciennes
• faire un inventaire des serveurs et des points d’accès (bastions, jump hosts, appliances)
• définir une stratégie : pilote, puis généralisation, puis coupure des méthodes legacy

Configurer la confiance CA

Sur chaque serveur cible, il faut ajouter la clé publique de la CA dans un fichier, puis indiquer à sshd de lui faire confiance.

Typiquement :

• /etc/ssh/trusted-user-ca-keys.pem
• sshd_config

conf TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

AuthorizedPrincipalsFileMatch

Désactiver l’auth par mot de passe, mais de façon contrôlée

Le but final est souvent :

conf PasswordAuthentication no

Mais pas le jour 1.

On pilote d’abord. On s’assure que les certificats marchent. On s’assure que les équipes savent se connecter. Et ensuite on coupe.

À revoir aussi :

• PermitRootLoginnoprohibit-password
• AllowUsersAllowGroups
• limiter les comptes locaux utilisés pour se connecter

Renforcer l’hygiène SSH

Profitez du chantier pour regarder :

• AllowAgentForwarding no
• ciphers, KEX, MAC : aligner sur une baseline moderne
• logs : augmenter la qualité des journaux, sans noyer tout le monde

Stratégie de rollback et break glass

Un point sensible. On veut un rollback, mais sans recréer un « shadow access ».

Bon modèle :

• une fenêtre temporaire où les deux méthodes coexistent
• un compte break glass très encadré, hors SSO, avec accès réseau limité, MFA fort si possible, et surtout journalisation et procédure formelle
• tests réguliers du break glass, parce qu’un break glass jamais testé… n’existe pas

Mise en place côté utilisateurs : génération et usage de clés éphémères + MFA (expérience dev ops)

L’adoption dépend énormément de l’ergonomie. Si ça devient pénible, les gens vont contourner. Ou demander des exceptions. Ou remettre des clés statiques « juste pour ce serveur ».

Deux modèles courants.

Modèle 1 : paire de clés générée à la demande

L’outil génère une clé, demande un certificat, utilise le tout, puis supprime.

C’est propre. Très propre. Mais parfois moins pratique selon les workflows, surtout quand on jongle entre plusieurs sessions.

Modèle 2 : clé locale + certificat éphémère signé

C’est souvent le meilleur compromis.

• la clé privée reste sur le poste, protégée par le système et idéalement une passphrase
• l’IdP + MFA délivre un certificat court
• ssh-agent
• à la fin, le certificat expire, et la clé seule ne sert plus à rien

Et si possible, on évite de persister le certificat sur disque. Ou on le persiste dans un endroit temporaire, avec nettoyage.

Intégration MFA via SSO

Concrètement, l’expérience ressemble à :

• vous lancez une commande CLI
• elle ouvre un navigateur ou utilise un device code
• vous faites votre MFA (WebAuthn, par exemple)
• le certificat est récupéré et chargé automatiquement

L’important, c’est que la demande de certificat soit liée à une authentification fraîche. Pas un token vieux de 3 jours.

Bonnes pratiques côté poste client

Ça a l’air évident, mais il faut l’écrire.

• protéger la clé locale : permissions, stockage sécurisé, passphrase
• ne jamais partager de clé
• ne jamais stocker de secrets SSH dans des repos Git, même privés
• verrouillage écran, mises à jour, posture minimum
• si possible, contrôle de device dans l’IdP (device compliance), surtout pour la prod

Ergonomie et réduction des frictions

Aider les équipes avec :

• des alias SSH clairs
• ~/.ssh/config
• des patterns de nommage d’host
• une doc courte : « comment obtenir un certificat », « comment vérifier son TTL », « quoi faire si ça échoue »

C’est souvent là que le projet réussit ou échoue. Pas sur la CA.

Politiques IAM à appliquer : accès juste à temps, moindre privilège et séparation des rôles

Une fois que vous avez des certificats courts, vous pouvez enfin faire des politiques propres. Avant, c’était trop compliqué. Là, ça devient naturel.

Rôles clairs

Définir quelques rôles simples, et s’y tenir :

• lecture : diagnostic, logs, pas d’écriture
• opérateur : actions courantes, redémarrages encadrés
• admin : actions privilégiées
• prod vs non prod : séparation stricte, et pas juste « un label »

Just in time

Le JIT peut prendre plusieurs formes :

• TTL court par défaut
• approbation obligatoire pour la prod
• fenêtres de maintenance où certains rôles sont autorisés
• délivrance de certificats admin seulement si un ticket est référencé

L’idée n’est pas de ralentir tout le monde. L’idée est d’éviter l’accès permanent « au cas où ».

Séparation des tâches

Pas d’accès admin permanent. Et pas d’élévation implicite.

On peut garder un rôle opérateur pour le quotidien, puis un workflow d’élévation pour admin. Incident, problème, change. Avec durée courte.

Offboarding

C’est là que le modèle brille.

Vous retirez l’utilisateur des groupes IdP, c’est terminé. Même si une clé privée traîne sur un vieux laptop, elle ne peut plus obtenir de certificat. Et les certificats déjà émis expirent vite. Donc la fenêtre de risque est mécaniquement réduite.

Prestataires

Même logique, mais encore plus stricte :

• scopes précis, hosts précis
• TTL court
• supervision renforcée
• pas d’accès direct si vous pouvez l’éviter, bastion recommandé
• revues fréquentes

Supervision et traçabilité : savoir qui s’est connecté, quand, et ce qu’il a fait

Si on supprime les secrets statiques, ce n’est pas juste pour être « plus secure ». C’est aussi pour reprendre le contrôle, preuves à l’appui.

Logs d’authentification

Il faut relier :

• l’identité IdP
• le principal dans le certificat
• l’événement d’authent SSH côté serveur

Et s’assurer que l’on peut répondre à une question simple : « qui est cette personne dans l’annuaire ».

Enrichissement des événements

Les événements gagnent en valeur si vous ajoutez :

• TTL du certificat
• rôle ou groupe
• device (si connu)
• IP source, pays, ASN
• passage par bastion ou non

Ensuite, vous envoyez ça au SIEM, vous corrélez, vous alertez.

Enregistrement de session

Si vous avez un bastion, l’enregistrement devient plus accessible :

• commandes
• flux
• timing

On n’est pas obligé d’enregistrer tout le monde, tout le temps. Mais sur la prod, ou sur les rôles admin, c’est souvent un bon compromis. Et c’est extrêmement utile en post incident.

Détection

Quelques détections basiques, mais efficaces :

• connexions hors horaires habituels
• élévations anormales, ou trop fréquentes
• taux d’échec élevé
• IP atypiques, pays inattendus
• certificats émis avec TTL plus long que la politique (ça arrive, via exceptions)

Conformité

Avec ce modèle, vous pouvez produire :

• des preuves d’accès
• des revues périodiques de rôles
• des politiques de rétention de logs cohérentes

Et ça, côté audit, ça change la conversation. On n’est plus sur « on pense que ». On est sur « voici les événements ».

Plan de migration réaliste (sans bloquer l’équipe)

Le plus gros risque d’un projet comme ça, c’est de vouloir tout couper trop vite. Et de créer une révolte douce. Ou une avalanche d’exceptions.

Un plan réaliste ressemble à ça.

Étape 1 : pilote non prod + groupe restreint

Un environnement non prod, un petit groupe SRE ou ops motivé. On valide :

• émission de certificats
• connexion
• logs
• TTL
• ergonomie

Étape 2 : déployer la confiance CA partout

TrustedUserCAKeys

But : être prêt le jour où on bascule. Et détecter les serveurs « hors gestion ».

Étape 3 : activer progressivement les rôles

On commence à faire passer des usages réels via certificats : astreinte, maintenance, intervention planifiée. On ajuste les politiques.

Étape 4 : réduire l’usage des clés statiques et couper les mots de passe

• rotation des clés statiques restantes
• interdiction du partage
• suppression des clés orphelines
• PasswordAuthentication no

Oui, dans l’outline il manque une étape 3 et on saute à 4. Dans la vraie vie aussi, on saute parfois. Tant que le plan reste lisible.

Étape 5 : durcissement final et contrôle continu

• durcissement SSH
• bastion et enregistrement si requis
• monitoring, alerting, revues régulières

Mesures d’adoption

• checklists simples
• templates de config SSH
• formation courte de 30 minutes
• support incident : un canal clair, une doc courte, des réponses rapides

Les erreurs fréquentes à éviter (celles qui ruinent le modèle)

Quelques erreurs reviennent tout le temps. Et elles sabotent l’intérêt même des certificats courts.

Conserver des clés statiques « au cas où » partout

C’est le fameux shadow access.

Si vous laissez des clés statiques en parallèle, sans inventaire strict et sans date de fin, vous aurez deux systèmes. Et l’attaquant choisira le plus faible.

TTL trop long

Une « clé éphémère » valable 7 jours n’est plus éphémère. Point.

Si vous avez peur de l’expiration, c’est souvent un problème d’ergonomie, pas un problème de sécurité. Il faut rendre le renouvellement simple.

Pas de procédure break glass encadrée

Soit vous n’en avez pas, et vous paniquez le jour où l’IdP est indisponible. Soit vous en avez une trop permissive, et elle devient la porte d’entrée permanente.

Le break glass doit être rare, surveillé, et testé.

Oublier l’IdP

Groupes mal gérés, MFA contournable, cycle de vie non maîtrisé. Au final, vous avez de beaux certificats, mais une identité faible.

Le projet est IAM avant d’être SSH.

Logs insuffisants

Si vous ne pouvez pas auditer, vous ne pouvez pas prouver. Et si vous ne pouvez pas prouver, vous perdez une grande partie de la valeur. Sans parler de la réponse à incident.

Conclusion : bannir les mots de passe statiques, c’est surtout reprendre le contrôle des identités

En une phrase : certificats SSH courts + MFA + politiques centralisées = moins de secrets, moins de risques, plus d’audit.

Le conseil actionnable, si vous devez démarrer lundi : faites un pilote. Définissez des TTL clairs et quelques rôles simples. Puis coupez progressivement les mots de passe et les clés longue durée, serveur par serveur, équipe par équipe. Pas besoin d’attendre le design parfait.

Le bénéfice business est réel, et pas juste « sécurité » : réduction de surface d’attaque, onboarding et offboarding rapides, conformité plus simple, et enquêtes plus courtes quand quelque chose se passe mal.

Et la clôture pragmatique, la seule qui compte : mieux vaut 80 % déployé partout avec un TTL court, que 100 % parfait sur cinq serveurs. Le risque, lui, ne s’arrête pas à cinq serveurs.

Questions fréquemment posées

Pourquoi les mots de passe SSH statiques posent-ils un problème majeur en sécurité ?

Les mots de passe SSH statiques, souvent créés temporairement pour un dépannage rapide, restent fréquemment actifs pendant des années sans surveillance. Cela permet à des attaquants d'accéder silencieusement aux systèmes via ces secrets oubliés, compromettant ainsi la sécurité sans alerter les équipes.

Quels sont les risques liés à l'utilisation de mots de passe longs et supposés forts pour SSH ?

Même un mot de passe long et aléatoire peut être compromis par des pratiques comme la réutilisation partielle, le phishing sophistiqué, le keylogging, les fuites de coffres ou tokens d'API, le bruteforce sur surfaces exposées et le credential stuffing. Le vrai risque est lié à l'identité opérationnelle associée au mot de passe.

Quelle est la différence entre authentifier et autoriser dans le contexte SSH moderne ?

Authentifier consiste à vérifier l'identité de l'utilisateur (qui es-tu), tandis qu'autoriser détermine ce que cet utilisateur a le droit de faire, où et pendant combien de temps. Une gestion moderne du SSH doit séparer clairement ces deux notions pour assurer une meilleure sécurité et traçabilité.

Quels sont les objectifs clés d'une authentification SSH moderne et sécurisée ?

Les objectifs principaux sont : 1) éliminer les mots de passe SSH statiques, 2) éviter les clés longues durées utilisables seules sur les postes utilisateurs, 3) garantir que chaque accès soit prouvé, attribuable à une identité précise et journalisé pour assurer traçabilité et contrôle.

Quelles technologies ou méthodes permettent d'atteindre une authentification SSH moderne ?

On combine plusieurs briques : des clés éphémères via certificats SSH, un MFA fort, un SSO ou fournisseur d'identité (IdP) pour gérer l'identité et son cycle de vie, des politiques d'accès basées sur RBAC ou ABAC, ainsi qu'un bastion ou agent pour contrôler et auditer les accès réseau.

Pourquoi l'approche combinant clés éphémères et MFA est-elle considérée comme la plus saine pour sécuriser SSH ?

Cette approche réduit drastiquement les secrets statiques qui dorment sur les postes ou dans les coffres. Elle impose une preuve forte d'identité via MFA et limite la durée de validité des accès grâce aux clés éphémères. Cela minimise les risques liés au phishing, au vol ou à la réutilisation des secrets tout en assurant une traçabilité complète.