Pendant des années, on a fait du SSH « à l’ancienne ». Une clé posée dans authorized_keys, un compte partagé « admin », parfois un VPN, et on se disait que c’était bon. Sauf que… en vrai, c’est confortable jusqu’au jour où tu dois répondre à une question simple, celle qui fait transpirer.
Qui s’est connecté, quand, sur quelle machine, et pour faire quoi ?
Le zéro trust appliqué à SSH, c’est ça. Partir du principe que personne n’est « de confiance » par défaut, même si la personne est interne, même si elle est dans le bon réseau, même si elle a déjà une clé. Et donc, on bascule vers des accès courts, contrôlés, révocables vite, et surtout auditables.
Dans cet article, je te montre une approche pratique, avec plusieurs options selon ton contexte, et des exemples concrets. Le but n’est pas d’ajouter 12 couches de complexité pour le plaisir. Juste d’arriver à un SSH propre.
Pourquoi « zéro trust » change vraiment la donne pour SSH
Le problème principal avec SSH classique, ce n’est pas SSH lui-même. C’est tout ce qu’on met autour.
- Des clés qui ne tournent jamais.
- Des comptes locaux qui s’accumulent.
- Des accès d’urgence qui deviennent permanents.
- Zéro trace exploitable, ou alors des logs incomplets.
Le zéro trust, appliqué proprement, impose quelques principes simples :
- authentification forte et centralisée
- autorisation explicite, idéalement par rôle
- accès à durée limitée
- journalisation complète, consultable et corrélable
Et oui, ça veut souvent dire qu’on arrête de « déposer une clé » comme unique stratégie.
Le modèle simple : SSH certifié (OpenSSH CA) + accès éphémère
Si tu veux un truc robuste sans dépendre d’un produit SaaS, le modèle OpenSSH CA est franchement une pépite. L’idée : au lieu d’ajouter des clés publiques partout, tu fais signer des certificats SSH à durée courte.
- l’utilisateur a une clé privée
- il obtient un certificat signé par une autorité (CA) interne
- le serveur fait confiance à la CA, pas aux clés individuelles
- le certificat expire (par exemple 15 minutes, 1 heure)
Côté serveurs : faire confiance à la CA
Sur tes serveurs, tu mets la clé publique de la CA dans TrustedUserCAKeys :
bash
TrustedUserCAKeys /etc/ssh/trusted-user-ca.pub PubkeyAuthentication yes PasswordAuthentication no
Puis reload :
bash sudo systemctl reload ssh
Et tu peux aussi forcer des règles par principal, par groupe, par source. Tu veux limiter, tu peux.
Côté utilisateur : obtenir un certificat valable 30 minutes
Exemple de signature (à faire sur la machine qui détient la CA, idéalement isolée) :
bash ssh-keygen -s user_ca -I "samyn-antoy" -n nun -V +30m id_ed25519.pub
-ndéfinit le principal autorisé-V +30mdonne une durée de validité courte
Ensuite l’utilisateur se connecte avec sa clé + certificat. Et quand c’est expiré, c’est fini. Même si la clé privée existe toujours.
Ce modèle règle déjà beaucoup de choses, surtout l’accès temporaire.
L’audit : enregistrer les sessions, pas juste les connexions
Un log de connexion SSH, c’est utile, mais souvent insuffisant. Ce que tu veux vraiment, c’est l’audit de session. Pas forcément pour espionner, plutôt pour investiguer vite quand il y a un incident ou un doute.
Tu as plusieurs niveaux :
- logs sshd (connexion, IP, user)
auditd(commandes, fichiers, syscalls)- enregistrement de session (tty recording)
- bastion qui enregistre tout
Un bastion SSH (jump host) bien configuré, avec enregistrement, c’est souvent le meilleur compromis. Tout le monde passe par un point unique, tu appliques les politiques, et tu centralises l’audit.
Option très efficace : un bastion moderne type Teleport
Je le dis clairement : si tu veux du zéro trust « prêt à porter » avec une bonne UX, Teleport est une référence.
Ce que ça apporte :
- certificats courts automatiquement
- MFA possible
- rôles et politiques fines
- enregistrement des sessions SSH
- recherche dans l’audit
- approbation d’accès (access request) pour du temporaire validé
En gros, tu peux faire : « j’ai besoin d’accès prod 1 heure », un manager approuve, tout est tracé, et ça expire.
C’est exactement l’esprit « accès temporaire et auditable ».
L’accès temporaire validé : workflow d’approbation (le vrai game changer)
Le zéro trust devient intéressant quand tu ajoutes une étape d’approbation pour certaines cibles.
Exemples typiques :
- accès production
- accès base de données
- accès machines sensibles
Tu définis une règle : pas d’accès direct. Il faut une demande, une justification, une durée. Et une trace.
Ça évite le classique : « j’ai gardé l’accès, au cas où ». Non. Tu redemandes, point.
Check-list rapide pour durcir SSH en mode zéro trust
Si tu veux avancer sans tout refaire d’un coup, fais ça dans cet ordre :
- désactiver les mots de passe SSH
- interdire le login root direct
- centraliser l’accès via un bastion
- passer aux certificats SSH à durée courte
- activer l’enregistrement de session sur les systèmes critiques
- ajouter MFA et approbations pour la prod
Et évidemment, rotation, révocation, inventaire. Toujours.
Petit mot de fin, et suite sur le blog
Si tu veux, je peux faire un second article plus « tuto » avec une mise en place complète OpenSSH CA, plus une variante bastion, plus une partie audit lisible, le tout étape par étape. Je publierai ça sur Le Blog Tech Pro de Samyn-Antoy ABASSE (tu peux garder l’URL sous la main : https://monblog-sa-abasse.blogspot.com), histoire de construire une mini série propre autour de l’admin Linux et de la sécurité.
Parce que le SSH zéro trust, au fond, ce n’est pas une mode. C’est juste la réponse moderne à une vieille question : comment donner accès sans perdre le contrôle.
Questions fréquemment posées
Qu'est-ce que le modèle zéro trust appliqué à SSH ?
Le modèle zéro trust pour SSH part du principe que personne n'est automatiquement digne de confiance, même les utilisateurs internes ou ceux disposant déjà d'une clé. Il impose une authentification forte et centralisée, une autorisation explicite par rôle, des accès à durée limitée et une journalisation complète pour un contrôle et une auditabilité renforcés.
Quels sont les problèmes courants avec la méthode SSH traditionnelle ?
La méthode SSH classique présente plusieurs failles : des clés qui ne tournent jamais, l'accumulation de comptes locaux, des accès d'urgence devenant permanents, et un manque de traçabilité exploitable ou des logs incomplets, ce qui rend difficile la gestion sécurisée des accès.
Comment fonctionne le modèle OpenSSH CA pour un accès SSH sécurisé ?
Le modèle OpenSSH CA utilise une autorité de certification interne pour signer des certificats SSH à durée courte. L'utilisateur possède une clé privée et obtient un certificat signé valide par exemple 15 minutes ou 1 heure. Les serveurs font confiance à la CA plutôt qu'aux clés individuelles, ce qui permet un contrôle d'accès temporaire et sécurisé.
Comment mettre en place la confiance envers une autorité de certification (CA) sur les serveurs SSH ?
Sur les serveurs SSH, il faut placer la clé publique de la CA dans le fichier 'TrustedUserCAKeys'. Ensuite, activer l'authentification par clé publique et désactiver l'authentification par mot de passe. Enfin, recharger le service SSH pour appliquer ces changements. Cela permet aux serveurs de faire confiance uniquement aux certificats signés par la CA.
Pourquoi est-il important d'enregistrer les sessions SSH et pas seulement les connexions ?
Enregistrer uniquement les connexions SSH fournit des informations limitées (utilisateur, IP). Pour une meilleure sécurité et capacité d'investigation en cas d'incident, il est essentiel d'auditer les sessions entières via des outils comme auditd, l'enregistrement tty ou un bastion SSH avec enregistrement complet. Cela permet de retracer précisément les actions effectuées durant chaque session.
Quels sont les avantages d'utiliser un bastion SSH moderne comme Teleport ?
Un bastion moderne comme Teleport centralise tous les accès SSH via un point unique où s'appliquent les politiques d'accès strictes. Il offre un enregistrement complet des sessions pour un audit efficace, simplifie la gestion des accès éphémères et renforce la sécurité globale sans ajouter une complexité inutile.
0 Commentaires