Journal coquillage inversé légitime

l'enfer c'est les autres

Récemment et contre tout bon sens, je me suis mis à offrir du support technique pour une utilisatrice GNU/Linux bidouillarde mais peu expérimentée. Mme Michu dispose d'une machine tournant sous une distribution avec laquelle je ne suis pas familier (Curvy Linux) qui a été installée par une personne qui n'est plus disponible.

Après le premier contact, il est vite apparu qu'il n'aurait pas été sain pour mon foie de me déplacer pour chaque intervention. D'où le besoin de mettre en place une solution de manipulation à distance. Mme Michu étant déjà habituée à une solution qui marche mais avec laquelle je m'interdit de contaminer mes machines, j'ai naturellement décidé de lui installer un truc plus compliqué et qui marche moins bien.

J'ai commencé par interroger un panel d'experts qui, dans leur grande sagesse, m'ont recommandé d'abandonner sans être capable de suggérer une piste de solution. Après avoir examiné la topologie locale ainsi que l'état de l'art, j'ai décidé qu'une solution à base d'OpenSSH me semble pas pire. Le reste de ce document décrit comment j'ai procédé.

salade de ports

Il y a trois machines en jeu : admin, serveur, client. La machine admin est mon poste de travail sur lequel je dispose d'un utilisateur et d'un client ssh. La machine serveur est une machine virtuelle nuagique disposant d'une adresse internet obsolète mais publique et sur laquelle j'ai le contrôle. La machine client est celle de Mme Michu.

Je veux réduire les risques qu'une présence malfaisante sur client puisse se propager à serveur ou admin et inversement. Je veux aussi donner à Mme Michu un semblant de contrôle sur quand j'accède à sa machine.

J'ai commencé par générer une clé SSH pour michu@client et à en copier la portion publique dans le ~/.ssh/authorized_keys de l'utilisatrice michu@admin fraîchement crée avec quelques restrictions :

no-agent-forwarding,no-pty,no-user-rc,no-X11-forwarding,command="/bin/sleep 31536000000000000",permitlisten="localhost:1337" ssh-rsa Ym9uam91ciBnZW50aWwgaGFja2VyIGRlIGxpbnV4ZnIK michu@client

En gros ça veut dire « autoriser uniquement le transfert de ports, n'autoriser à écouter que sur le port 1337 et déconnecter automatiquement après un milliard d'années ». Il y a bien un restrict qui permet d'activer toutes les restrictions mais il n'est apparemment pas possible de surcharger cette directive pour n'en autoriser qu'une (le transfert de ports). Ça veut aussi dire que la prochaine fois qu'OpenSSH implémente une nouvelle fonctionnalité associée à une directive no-*, il faudra penser à ajouter cette dernière explicitement.

Du côté client, j'ai installé un serveur OpenSSH qui n'écoute que sur les adresses de la boucle locale :

ListenAddress localhost

Je me suis crée un compte krunch@client sur lequel j'ai copié ma clé SSH publique et que j'ai ajouté aux sudoers.

J'ai aussi ajouté ceci dans le ~/.ssh/config de michu@client :

Host serveur
    HostName serveur.example.com
    RemoteForward localhost:1337 localhost:22

L'idée est qu'une fois la connexion ssh établie, le port 1337 sur serveur sera transmis au port 22 sur client. Le HostName permet aussi d'économiser un peu les doigts de Mme Michu.

Du côté admin, il me reste juste à ajouter ceci à mon ~/.ssh/config :

Host client
    HostName localhost
    Port 1337
    ProxyJump serveur.example.com

La subtilité vient de la toute nouvelle directive ProxyJump introduite dans OpenSSH 7.3 en 2016. Le client ssh se connecte d'abord à serveur, établi un tunnel TCP vers le port 1337 de serveur puis se connecte via ce tunnel. C'est un peu comme ForwardAgent / -A mais sans avoir à faire confiance à serveur.

En image, ça donne ceci :

   ┌──────┐  ┌──────────┐  ┌─────┐
   │client│  │  serveur │  │admin│
   │      │  │          │  │     │
   │   ───├──►22        │  │     │
   │      │  │          │  │     │
   │      │  │┌───────22◄──┤───  │
   │      │  ││         │  │     │
   │      │  │└─►1337──┐│  │     │
   │      │  │         ││  │     │
   │ 22◄──│──│─────────┘│  │     │
   │      │  │          │  │     │
   └──────┘  └──────────┘  └─────┘

après l'effort, l'effort suivant peut commencer

Maintenant, lorsque Mme Michu m'appelle pour que je l'aide avec le pilote de sa nouvelle carte wifi, je peux lui demander de taper ssh serveur dans son coquillage, suite à quoi il me suffit d'exécuter ssh client pour être connectée chez elle.

colophon

Pour des raisons évidentes de respect de la vie privée, les nom des machines, des distributions GNU/Linux ainsi que les numéros de ports ont été modifiés, sauf localhost et 22 pour des raisons d'intelligibilité.