Publication en open source d’OpenPubkey SSH (OPKSSH) — un système de single sign-on intégré à SSH

• Cloudflare a publié en open source OPKSSH (OpenPubkey SSH)
• OPKSSH permet de générer et d’utiliser automatiquement des clés SSH via une connexion SSO basée sur OpenID Connect
• Les utilisateurs n’ont plus besoin de gérer eux-mêmes leurs clés publiques/privées SSH ni de les déployer sur les serveurs
• Il devient possible d’introduire une approche d’accès fondée sur l’identité pour l’authentification SSH, sans modifier le protocole SSH

Contexte : SSO et OpenID Connect

• Le SSO (Single Sign-On) est une méthode d’authentification qui permet à un utilisateur d’accéder à plusieurs systèmes après une seule connexion
• OpenID Connect est un protocole principalement utilisé pour le SSO, qui émet des jetons d’identité contenant des informations sur l’utilisateur
• Un jeton d’identité contient des informations comme l’adresse e-mail de l’utilisateur, mais pas de clé publique → il ne peut donc pas être utilisé directement pour un protocole de sécurité comme SSH

Présentation d’OpenPubkey

• OpenPubkey ajoute la clé publique de l’utilisateur dans le jeton d’identité pour en faire un PK Token
• Cela permet de certifier que « Google atteste que l’utilisateur [e-mail] utilise la clé publique 0x123 »
• Il peut être appliqué sans aucune modification du protocole OpenID Connect existant

Rôle et avantages d’OPKSSH

• OPKSSH intègre OpenPubkey à SSH pour générer des clés SSH éphémères via une connexion SSO
• Il fonctionne sans modification du protocole SSH existant et peut être activé en ajoutant seulement deux lignes au fichier de configuration

• Amélioration de la sécurité

  • Utilisation de clés SSH éphémères au lieu de clés de longue durée → réduction de l’impact en cas de fuite et possibilité de limiter la durée de vie des clés
  • Expiration par défaut au bout de 24 heures, modifiable via la configuration

• Amélioration de l’expérience utilisateur

  • Il suffit d’exécuter la commande opkssh login pour générer une clé SSH et se connecter
  • Plus besoin de copier une clé privée SSH sur plusieurs ordinateurs

• Amélioration de la visibilité pour l’administration

  • Accès fondé sur l’adresse e-mail plutôt que sur des clés → il devient plus clair de savoir qui est l’utilisateur
  • Il suffit d’ajouter une adresse e-mail comme [e-mail] dans le fichier d’autorisation d’accès pour accorder immédiatement l’accès

Fonctionnement d’OPKSSH

• Lorsqu’un utilisateur exécute opkssh login :
  • génération d’une paire de clés SSH publique/privée temporaire
  • connexion via le navigateur à un fournisseur OpenID (Google, etc.)
  • en cas de succès, création d’un PK Token contenant la clé publique et l’identité de l’utilisateur via le protocole OpenPubkey
  • enregistrement dans le répertoire .ssh d’un fichier de clé publique contenant le PK Token et du fichier de clé privée
• Lors d’une connexion SSH :
  • le client SSH envoie au serveur SSH la clé publique contenant le PK Token
  • le serveur délègue la validation de la clé publique à l’outil OpenPubkey verifier configuré via AuthorizedKeysCommand
  • si le PK Token est valide et que l’e-mail figure dans la liste des accès autorisés, la connexion est approuvée

Résolution des problèmes techniques

• Transmission du PK Token : le PK Token est intégré à la clé publique SSH à l’aide du champ d’extension des certificats SSH
• Validation côté serveur : AuthorizedKeysCommand permet de déléguer la validation de la clé publique à un programme personnalisé (OpenPubkey verifier)
• Vérification de correspondance de la clé publique : vérification que la clé publique protégeant la session SSH correspond à celle contenue dans le PK Token

Passage en open source et sa signification

• OPKSSH est publié sur GitHub sous licence Apache 2.0
• Alors qu’il n’était auparavant qu’au stade de prototype, il propose désormais une version stable avec des fonctions SSH complètes
• Cloudflare n’en assure ni la maintenance ni la garantie, mais a fait don du code à la communauté OpenPubkey

Principales améliorations

• ajout de fonctions SSH utilisables en conditions réelles
• fourniture d’un script d’installation automatique
• inclusion d’outils de configuration améliorés

[GN⁺]

Avis Hacker News

• Les certificats SSH existent depuis longtemps, et il est possible de créer sa propre CA SSH pour émettre des certificats de courte durée
  • Il existe diverses options pour obtenir automatiquement des certificats, dont le projet step-ca
  • step-ca peut communiquer avec des systèmes OAUTH/OIDC et des fournisseurs cloud
  • Des solutions commerciales existent également
• Préférence pour une approche utilisant une CA SSH et du matériel
  • Cela évite d’avoir à appeler du code tiers depuis SSHD, ce qui minimise la surface et les vecteurs d’attaque
  • Cela permet d’empêcher complètement les fuites de clés ou les attaques par réutilisation
  • Tout peut être fait avec la commande ssh-keygen par défaut, ce qui est avantageux du point de vue de l’administrateur
• Doute sur l’affirmation selon laquelle un jeton d’identité ne contenant pas la clé publique de l’utilisateur ne peut pas protéger directement le protocole SSH
  • L’authentification SSH n’a pas nécessairement besoin d’être fondée sur des clés
  • Question sur la possibilité de l’implémenter via GSSAPI
• Utilisation de Teleport pour une authentification SSH basée sur des certificats, avec émission de certificats de courte durée via une authentification SSO
  • Cela offre des avantages en matière de contrôle d’accès et de journaux d’audit
• Développement en cours d’une alternative à SSH appelée Terminalwire
  • Adaptée à l’exécution de commandes ponctuelles vers un SaaS depuis un poste de travail développeur
  • Semblable à SSH en ce qu’il diffuse stdio du serveur vers le client, mais fournit des commandes supplémentaires
• Comparaison avec la technologie de clés SSH de Userify
  • Userify utilise des clés ordinaires distribuées et ne centralise que le plan de contrôle
  • Il reste possible de se connecter aux serveurs même si le serveur d’authentification est hors ligne
  • Il permet de terminer les sessions utilisateur et de supprimer les comptes
• En tant qu’auteur du billet de blog et principal contributeur à opkssh, prêt à répondre aux questions
• Difficulté à voir la différence avec l’exploitation d’une CA SSH prenant en charge OIDC
  • Les serveurs n’ont qu’à faire confiance à la clé de la CA
• Il existe un fork d’OpenSSH prenant en charge une CA de certificats X.509
  • Il trouve amusant que le fait de présenter comme innovant une norme qui renvoie la clé publique sous forme de jeton, ainsi qu’un binaire d’authentification côté serveur l’utilisant pour se connecter en SSH