Runpod: cómo configurar un SSH completo para SCP e IDE en pods con GPU

Las plataformas de GPU en la nube venden ante todo capacidad de cómputo, pero el trabajo diario de un ingeniero se atasca en los detalles: cómo subir un dataset de 50 GB, cómo abrir el proyecto en su IDE habitual, cómo reenviar un puerto hasta Jupyter. Runpod ha publicado en su blog una guía que cubre justamente esa capa. Explica cómo configurar un demonio SSH completo en el pod, con el que funcionan SCP y la conexión de editores de código.

El material original que tenemos es breve, así que nos basamos en lo que declara y en el esquema generalmente conocido del funcionamiento de SSH en Runpod. Conviene contrastar los apartados concretos de la interfaz y los parámetros de las plantillas con la documentación vigente de la plataforma.

Dos formas de acceder al pod

Runpod ofrece dos modos de SSH. El primero funciona a través del proxy de la plataforma. Su ventaja es que no requiere configurar nada: se obtiene un terminal interactivo. Pero es solo eso, un terminal. SCP, SFTP y el desarrollo remoto en un IDE no funcionan con esta conexión, porque al otro lado no hay un servidor SSH completo que entienda esos protocolos.

El segundo modo es el SSH «real». Dentro del contenedor se ejecuta sshd, y el puerto 22 se expone al exterior como un puerto TCP con IP pública. El cliente se conecta directamente, como a un VPS convencional. Este es el escenario que desarrolla el tutorial.

Qué se necesita para la configuración

El esquema es el estándar de cualquier host remoto con autenticación por clave. El orden general es el siguiente:

• elegir una plantilla (imagen) que tenga instalado y arranque un servidor OpenSSH;
• añadir la clave pública propia en los ajustes de la cuenta o en las variables de entorno del pod;
• comprobar que el pod está alojado en un host con IP pública y que el puerto TCP 22 está abierto;
• conectarse con un comando del tipo `ssh root@<IP> -p <puerto externo> -i ~/.ssh/clave`;
• para copiar archivos, usar `scp -P <puerto>` o un cliente SFTP.

Un matiz aparte: el puerto externo que ve el cliente normalmente no es el 22. La plataforma lo muestra en la ficha del pod, y es el que hay que indicar al conectarse. Un error típico entre los principiantes es intentar conectarse al puerto estándar.

Para qué le sirve esto a un ingeniero

La mayor ventaja es el IDE. VS Code y JetBrains pueden trabajar por SSH: el código está en la máquina remota con GPU, mientras que el editor, el depurador y el terminal funcionan en local. Para quien ajusta un modelo o depura la inferencia, esto elimina la necesidad de mantener el código en un Jupyter dentro del navegador o de copiar archivos a mano.

La segunda ventaja es la transferencia de datos. SCP y los flujos de trabajo tipo rsync permiten recuperar rápidamente checkpoints y logs del pod antes de detenerlo. Cuando el alquiler se factura por tiempo, los minutos extra dedicados a descargar artefactos se convierten en dinero.

La tercera es el reenvío de puertos. Mediante un túnel SSH se puede abrir en local TensorBoard, la interfaz web de un servidor de inferencia o Jupyter de forma segura, sin publicarlos en internet.

En la práctica: a qué prestar atención

Antes de lanzar un trabajo de larga duración, conviene comprobar varias cosas. En primer lugar, guarde las claves con criterio: un par de claves exclusivo para la nube, una frase de contraseña y el inicio de sesión por contraseña desactivado. Una IP pública implica que los bots empezarán a escanear el sshd a los pocos minutos de arrancar el pod.

En segundo lugar, tenga en cuenta que el contenedor es efímero. Los ajustes de sshd y las claves añadidas manualmente dentro del pod pueden no sobrevivir a su recreación. Es más fiable incorporarlos a una plantilla propia o a un script de arranque.

En tercer lugar, escriba todo lo importante en un volumen persistente, no en el sistema de archivos del contenedor. SSH facilita el acceso, pero no cambia las reglas de almacenamiento de datos de la plataforma.

Y una última cosa: si solo necesita un terminal rápido para revisar logs, el modo proxy es suficiente. El SSH real compensa cuando trabaja con el pod durante horas: edita código, lanza experimentos y transfiere archivos con regularidad.