Suport technique et veille technologique

LinuxFr.org : les journaux  -  Dédier une clé SSH au rebond sur un serveur

 -  Décembre 2023 - 

Sommaire

• Rebondir avec ProxyJump
• Séparer les clés par niveau de sécurité
• Rebondir n'est pas une opération "sensible"
• La solution : command=ssh,restrict,permit-open
• Et si je dois administrer bastion avec une clé plus sécurisée ?

Bonjour nal,

Pour du développement, j'ai besoin d'administrer en SSH un serveur cible accessible depuis un serveur bastion. Dans ce document, j'explique comment dédier une clé SSH pour se connecter au bastion sans que cette clé ne puisse servir à rien d'autre qu'à rebondir vers d'autres serveurs.

On va parler de plein d'autres choses avant d'arriver au résultat.

Rebondir avec ProxyJump

On connaît l'option -J de SSH (ou ProxyJump dans ~/.ssh/config) qui permet de faire ça simplement :

ssh -J bastion cible

Ça ouvre une connexion SSH sur bastion et, à travers cette connexion, on ouvre une connexion SSH depuis mon PC vers la cible.

Parenthèse : Je rappelle au passage que l'idée alternative, consistant à utiliser ForwardAgent pour rendre accessible l'agent SSH qui tourne sur mon poste au programme SSH qui tourne sur bastion pour accéder à la clé privée permettant d'ouvrir la connexion vers cible est une très mauvaise idée : elle permet à celui qui administre le bastion d'utiliser toutes vos clés privées SSH pour se connecter à tout ce qu'il veut (c'est ce qui est arrivé à Matrix.org en avril 2019). On fait les choses bien, on utilise ProxyJump (qui est un wrapper autour de ProxyCommand, et voici comment fonctionne ProxyCommand), fin de la parenthèse.

Séparer les clés par niveau de sécurité

Je distingue mes clés SSH par niveau de sécurité :
- peu sécurisée : des clés sous forme de fichiers à plat (~/.ssh/id_...) sans mot de passe. Attaque: pour accéder à ma clé, le programme malveillant a juste besoin d'avoir accès en lecture au fichier.
- mieux sécurisée : des clés sous forme de fichiers à plat (~/.ssh/id_...), simplement protégées par mot de passe et chargées dans l'agent SSH pour ne pas avoir à retaper le mot de passe à chaque fois. Attaque: pour accéder à ma clé, le programme malveillant doit exécuter du code dans mon contexte et parler à mon agent SSH. Il ne peut pas extraire la clé mais peut l'utiliser pour se connecter sans mon accord. Il peut aussi essayer de trouver mon mot de passe en remplaçant la commande ssh-agent.
- mieux sécurisée (bis) : des clés dont la partie privée est non extractible car stockée sur un périphérique matériel dédié, par exemple sur un TPM ou une smartcard GPG ou x509. Attaque: idem.
- très sécurisée : une clé dont la partie privée est non extractible car stockée sur une yubikey qui me demande de confirmer chaque connexion par un appui tactile. Attaque: pour utiliser ma clé, le programme malveillant doit tenter d'ouvrir une connexion juste avant moi, attendre que je clique sur le bouton et faire ses dégâts sur le serveur distant avant que je ne réalise que mon appui ne m'a pas permis d'ouvrir la connexion que je voulais.

Se connecter à la cible est une opération plus ou moins sensible, selon ce qui est hébergé sur ce serveur (données de tests ou données de production, données triviales ou données sensibles …). Je choisis le niveau de sécurité de la clé en fonction de ce niveau de sensibilité.

Rebondir n'est pas une opération "sensible"

Mais se connecter au bastion pour rebondir ne doit pas être une opération sensible en soi : il n'y a pas de raison de taper deux fois sur ma yubikey pour parvenir à ma cible.

Sauf que, par défaut, la clé qui me sert à rebondir sert aussi à me connecter en SSH au bastion : à exécuter des commandes, à copier des fichiers, etc.

Mon soucis est donc le suivant : comment faire pour que la clé qui me sert à me connecter au bastion ne puisse pas servir à autre chose qu'à rebondir vers d'autres serveurs ?
Autrement dit, comment bloquer tous les autres usages de SSH spécifiquement pour cette clé de rebond ?

La solution : command=ssh,restrict,permit-open

Le problème semble simple, mais je n'ai trouvé nulle part la réponse. La configuration que j'ai trouvée, et que je soumets à votre sagacité, consiste à indiquer dans ~/.ssh/authorized_keys sur bastion :

command="ssh",restrict,port-forwarding ssh-rsa AAAAB3Nza......  ma-cle-peu-securisee

• command="ssh" force l'exécution de ssh dès qu'on se connecte à la machine. Je ne comprends pas bien pourquoi ça suffit pour exécuter ssh cible , mais ça marche
• restrict interdit a peu près tout
• port-forwarding réautorise le passage de port entre bastion et ma machine, nécessaire pour atteindre cible

Dès lors :

• ✅ Le rebond via -J fonctionne
• ✅ ssh bastion -i ma-cle-peu-securisee -> PTY allocation request failed on channel 0. Connection to bastion closed.
• ✅ scp bastion:~/.ssh/authorized_keys ./ -> scp: Connection closed (et le fichier n'est pas récupéré)

Objectif atteint.

Et si je dois administrer bastion avec une clé plus sécurisée ?

J'ai aussi une ligne dans .ssh/authorized_keys sur bastion qui m'autorise à me connecter avec ma yubikey pour l'administrer. Mais ma clé peu sécurisée est tentée la première, elle est acceptée et la connexion se ferme, sans que les clés suivantes ne soient pas tentées (contrairement à ce qui se serait passé si la clé peu sécurisée avait été rejetée d'emblée).

Pour contourner le problème, il faut exporter la clé publique SSH associée à la clé privée yubikey dans un fichier (par exemple, s'il s'agit d'une clé GPG sur la yubikey, avec gpg --export-ssh-key > ~/.ssh/yubikey.pub), puis indiquer cette identité lors de la connexion :

ssh -i ~/.ssh/yubikey.pub bastion

Voilà, comme j'ai passé un temps non nul sur ce que je pensais être assez trivial et que je n'ai pas trouvé de gens ayant documenté ça ailleurs (j'ai peut-être mal cherché), je me suis permis de partager ça ici. N'hésitez pas à corriger ou signaler des points aveugles en commentaire.

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Samuel