Runpod : configurer un SSH complet pour SCP et les IDE sur les pods GPU

Les plateformes cloud GPU vendent avant tout de la puissance de calcul, mais le quotidien d'un ingénieur se heurte à des détails : comment envoyer un dataset de 50 Go, comment ouvrir un projet dans son IDE habituelle, comment rediriger un port vers Jupyter. Runpod a publié sur son blog un guide qui traite précisément cette couche. Il s'agit de configurer un démon SSH complet sur le pod, afin de faire fonctionner SCP et la connexion des éditeurs de code.

Le matériel source dont nous disposons est court. Nous nous appuyons donc sur ce qu'il affirme et sur le schéma de fonctionnement de SSH chez Runpod, bien connu. Mieux vaut vérifier les options précises de l'interface et les paramètres des templates dans la documentation à jour de la plateforme.

Deux façons d'accéder à un pod

Runpod propose deux modes SSH. Le premier passe par le proxy de la plateforme. Il a l'avantage de ne rien demander en configuration : vous obtenez un terminal interactif. Mais ce n'est qu'un terminal. SCP, SFTP et le développement à distance dans une IDE ne fonctionnent pas via cette connexion, car il n'y a pas de serveur SSH complet de l'autre côté pour comprendre ces protocoles.

Le second mode est le « vrai » SSH. Un sshd est lancé dans le conteneur, et le port 22 est exposé à l'extérieur comme port TCP avec une IP publique. Le client se connecte directement, comme à un VPS ordinaire. C'est ce scénario que détaille le tutoriel.

Ce qu'il faut pour la configuration

Le schéma est standard pour tout hôte distant avec authentification par clé. Voici l'ordre général :

• choisir un template (image) où un serveur OpenSSH est installé et démarré ;
• ajouter sa clé publique dans les paramètres du compte ou dans les variables d'environnement du pod ;
• vérifier que le pod est hébergé sur une machine avec IP publique et que le port TCP 22 est ouvert ;
• se connecter avec une commande du type `ssh root@<IP> -p <port externe> -i ~/.ssh/clé` ;
• pour copier des fichiers, utiliser `scp -P <port>` ou un client SFTP.

Un point à noter : le port externe que voit le client n'est généralement pas le 22. La plateforme l'affiche dans la fiche du pod, et c'est lui qu'il faut indiquer à la connexion. L'erreur classique des débutants consiste à frapper au port standard.

Pourquoi c'est utile aux ingénieurs

Le principal gain, c'est l'IDE. VS Code et JetBrains savent travailler via SSH : le code reste sur la machine distante équipée d'un GPU, tandis que l'éditeur, le débogueur et le terminal tournent en local chez vous. Pour un développeur qui affine un modèle ou débogue une inférence, plus besoin de garder son code dans un Jupyter dans le navigateur ni de copier les fichiers à la main.

Deuxième gain : le transfert de données. SCP et les scénarios de type rsync permettent de récupérer rapidement checkpoints et logs depuis le pod avant son arrêt. Quand la location est facturée au temps, les minutes perdues à exporter les artefacts se transforment en argent.

Troisième gain : la redirection de ports. Un tunnel SSH permet d'ouvrir en local, en toute sécurité, TensorBoard, l'interface web d'un serveur d'inférence ou Jupyter, sans les publier sur Internet.

En pratique : les points d'attention

Avant de lancer un travail de longue durée, vérifiez quelques points. D'abord, gérez vos clés correctement : une paire de clés dédiée au cloud, une passphrase, la connexion par mot de passe interdite. Avec une IP publique, le sshd sera balayé par des bots quelques minutes seulement après le démarrage du pod.

Ensuite, tenez compte du caractère éphémère du conteneur. Les réglages de sshd et les clés ajoutées à la main à l'intérieur du pod peuvent ne pas survivre à une recréation. Il est plus sûr de les intégrer dans son propre template ou dans un script de démarrage.

Enfin, écrivez tout ce qui compte sur un volume persistant, et non dans le système de fichiers du conteneur. SSH simplifie l'accès, mais ne change pas les règles de stockage des données sur la plateforme.

Et un dernier point : si vous n'avez besoin que d'un terminal rapide pour consulter des logs, le mode proxy suffit. Le vrai SSH se justifie quand vous travaillez des heures sur un pod : vous modifiez le code, vous enchaînez les expériences et vous transférez régulièrement des fichiers.