Ouvrir un DevContainer sur un serveur distant avec VSCode Remote SSH et ProxyJump

Je devais écrire un script Bash qui récupère des fichiers sur un serveur SFTP et envoie des requêtes POST à une API sécurisée. Assez simple — sauf que les deux se trouvent sur un segment réseau privé uniquement joignable depuis un serveur Linux précis. Et ce serveur Linux n'est lui-même joignable que depuis une VM Windows au bureau. Mon portable, au bout de la chaîne, ne voit aucun des deux services directement.

Sans la technique ci-dessous, le workflow est lourd : ouvrir un terminal sur la VM, faire un SSH vers le serveur Linux, éditer le script avec nano, l'exécuter, copier-coller les erreurs vers mon éditeur. Pas génial.

Ou bien je peux me passer complètement de la VM et travailler directement depuis mon portable. Cet article présente les deux chemins — et la route directe depuis le portable est plus simple qu'elle n'y paraît.

Avec VSCode Remote SSH enchaîné à Dev Containers, le workflow devient : ouvrir VSCode, se connecter une fois, et travailler exactement comme en local — éditeur complet, devcontainer complet, et le serveur SFTP ainsi que l'API joignables depuis le terminal intégré. Il y a deux façons de mettre ça en place, et l'article couvre les deux.

Prérequis : vous devez déjà être à l'aise avec les bases de VSCode Remote SSH. Sinon, Développement distant en SSH avec VSCode couvre l'installation de l'extension et le fichier de configuration SSH depuis zéro.

Ce que vous obtenez au final​

Avec l'approche recommandée, l'architecture ressemble à ceci :

VSCode tourne sur votre portable et se connecte au serveur Linux en un clic — la VM Windows n'est qu'un relais dans la configuration SSH, invisible à l'usage. Le devcontainer tourne sur le serveur Linux, donc il hérite du réseau du serveur : le serveur SFTP et l'API sécurisée sont joignables depuis l'intérieur du container, même s'ils sont invisibles depuis votre portable.

Quelle approche vous convient ?​

Deux situations, deux chemins :

Pour vérifier si l'approche recommandée est disponible, lancez ceci depuis le terminal de votre portable :

ssh -J vm-user@windows-vm-ip dev-user@test.example.internal "whoami && hostname"▋

• Ça affiche dev-user et le nom d'hôte du serveur Linux → utilisez l'approche recommandée.
• Ça part en timeout → votre portable ne peut pas joindre la VM du tout → utilisez l'approche de repli.
• Connection refused sur le port 22 → la VM est joignable mais OpenSSH Server n'est pas installé → voyez le correctif ci-dessous.

La seconde ligne est la sortie de hostname sur la machine distante — elle reflète le nom défini dans /etc/hostname, qui peut différer de l'adresse utilisée pour vous connecter. C'est normal ; ce qui compte, c'est que la commande ait renvoyé quelque chose plutôt que de partir en timeout ou d'être refusée.

$ Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
$ Start-Service sshd
$ Set-Service -Name sshd -StartupType Automatic

Pourquoi ça fonctionne​

• Deux extensions, une seule chaîne. Remote - SSH lance un processus VS Code Server sur l'host Linux. Dev Containers démarre ensuite un container sur cet host et y connecte VSCode — le container tourne sur le moteur Docker du serveur, pas sur celui de votre portable.
• Le privilège réseau est hérité de l'host. La pile réseau du container vit sur le serveur Linux, donc chaque connexion sortante part de l'IP du serveur. Les services qui bloquent l'adresse de votre portable laissent passer le serveur.
• ProxyJump délègue le relais à SSH. Avec ProxyJump dans ~/.ssh/config, SSH ouvre une connexion vers la VM, puis y fait passer une seconde connexion SSH vers le serveur Linux. VSCode ne voit qu'un seul host et un seul clic.
• Aucun transfert de fichiers. Les fichiers vivent sur le serveur. L'éditeur les lit et les écrit directement — pas de scp, pas de rsync, pas d'étape d'upload.

Configurer SSH​

Approche recommandée — ProxyJump depuis votre portable​

Prérequis​

Votre clé privée SSH (~/.ssh/id_ed25519) doit se trouver sur votre portable — si vous n'en avez pas encore, cet article détaille la génération d'une paire de clés ed25519. ProxyJump fait passer l'authentification dans le tunnel — la clé de votre portable authentifie les deux hosts, donc elle n'a jamais besoin de quitter votre machine. L'authentification par mot de passe fonctionne aussi si l'authentification par clé n'est pas en place sur la VM windows-vm-ip.

Configurer SSH sur votre portable​

Créez le fichier C:\Users\your_laptop_user\.ssh\config (Windows ; WSL inclus) ou ~/.ssh/config (si vous êtes sous Linux/macOS) sur votre portable :

Host linux-test
    Hostname test.example.internal
    User dev-user
    ProxyJump vm-user@windows-vm-ip
    IdentityFile ~/.ssh/id_ed25519

La ligne ProxyJump indique à SSH d'atteindre linux-test en passant par la VM windows-vm-ip. À partir de là, ssh linux-test depuis votre portable se connecte directement au serveur Linux — plus d'étape manuelle sur la VM.

Tester la chaîne complète​

Lancez la commande avec l'alias nommé, maintenant que la configuration est en place :

$ ssh linux-test "whoami && hostname"▋

La première exécution ressemblera à ceci :

$ ssh -J vm-user@windows-vm-ip dev-user@test.example.internal "whoami && hostname"
The authenticity of host 'windows-vm-ip (1.2.3.4)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789ABCD.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'windows-vm-ip' (ED25519) to the known hosts.
vm-user@windows-vm-ip's password:
The authenticity of host 'test.example.internal (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789BCDE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'test.example.internal' (ED25519) to the known hosts.
dev-user@test.example.internal's password:
dev-user
test.example.internal

Deux choses se produisent ici, toutes deux normales et uniquement à la première fois :

• Les demandes de clé d'hôte (The authenticity of host ... can't be established) : SSH n'a jamais vu ces hosts. Tapez yes pour chacun — l'empreinte est stockée dans ~/.ssh/known_hosts et la question ne revient plus.
• Les demandes de mot de passe : une pour la VM et une pour le serveur Linux — la connexion fonctionne dans tous les cas. Pour la rendre totalement silencieuse, autorisez votre clé publique sur chaque host (voir ci-dessous).

$ cat ~/.ssh/id_ed25519.pub

$ Add-Content C:\ProgramData\ssh\administrators_authorized_keys "ssh-ed25519 AAAA...your-key-here"

$ ssh-copy-id linux-test
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
dev-user@linux-test's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'linux-test'"
and check to make sure that only the key(s) you wanted were added.

Approche de repli — VSCode sur la VM Windows​

Suivez ce chemin si l'approche recommandée n'est pas disponible (serveur SSH non installé sur la VM windows-vm-ip, ou VM non joignable en SSH depuis votre portable).

Créer le fichier de configuration SSH sur la VM​

Ouvrez une session Powershell sur la VM windows-vm-ip. Si le sous-dossier $HOME\.ssh n'existe pas encore, créez-le : New-Item -ItemType Directory -Path "$HOME\.ssh".

Ouvrez (ou créez) C:\Users\vm-user\.ssh\config dans Notepad. Le fichier doit s'appeler config, sans extension — config.txt est silencieusement ignoré par tous les clients SSH.

Host linux-test
    Hostname test.example.internal
    User dev-user
    IdentityFile ~/.ssh/id_ed25519

Copier votre clé privée SSH sur la VM​

Le client SSH de la VM a besoin de votre clé privée. Parce que vous aurez probablement aussi besoin de votre clef publique dans le futur, copiez les deux manuellement via l'Explorateur (allez dans votre home Linux sous \\wsl$\ et copiez ~/.ssh/id_ed25519 vers C:\Users\vm-user\.ssh\), ou lancez ce one-liner dans une session Powershell qui a accès à WSL :

$ wsl sh -c 'cp "$HOME/.ssh/id_ed25519.pub" "/mnt/c/Users/$(cmd.exe /c echo %USERNAME% | tr -d "\r")/.ssh/id_ed25519.pub"'
$ wsl sh -c 'cp "$HOME/.ssh/id_ed25519" "/mnt/c/Users/$(cmd.exe /c echo %USERNAME% | tr -d "\r")/.ssh/id_ed25519"'

Tester la connexion depuis la VM​

Depuis Powershell sur la VM, vérifiez que l'alias se résout et que l'authentification passe :

PS C:\Users\vm-user\.ssh> ssh linux-test
No updates available to install

Last update check: 2026-09-04 00:00:01
Last login: Thu Sep  3 17:41:10 2026 from 10.x.x.x

[dev-user@linux-server-01 ~]$ whoami
dev-user

[dev-user@linux-server-01 ~]$ pwd
/home/dev-user

[dev-user@linux-server-01 ~]$ exit
logout
Connection to test.example.internal closed.
PS C:\Users\vm-user\.ssh>

Se connecter avec VSCode​

SSH est maintenant configuré et la commande de test a renvoyé votre nom d'utilisateur — la connexion fonctionne de bout en bout. Que vous ayez suivi l'approche recommandée ou celle de repli, vous êtes au même point : prêt à ouvrir VSCode et à vous connecter au serveur Linux.

Donc, côté Windows, ouvrez une console Powershell et installez l'extension Remote - SSH — c'est elle qui fournit la barre latérale Remote Explorer utilisée pour se connecter à l'host distant :

$ code --install-extension ms-vscode-remote.remote-ssh
Installing extension 'ms-vscode-remote.remote-ssh'...
Extension 'ms-vscode-remote.remote-ssh' v0.120.0 was successfully installed.

$ code --list-extensions | grep remote-ssh
ms-vscode-remote.remote-ssh

$ code --list-extensions | grep remote-ssh

Ouvrez VSCode — sur votre portable si vous avez suivi l'approche recommandée, ou sur la VM Windows si vous avez suivi l'approche de repli. Dans la barre latérale Remote Explorer, sélectionnez Remotes (Tunnels/SSH) dans la liste déroulante.

Utilisateurs WSL : encore une fois, parce que c'est important : passez par le menu Démarrer de Windows et lancez VSCode depuis là.

Repérez linux-test dans la liste et cliquez sur l'icône flèche à côté pour l'ouvrir dans une nouvelle fenêtre.

VSCode déploie un petit binaire serveur sur l'host Linux la première fois — surveillez la barre d'état en bas à gauche pour le message Opening Remote.... Dès que le nom de l'host y apparaît, vous êtes connecté.

Vérifier la connexion​

Ouvrez un terminal dans VSCode (Terminal → New Terminal) et lancez :

$ hostname
test.example.internal▋

Le nom d'hôte correspond au serveur Linux — le terminal tourne sur la machine distante, pas sur votre portable.

C'est ce contexte réseau qui rend la suite possible. Les services invisibles depuis votre portable mais joignables depuis le serveur sont désormais accessibles depuis ce terminal. Si votre projet se connecte à un serveur SFTP, essayez tout de suite :

$ sftp -i ~/.ssh/id_ed25519 -P 22 user@sftp.example.internal
Connected to sftp.example.internal.
sftp>

Vous êtes sur un prompt sftp> depuis un terminal à l'intérieur de VSCode sur votre portable — le réseau du serveur Linux fait le routage, de façon invisible.

Ouvrir le DevContainer​

Une fois connecté à l'host distant, installez l'extension Dev Containers pour ouvrir le projet dans un container qui tourne sur cet host :

$ code --install-extension ms-vscode-remote.remote-containers
Installing extension 'ms-vscode-remote.remote-containers'...
Extension 'ms-vscode-remote.remote-containers' v0.395.0 was successfully installed.

$ code --list-extensions | grep remote-containers
ms-vscode-remote.remote-containers

Ouvrez le dossier du projet sur le serveur Linux, puis appuyez sur F1 et lancez Dev Containers: Rebuild and Reopen in Container la première fois (ou Reopen in Container lors des connexions suivantes).

Une fois le container démarré, votre prompt change pour refléter l'environnement du container. À partir de là, le serveur SFTP et l'API sécurisée sont joignables — les deux services invisibles depuis votre portable sont maintenant sur le réseau local du container.

Sous le capot (à sauter si vous voulez juste l'utiliser)​

Remote - SSH installe un processus vscode-server sur l'host Linux à la première connexion, réutilisé ensuite. Ce serveur gère toute la communication de l'éditeur — lecture de fichiers, I/O du terminal, language server protocol — à travers le tunnel SSH.

Dev Containers dialogue ensuite avec la socket Docker de cet host distant. Il lit devcontainer.json, construit ou récupère l'image, et démarre le container. VSCode rebranche son protocole d'éditeur sur le runtime du container, en laissant le layer SSH intact en dessous. Résultat : deux connexions imbriquées : tunnel SSH → VS Code Server sur l'host → runtime du container.

Avec l'approche recommandée, il y a un troisième niveau : le tunnel SSH lui-même passe par la VM via ProxyJump. Le VS Code Server n'en sait rien — il sait seulement qu'il tourne sur l'host Linux. Le ProxyJump se joue entièrement au niveau SSH.

Les bind mounts du container référencent des chemins sur le serveur Linux, pas des chemins de votre portable ou de la VM — et c'est exactement ce qu'on veut.

ssh -J vm-user@windows-vm-ip dev-user@test.example.internal "whoami && hostname"

ssh -J vm-user@windows-vm-ip dev-user@test.example.internal

Bonus - one-liners ssh -J​

Toutes les commandes ci-dessous fonctionnent depuis n'importe quelle machine sans toucher à ~/.ssh/config — la chaîne complète est encodée dans le flag -J.

Vérification rapide — exécute une commande et quitte :

ssh -J vm-user@windows-vm-ip dev-user@test.example.internal "whoami && hostname"

Shell interactif sur le serveur Linux :

ssh -J vm-user@windows-vm-ip dev-user@test.example.internal

Pour les sessions interactives qui lancent un programme précis, ajoutez -t afin d'allouer un pseudo-terminal. Sans lui, le programme distant démarre mais n'affiche aucun prompt — la session semble figée, alors qu'elle attend silencieusement une entrée.

Session SFTP sur un serveur uniquement joignable depuis l'host Linux :

ssh -t -J vm-user@windows-vm-ip dev-user@test.example.internal sftp -i ~/.ssh/id_ed25519 user@sftp.example.internal

Session PostgreSQL sur une base uniquement joignable depuis l'host Linux :

ssh -t -J vm-user@windows-vm-ip dev-user@test.example.internal psql -h db.example.internal -U postgres

Port forwarding — utilisez n'importe quel outil graphique depuis votre portable :

Pour les clients graphiques Windows (HeidiSQL, DBeaver, TablePlus…) qui ne peuvent pas passer directement par SSH, le port forwarding est la réponse. Il expose le port distant comme localhost sur votre machine — l'outil graphique ne sait pas qu'il traverse deux sauts SSH :

ssh -fNL 5432:db.example.internal:5432 -J vm-user@windows-vm-ip dev-user@test.example.internal

Connectez ensuite HeidiSQL (ou n'importe quel client) à Host: localhost, Port: 5432. Le tunnel tourne silencieusement en arrière-plan (-f) sans commande distante (-N). Tuez le processus ssh quand vous avez fini.

Conclusion​

La combinaison de VSCode Remote SSH et Dev Containers résout un problème qui demande sinon un workflow manuel pénible en plusieurs étapes : développer du code qui doit tourner — ou atteindre des services qui n'existent que — sur un serveur que votre portable ne peut pas joindre directement.

L'approche recommandée (ProxyJump) est la plus propre : une fois la configuration SSH en place, la connexion se fait en un clic et la VM Windows devient une infrastructure invisible. L'approche de repli est l'alternative fiable quand le serveur SSH de la VM n'est pas disponible.

Développement distant en SSH avec VSCode est l'article compagnon si vous voulez partir d'un cas plus simple — éditer des fichiers sur un host distant sans devcontainer, avec un container Docker local comme terrain d'entraînement sûr avant de toucher à un vrai serveur.