Certificats SSH : une meilleure expérience SSH

 (jpmens.net)
6 points par GN⁺ 27 일 전 | 1 commentaires | Partager sur WhatsApp
  • Les certificats SSH résolvent les contraintes de l’authentification SSH classique basée sur des clés publiques et fournissent une confiance automatique entre le client et le serveur
  • Pris en charge depuis OpenSSH 5.4, ils permettent à une CA (autorité de certification) de signer les clés utilisateur et hôte afin d’authentifier sans modifier authorized_keys
  • Les certificats peuvent inclure une durée de validité, des utilisateurs autorisés (principals), des IP d’accès, une commande forcée (force-command), etc., pour un contrôle d’accès fin
  • La procédure TOFU (Trust on First Use) disparaît, et il devient possible de se connecter en toute sécurité sans avertissement lors d’un changement de clé hôte
  • Avec un serveur ou des outils de signature automatique, il est possible d’automatiser la gestion SSH dans de grands environnements serveurs tout en améliorant la sécurité

Présentation des certificats SSH et limites de l’authentification SSH classique par clés

  • Lors d’une connexion SSH, il faut vérifier l’empreinte (fingerprint) de la clé hôte du serveur lors de la première connexion. En pratique, la plupart des utilisateurs ne la valident pas et saisissent simplement « yes », suivant ainsi le modèle TOFU (Trust on First Use)
    • Un administrateur peut vérifier directement l’empreinte du serveur ou la valider avec la commande ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
  • L’authentification par clé publique permet de se connecter sans mot de passe, mais il faut déployer la clé publique dans le fichier authorized_keys de chaque serveur
  • Avec l’agent SSH (ssh-agent), il est possible de conserver la clé privée en mémoire afin de s’authentifier sans la ressaisir à chaque fois
  • Limites de l’approche classique
    • Il faut copier la clé publique de chaque utilisateur sur les serveurs
    • Un message d’avertissement apparaît côté client lorsqu’une clé hôte change
    • La gestion de la confiance devient contraignante à cause du TOFU

Certificats SSH et autorité de certification (CA)

  • Le certificat SSH (Certificate) est pris en charge depuis OpenSSH 5.4 (mars 2010) et repose sur une extension du format de clé SSH existant
  • Une CA SSH est constituée d’une paire de clés SSH, dont la clé publique joue le rôle de racine de confiance
  • Principaux avantages
    • Aucune modification du fichier authorized_keys du serveur n’est nécessaire
    • Aucun avertissement lors du remplacement d’une clé hôte
    • La suppression de la procédure TOFU permet une confiance automatique
    • Le certificat peut contenir des utilisateurs autorisés (principals), des IP autorisées, une durée de validité, une commande forcée (force-command), etc.
    • L’accès est automatiquement bloqué à l’expiration du certificat

Mise en place d’une CA SSH et procédure de signature

  • Sur le système CA, création d’une paire de clés CA avec l’algorithme ECDSA
    • ssh-keygen -t ecdsa -C "SSH CA" -f CA/ssh-ca
  • L’utilisateur transmet sa clé publique (*.pub) à la CA, qui la signe (sign) et émet un certificat (*-cert.pub)
    • Exemple : ssh-keygen -s CA/ssh-ca -I "Jane Jolie" -n jane -z 001 -V +1w jane.pub
  • Configuration du serveur
    • Enregistrer la clé publique de la CA dans /etc/ssh/ssh-ca.pub et ajouter le paramètre TrustedUserCAKeys
    • Signer la clé hôte du serveur avec la CA (ssh-keygen -h -s CA/ssh-ca ...) puis l’enregistrer dans l’entrée HostCertificate
  • Configuration du client
    • Ajouter une ligne @cert-authority dans le fichier known_hosts
    • Exemple : @cert-authority *.example.com $(cat CA/ssh-ca.pub)

Connexion et vérification avec des certificats SSH

  • L’utilisateur se connecte avec le certificat signé et la clé privée (ssh -i jane -l jane alice.example.com)
  • Les journaux du serveur enregistrent l’ID, le numéro de série (serial) et l’empreinte de la CA du certificat
  • Il est possible d’ajouter plusieurs noms d’hôte ou adresses IP comme principal dans le certificat
  • Si l’on tente de se connecter avec un utilisateur autre qu’un principal déclaré dans le certificat, l’erreur « Certificate invalid: name is not a listed principal » apparaît
  • On peut appliquer un contrôle d’accès fin avec une commande forcée (force-command) ou des IP autorisées (source-address)

Liste de vérification pour contrôle et dépannage

  • Éléments à vérifier côté serveur

    • Paramètre TrustedUserCAKeys présent et clé publique de la CA disponible
    • Clé hôte signée et HostCertificate défini
    • Redémarrage de sshd nécessaire

  • Éléments à vérifier côté client

    • La clé utilisateur doit être signée par la CA
    • L’entrée @cert-authority de known_hosts et le principal doivent correspondre
    • À l’expiration du certificat, le message « Certificate invalid: expired » s’affiche
    • En cas de non-concordance avec les contraintes du certificat, une demande de mot de passe apparaît
    • Lors de l’ajout du certificat à l’agent SSH, la clé et le certificat sont tous deux enregistrés (ssh-add jane)
    • Les options de signature (-O) permettent de contrôler les fonctionnalités
    • Exemple : avec -O clear, tous les droits sont retirés puis seuls permit-agent-forwarding et permit-port-forwarding sont autorisés

Automatisation des certificats de clés hôtes

  • Le module Python sshkey-tools et BottlePy permettent d’implémenter un serveur de signature automatique (hkbot)
    • Après lancement de hkbot.py sur le serveur CA, l’envoi d’une requête HTTP avec la clé publique hôte déclenche automatiquement la signature
    • Côté client, la commande curl -F hostkey=@/etc/ssh/ssh_host_ed25519_key.pub http://CA:8870 | sh permet l’installation automatique
    • La configuration est appliquée après modification de /etc/ssh/sshd_config, vérification, puis systemctl restart sshd
  • Les connexions SSH peuvent ensuite s’appuyer sur les certificats pour établir automatiquement la confiance et permettre la connexion

Résumé des avantages des certificats SSH

  • TOFU inutile, avec une confiance automatique entre client et serveur
  • Émission de certificats à courte durée de validité pour un contrôle d’accès temporaire
  • Blocage automatique de l’accès à l’expiration du certificat, sans nettoyage de authorized_keys
  • Possibilité de définir des politiques fines avec commande forcée, restriction PTY, contrôle par IP d’accès
  • Les outils d’automatisation permettent de simplifier la gestion de grands environnements serveurs
  • Le projet Smallstep SSH est présenté comme ressource associée

Références complémentaires

Mise à jour

  • Une CA SSH est particulièrement utile dans un environnement où l’on possède ses propres serveurs avec des privilèges root
  • Sur les systèmes multi-utilisateurs, les approches classiques avec known_hosts et authorized_keys restent toujours nécessaires
  • Projet de standardisation du format des certificats SSH : draft-miller-ssh-cert-06

À lire aussi

1 commentaires

 
GN⁺ 27 일 전
Commentaires Hacker News

  • Je suis surpris que des gens utilisent encore des mots de passe SSH
    Surtout dans les grands groupes, où plusieurs politiques de mot de passe s’entremêlent, au point que se connecter à un simple serveur prend du temps
    Donc même si on leur explique d’utiliser des clés avec ssh-keygen, la plupart se disent juste « il faudra que j’essaie un jour » et ne le font jamais

    • Les clés sont utiles quand il existe un système de gestion centralisé côté personnel ou entreprise
      Mais en pratique, la gestion tourne vite au chaos, avec une même clé publique utilisée sur plusieurs serveurs ou des clés partagées entre personnes
      Les mots de passe ont au moins l’avantage d’être simples
    • Depuis des années, je gère mes clés SSH avec un HSM basé sur Yubikey
      Il n’y a pas de mot de passe, mais il faut toucher physiquement la Yubikey au moment de la connexion
    • L’usage de clés distribuées comme ssh-copy-id facilite les déplacements latéraux d’un attaquant dans le réseau, donc beaucoup d’organisations l’interdisent

  • Tous les quelques mois, quelqu’un redécouvre les certificats SSH et écrit un billet de blog à ce sujet
    Moi aussi, j’ai écrit un article sur le sujet il y a 15 ans, et avec le recul il était incomplet

    • Beaucoup de gens confondent clés et certificats
      Même des ingénieurs sécurité oublient parfois qu’ils utilisent une authentification par clé, et non des certificats SSH
    • Les certificats SSH sont utiles parce qu’ils permettent d’accorder à un utilisateur donné un accès limité dans le temps et en privilèges
    • Je connaissais moi aussi les certificats SSH, mais je n’ai jamais réussi à quitter le modèle basé sur les clés
      Gérer manuellement les clés sur plusieurs serveurs est bien trop pénible
      Je me demande s’il vaut encore la peine de migrer maintenant
    • Il y a 10 ans, quand mon entreprise a mis en place une autorité de certification SSH, nous nous sommes appuyés sur le billet de blog ci-dessus

  • L’approche TOFU (Trust On First Use) est simple, mais elle va déjà assez loin
    Sur mes serveurs, une fois que j’ai vérifié moi-même la clé d’hôte, cela me suffit
    Dans un grand environnement d’entreprise, il suffit de publier la liste des clés publiques des serveurs internes sur un site web interne signé en SSL
    Mais dans les environnements avec beaucoup de serveurs ou des changements fréquents, les certificats sont bien meilleurs, et TOFU a ses limites à plusieurs niveaux
    J’aimerais aussi que les navigateurs avertissent quand la clé TLS d’un serveur change

    • J’utilise SSH depuis 1996, mais je n’ai jamais vu quelqu’un vérifier manuellement une clé publique en pratique
      La plupart tapent simplement « yes » et passent à autre chose

  • Dans mon entreprise, nous gaspillons énormément de temps et d’argent à cause de l’inspection SSL de Zscaler
    Quand l’erreur « self-signed certificate in certificate chain » s’affiche, c’est toujours une galère

    • J’ai analysé Zscaler installé sur le Windows 11 de l’entreprise d’un ami, et c’était presque du niveau d’un malware
      Il installe son propre certificat racine et verrouille les paramètres du navigateur pour empêcher l’usage d’un proxy
      Même si on modifie les fichiers de configuration de Firefox ou Chrome, ils sont immédiatement écrasés
      Il faut même un mot de passe IT pour le désactiver via l’interface graphique
      C’est à peine mieux que l’antivirus Cybereason
    • Dans notre entreprise, Cisco Umbrella fait la même chose
      Il casse tous les protocoles basés sur HTTP
      Git, RubyGems, go mod, Nix et quantité d’autres outils se retrouvent cassés
      Le fournisseur prétend que c’est « transparent », mais en réalité pas du tout
      Il faut des heures pour diagnostiquer les problèmes, et la plupart des administrateurs ignorent à quel point c’est destructeur
    • À noter que les certificats SSH sont différents des certificats X.509

  • L’article ne mentionnait que les avantages des certificats d’autorité de certification, mais il y a clairement aussi des inconvénients
    Je n’ai jamais eu de problème de sécurité lié à TOFU

    • Dire « il ne s’est jamais rien passé, donc c’est sûr » revient à dire qu’on peut ne pas porter de ceinture de sécurité
      S’il y a des inconvénients aux certificats SSH, j’aimerais savoir lesquels précisément
    • TOFU est pratique, mais ce n’est pas indispensable
      Pour renforcer la sécurité, on peut échanger les clés publiques par un canal sûr comme une clé USB
      Même avec des certificats, il faut au fond suivre la même procédure ; la seule différence est que la responsabilité de la gestion passe de l’utilisateur à l’administrateur
      Dans les grandes organisations, les certificats peuvent être utiles, mais le niveau de sécurité général reste le même
    • Si l’on peut configurer l’autorité de certification à l’avance, on peut éviter TOFU
      Il suffit de l’inclure dans un script d’installation ou une image de déploiement
      TOFU n’a de sens que lorsqu’on accède à une machine déjà configurée
    • Dire « il n’y a encore jamais eu d’incident de sécurité lié à TOFU » signifie seulement qu’il n’y en a pas encore eu

  • Dans nos environnements dev/stg, nous réinstallons la moitié des machines chaque jour
    Grâce aux certificats d’hôte SSH, c’est bien plus pratique : plus besoin de nettoyer known_hosts ni de conserver les clés

  • Je développe en projet perso un outil appelé Sshifu
    C’est un outil qui facilite la connexion basée sur des certificats SSH et le SSO
    Il suffit d’installer sshifu-server sur le serveur pour l’utiliser comme CA, puis de configurer chaque serveur SSH pour faire confiance à cette CA
    L’utilisateur n’a plus qu’à se connecter avec la commande npx sshifu
    Voir le dépôt GitHub

  • En production réelle, l’accès basé sur des certificats mène à des problèmes de gestion complexes
    Expiration des certificats, suppression des utilisateurs, connexion en cas de panne serveur : de nombreux sujets apparaissent
    Chez Userify, nous traitons ces problèmes depuis 15 ans, et bâtir une infrastructure d’authentification SSH stable n’a rien de simple

    • Mais à mon avis, le mode SaaS est le pire choix possible

  • J’ai ajouté la prise en charge des certificats SSH à pico.sh, et cela a été très utile pour mettre en place un contrôle d’accès de style RBAC
    Voir la documentation

  • En production, les certificats SSH ont plutôt tendance à centraliser la complexité et à aggraver les problèmes
    Une CA unique doit être disponible en permanence, et en cas de panne tout accès est bloqué
    Il y a aussi des problèmes très concrets comme le réglage du TTL, la gestion de la racine de confiance ou la difficulté du débogage
    Au final, les gens réintroduisent des caches ou des agents
    Nous faisons l’inverse : chaque nœud synchronise via HTTPS les informations utilisateur dans authorized_keys en local
    Cela permet de conserver un contrôle centralisé tout en localisant les pannes
    C’est l’approche utilisée chez Userify, qui gère non seulement l’authentification mais aussi les autorisations
    Les certificats seuls ne résolvent pas des problèmes comme la création des utilisateurs, les rôles sudo ou le nettoyage des répertoires personnels

    • On nous demande comment nous gérons TOFU