SSH moderne : clés, FIDO2, bastion, et politiques

SSH, on l’utilise tous. Tous les jours. Et pourtant, dans beaucoup d’environnements, c’est resté un truc un peu… ancien monde. Une paire de clés qui traîne sur un laptop, un authorized_keys qui grossit, des accès directs sur des serveurs exposés, et parfois un mot de passe encore activé « au cas où ».

Sauf que maintenant, on a mieux. On a des bonnes pratiques plus réalistes, et des outils qui ne demandent pas de réinventer l’infra entière. Clés plus propres, certificats SSH, FIDO2, bastions, politiques, journalisation. Et surtout une façon plus saine de répondre à la question qui fâche : qui a accès à quoi, quand, et comment on le retire.

Dans cet article, je pose une vue d’ensemble « SSH moderne », avec du concret, des configs, et des choix. Pas une vérité unique, plutôt une boîte à outils.

Pourquoi moderniser SSH (même si « ça marche »)

Le risque principal, ce n’est pas SSH en lui-même. C’est tout ce qu’on a empilé autour.

Quelques situations très classiques :

• une clé privée copiée sur 3 machines parce que « c’est pratique »
• des clés sans passphrase, parce que « sinon ça casse les scripts »
• un accès direct au serveur de prod depuis Internet, ouvert sur 22/tcp
• aucune traçabilité : on sait qu’on est passé, mais qui exactement, avec quelle identité…
• le jour où quelqu’un part : on oublie une clé dans un authorized_keys secondaire, et tant pis

Moderniser SSH, c’est réduire l’exposition, réduire la durée de vie des identifiants, et rendre la révocation… enfin faisable.

Les fondamentaux : des clés propres, courtes, et bien gérées

Avant de parler FIDO2 ou bastion, on remet les bases au carré.

Choisir les bons algos aujourd’hui

• Ed25519 : excellent choix par défaut.
• RSA : encore OK si taille suffisante, mais plutôt en compatibilité.
• DSA : à oublier.

Génération :

bash ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_samyn

• -a 100 augmente le coût KDF pour résister aux attaques hors ligne.
• une passphrase, oui. On en reparle juste après.

Passphrase + agent : la combo qui évite les « clés nues »

Une clé sans passphrase, c’est comme laisser un badge d’accès dans la rue. L’argument « mais c’est pour l’automatisation » est souvent un symptôme d’architecture, pas une obligation.

Sur poste utilisateur, utilisez l’agent :

bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519_samyn

Et dans ~/.ssh/config :

sshconfig Host * AddKeysToAgent yes UseKeychain yes IdentityFile ~/.ssh/id_ed25519_samyn

Sur Linux, UseKeychain n’existe pas, mais l’idée reste : agent + durée de vie raisonnable.

authorized_keys : mettre des contraintes, pas juste des clés

On peut limiter les dégâts avec des options par clé.

Exemple :

text from="10.10.0.0/16",no-agent-forwarding,no-port-forwarding,no-pty ssh-ed25519 AAAA...

Ça ne remplace pas une vraie politique, mais ça évite des scénarios bêtes.

FIDO2 et clés matérielles : l’anti exfiltration simple et efficace

C’est là que ça devient vraiment intéressant.

Une clé SSH classique peut être copiée. Une clé FIDO2 (YubiKey, Nitrokey, SoloKey…) peut être utilisée, mais la clé privée ne sort pas du matériel. Même si ton laptop est compromis, l’attaquant ne récupère pas une clé exportable « pour plus tard ».

Deux modes : U2F vs resident keys

OpenSSH supporte FIDO2 avec -t ed25519-sk ou -t ecdsa-sk.

• ed25519-sk : recommandé si supporté.
• resident key : la clé est stockée sur la token, pratique pour mobilité.

Génération :

bash ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk_samyn

Resident key :

bash ssh-keygen -t ed25519-sk -O resident -O verify-required -f ~/.ssh/id_ed25519_sk_resident

• verify-required force le PIN ou l’interaction utilisateur selon le token, c’est bien.
• certains tokens demandent de toucher la clé, ce qui tue pas mal de scénarios d’attaque.

Côté serveur : rien de spécial, mais attention aux versions

Le serveur voit une clé publique comme une autre. Ce qui compte, c’est le client OpenSSH et la lib FIDO2 (selon OS).

Vérifiez vos versions, et testez sur un environnement de staging. Toujours.

Certificats SSH : arrêter de gérer des clés à la main (à grande échelle)

À partir de 10, 20, 50 serveurs, le modèle « je copie la clé publique partout » commence à coûter cher.

Les certificats SSH (OpenSSH CA) changent le jeu :

• les serveurs font confiance à une CA
• les utilisateurs obtiennent un certificat à durée courte
• la révocation devient une question de durée de vie, plus que de chasse aux clés

Principe rapide

1. Vous créez une CA pour signer les clés utilisateurs.
2. Les serveurs ont TrustedUserCAKeys.
3. Vous signez des certificats valables, par exemple, 8 heures.

Création CA :

bash ssh-keygen -t ed25519 -f /etc/ssh/ssh_user_ca -C "SSH User CA"

Signer une clé user :

bash ssh-keygen -s /etc/ssh/ssh_user_ca -I samyn -n samyn,ops -V +8h ~/.ssh/id_ed25519_samyn.pub

Côté serveur, dans /etc/ssh/sshd_config :

conf TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub

Et vous redémarrez sshd.

Pourquoi c’est moderne

Parce que vous arrêtez de gérer des listes infinies. Et vous pouvez lier ça à de l’IAM, du SSO, ou un workflow interne : « tu as le droit ? ok, voici un cert valable 1 heure ».

Outils souvent utilisés pour ça :

• Smallstep step-ca
• HashiCorp Vault (SSH secrets engine)
• Teleport (approche plus intégrée)

Le bastion : le vrai point de contrôle (et le point de friction aussi)

Le bastion, c’est le serveur par lequel on passe. Certains le détestent parce que « ça rajoute une étape ». Oui. Et c’est le but.

Un bastion bien fait :

• évite d’exposer tous les serveurs
• centralise les logs
• permet des politiques réseau simples : seuls les flux bastion vers cibles sont autorisés
• facilite l’élévation temporaire, et le JIT (just in time)

Architecture simple

• Internet ou VPN ou ZTNA vers bastion
• bastion vers réseau interne
• cibles non exposées

Règle d’or : si un serveur n’a aucune raison d’être accessible publiquement, il ne l’est pas.

ProxyJump : ergonomie côté client

Dans ~/.ssh/config :

sshconfig Host bastion HostName bastion.example.com User samyn

Host prod-* User ops ProxyJump bastion

Connexion :

bash ssh prod-app-01

L’utilisateur oublie presque le bastion, mais vous gardez le contrôle.

Durcir le bastion

Quelques pistes simples :

• pas de mot de passe SSH
• MFA ou FIDO2 côté accès bastion
• restrictions fortes : pas de shell si pas nécessaire, ou shell restreint
• pas de forwarding inutile

Dans /etc/ssh/sshd_config sur bastion :

conf PasswordAuthentication no PermitRootLogin no AllowAgentForwarding no X11Forwarding no PermitTunnel no AllowTcpForwarding no

Vous pouvez être plus souple selon usage, mais partez strict.

Politiques SSH : ce qu’il faut décider noir sur blanc

Un « SSH moderne » ce n’est pas juste une techno. C’est une politique.

Voici des règles qui fonctionnent bien en entreprise, et même sur des projets perso un peu sérieux :

1) Authentification

• utilisateurs humains : FIDO2 ou clés + certificats courts
• automatisation : certificats courts via Vault ou step-ca, ou clés dédiées, isolées, et rotées
• interdiction des mots de passe SSH, sauf break glass documenté

2) Réseau et exposition

• pas de SSH direct sur toutes les machines
• bastion obligatoire ou accès via VPN ou ZTNA
• filtrage IP si contexte stable

3) Durée de vie et rotation

• clés utilisateurs : rotation régulière (ex : 6 mois)
• certificats : durée courte (ex : 1 heure à 8 heures)
• inventaire : savoir quelles identités existent et où

4) Journalisation et traçabilité

• logs SSH centralisés (syslog, SIEM)
• corrélation identité : user, source IP, heure, host cible
• idéalement : enregistrement de session sur bastion (selon sensibilité)

5) Provisioning et offboarding

Le offboarding est le test ultime.

• si quelqu’un part, ses accès doivent tomber en minutes, pas en semaines
• avec certificats courts, c’est presque gratuit : on stoppe l’émission de cert, et c’est fini
• avec clés statiques, c’est une chasse. Donc si vous êtes encore en statique partout, au moins : inventaire + automatisation de suppression

Automatisation : comment ne pas casser la prod avec « trop de sécurité »

On veut sécuriser, pas bloquer les équipes.

Cas typique : Ansible, CI/CD, scripts

Pour l’automatisation, les options réalistes :

• compte de service limité, clé dédiée, IP restreinte, commandes limitées
• ou mieux : certificats SSH éphémères signés à la demande (Vault est très bon pour ça)

Évitez le piège : une clé privée partagée entre 4 pipelines. Ça arrive tout le temps. Et ça finit mal.

Commandes forcées : réduire l’impact d’un compte technique

Dans authorized_keys :

text command="/usr/local/bin/deploy-only.sh",no-pty,no-agent-forwarding ssh-ed25519 AAAA...

Vous dites : cette clé ne sert qu’à déployer. Point.

Checklist rapide : à quoi ressemble une mise à niveau progressive

Si vous ne savez pas par où commencer, faites simple, par étapes.

1. désactiver PasswordAuthentication
2. passer en Ed25519 partout
3. mettre un bastion ou ProxyJump, et fermer l’accès direct
4. activer logs centralisés
5. introduire FIDO2 pour les admins
6. introduire certificats SSH pour réduire authorized_keys
7. documenter politique + offboarding

Ça peut se faire sur 4 semaines, sans projet titanesque. Franchement.

Exemple de configuration sshd « propre » (base)

Dans /etc/ssh/sshd_config :

conf Port 22 Protocol 2

PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes

X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no

ClientAliveInterval 300 ClientAliveCountMax 2

LogLevel VERBOSE

• LogLevel VERBOSE aide pour la traçabilité (à calibrer selon volume).
• ClientAlive* coupe des sessions mortes.

Adaptez, testez, et faites une fenêtre de changement. Toujours.

Un mot sur l’expérience utilisateur (parce que sinon, les gens contournent)

Si l’expérience est pénible, les gens vont bricoler. Donc :

• fournissez un ~/.ssh/config standard
• documentez 3 commandes : « obtenir un cert », « se connecter », « debug »
• faites un guide de récupération : token perdu, laptop réinstallé, etc.

Et oui, ça a sa place sur un blog tech pratique.

Sur Le Blog Tech Pro de Samyn-Antoy ABASSE, je garde ce genre de procédures et checklists dans mes pages et articles orientés terrain. Si vous voulez, vous pouvez aussi passer par https://monblog-sa-abasse.blogspot.com et piocher dans les ressources, ou me contacter via « Mes services » quand il faut transformer ça en mise en place propre (bastion, politiques, durcissement, doc interne). Ça évite les demi mesures.

Conclusion : SSH moderne, c’est surtout une histoire de durée de vie et de points de contrôle

Si je devais résumer sans faire trop long.

• les clés statiques partout, ça ne scale pas
• FIDO2 réduit un risque énorme : l’exfiltration silencieuse
• les certificats SSH rendent l’accès temporaire naturel
• le bastion ramène contrôle, logs, et politiques réseau simples
• une politique écrite rend l’offboarding possible, donc la sécurité réelle

Et après, seulement après, vous commencez à parler « zéro trust », ZTNA, et tous les grands mots. La base, c’est déjà puissant.

---

Images (sources)

Les images intégrées proviennent de Unsplash, utilisables comme illustrations dans un contexte éditorial.

Questions fréquemment posées

Pourquoi moderniser SSH alors que ça fonctionne déjà ?

Moderniser SSH permet de réduire les risques liés à la gestion des clés et des accès : éviter la copie excessive de clés privées, renforcer la sécurité avec des passphrases, limiter l'exposition des serveurs, assurer une traçabilité précise des connexions, et faciliter la révocation rapide des accès lorsque nécessaire.

Quels sont les algorithmes recommandés pour générer des clés SSH aujourd'hui ?

Ed25519 est le choix par défaut recommandé pour sa sécurité et sa performance. RSA reste acceptable si la taille de clé est suffisante, principalement pour compatibilité. DSA est à éviter complètement.

Comment sécuriser efficacement ses clés SSH avec une passphrase et un agent ?

Il est conseillé d'utiliser une passphrase pour protéger la clé privée, évitant ainsi les « clés nues ». Pour ne pas pénaliser l'automatisation ou l'usage quotidien, on peut utiliser un agent SSH (comme ssh-agent) qui stocke temporairement la clé déchiffrée en mémoire, permettant un usage fluide tout en conservant la sécurité.

Quelles bonnes pratiques appliquer dans le fichier authorized_keys ?

Il faut limiter les accès par clé en ajoutant des contraintes comme restreindre les IP sources, désactiver le transfert d'agent ou de port, interdire l'accès à un terminal interactif, etc. Ces restrictions minimisent les dégâts en cas de compromission d'une clé.

Qu'est-ce que FIDO2 et comment améliore-t-il la sécurité SSH ?

FIDO2 correspond à l'utilisation de clés matérielles (YubiKey, Nitrokey, SoloKey) qui stockent la clé privée sans jamais l'exposer hors du matériel. Cela empêche toute exfiltration même si l'ordinateur est compromis. OpenSSH supporte FIDO2 avec les types ed25519-sk ou ecdsa-sk.

Quelle différence entre les modes U2F et resident keys pour FIDO2 en SSH ?

Le mode U2F (ed25519-sk) nécessite une interaction physique à chaque utilisation mais ne stocke pas la clé sur le token. Le mode resident key stocke la clé directement sur le token (avec options comme -O resident), facilitant la mobilité car la clé est toujours disponible sur le token lui-même. L'option verify-required force une authentification utilisateur renforcée.