Certificats SSH : une meilleure expérience SSH

• 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

• Guide de sécurité OpenSSH de Mozilla
• Article de recherche sur la vérification des empreintes de clés hôtes SSH via DNS
• Documentation d’implémentation de la prise en charge des certificats OpenSSH dans PuTTY et guide de configuration

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