Configuration d'un tunnel SSH pour JupyterLab
Lorsque vous ne pouvez accéder à un serveur qu'via SSH (port 22) mais que vous souhaitez utiliser JupyterLab qui tourne sur le port 8888, la solution la plus simple et sécurisée est d'établir un transefrt de port local SSH.
Configuration côté serveur (à effectuer une seule fois)
- Générer le fichier de configuraton : ```
jupyter lab --generate-config
Ceci créera un fichier jupyter\_lab\_config.py dans ~/.jupyter. - Définir un mot de passe fixe (plus pratique que le token) : ```
jupyter server password
Suivez les instructions pour saisir votre mot de passe qui sera stocké sous forme de hash. - Lancer JupyterLab en écoute uniquement sur l'interface locale : ```
jupyter lab --no-browser --ip=127.0.0.1 --port=8888
Pour une exécution en arrière-plan, vous pouvez utiliser systemd ou la commande nohup.
Configuration du tunnel SSH côté client
Méthode 1 : Interface graphique avec PuTTY
- Entrez l'adresse IP du serveur et le port 22 dans l'interface principale
- Allez dans le menu : Connection → SSH → Tunnels
- Dans le champ "Source port", entrez
8888(port local) - Dans le champ "Destination", entrez
127.0.0.1:8888 - Sélectionnez "Local" comme type de redirection, puis cliquez sur "Add"
- Retournez à la sestion, sauvegardez et ouvrez la connexion
- Gardez la fenêtre SSH ouverte pendant toute la durée d'utilisation
Méthode 2 : Ligne de commande (PowerShell/CMD)
ssh -L 8888:127.0.0.1:8888 utilisateur@adresse_serveur
Après connexion réussie, ne fermez pas cette fenêtre.
Accès via le navigateur
Ouvrez votre navigateur local et entrez l'adresse :
http://localhost:8888
Saisissez le mot de passe défini précédemment pour accéder à JupyterLab distant.
Dépannage
- Port 8888 déjà utilisé : Modifiez le port local (par exemple 8889) et accédez via localhost:8889
- Connection refusée : Vérifiez que Jupyter écoute bien sur 127.0.0.1:8888 côté serveur
- Déconnexions fréquentes : Dans PuTTY, réglez "Seconds between keepalives" sur 30. En ligne de commande, ajoutez dans ~/.ssh/config : ```
ServerAliveInterval 60
- Utilisation du token : Au lancement, Jupyter affiche une URL avec token, copiez-la dans votre navigateur
Principe des tunnels SSH et différences avec les proxies
Principe des tunnels SSH
Un tunnel SSH (transfert de port SSH) crée un canal de communication chiffré au sein d'une session SSH existante. Il permet de rediriger le trafic d'un port local vers un port distant via une connexion sécurisée.
Flux de données (exemple de transfert local)
- Le navigateur envoie une requête HTTP à 127.0.0.1:8888
- Le client SSH intercepte ce trafic, le chiffre et l'envoie via le port 22
- Le trafic traverse le réseau/pare-feu
- Le serveur SSH reçoit le trafic, le déchiffre
- Le serveur redirige le trafic clair vers 127.0.0.1:8888 (JupyterLab)
- Les réponses suivent le même chemin en sens inverse
Tunnels SSH vs. Proxies : comparaison
| Aspect | Tunnel SSH | Proxy SOCKS/HTTP |
|---|---|---|
| Niveau de fonctionnement | Transport (TCP) | Application |
| Chiffrement | De bout en bout jusqu'au serveur SSH | Client-proxy seulement (dépend du protocole) |
| Transparence applicative | Transparent - l'application pense se connecter en local | Non-transparent - l'application doit supporter les proxies |
| Type de trafic | Tout service TCP | SOCKS: TCP/UDP, HTTP: uniquement HTTP(S) |
| Configuration | Une fois au niveau client | Chaque application doit être configurée |
| Sécurité | Basée sur l'authentification SSH | Nécessite authentification et contrôles séparés |
| Ports typiques | 22 (externe), interne configurable | 1080 (SOCKS), 3128/8080 (HTTP) |
| Multi-destinations | Un tunnel = une redirection de port | SOCKS: une seule connexion pour toutes les destinations |
Conclusion
- Le transfert de port SSH est une fonction intégrée utilisant le port 22 pour rediriger n'importe quel flux TCP
- Le proxy fonctionne au niveau applicatif et nécessite la coopération de l'application cliente
- Pour rediriger un service spécifique comme JupyterLab, le tunnel SSH est la solution la plus simple sans logiciel supplémentaire