URL: https://linuxfr.org/users/samuel/journaux/dedier-une-cle-ssh-au-rebond-sur-un-serveur Title: Dédier une clé SSH au rebond sur un serveur Authors: Samuel Date: 2023年12月08日T23:17:08+01:00 License: CC By-SA Tags: ssh, authentification, ssh-agent, yubikey, smartcard et sécurité Score: 42 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](https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident/#ssh-agent-forwarding-should-be-disabled)). On fait les choses bien, on utilise `ProxyJump` (qui est un wrapper autour de `ProxyCommand`, et [voici comment fonctionne ProxyCommand](https://serverfault.com/questions/544545/how-does-ssh-proxycommand-actually-work/544555#544555)), 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.

AltStyle によって変換されたページ (->オリジナル) /