Runpod: como configurar SSH completo para SCP e IDEs em pods com GPU

As plataformas de GPU na nuvem vendem, antes de tudo, poder de computação, mas o dia a dia do engenheiro esbarra em detalhes: como enviar um dataset de 50 GB, como abrir o projeto na IDE de costume, como redirecionar uma porta até o Jupyter. A Runpod publicou em seu blog um guia que resolve justamente essa camada. O tema é a configuração de um daemon SSH completo no pod, depois da qual passam a funcionar o SCP e a conexão de editores de código.

O material de origem que temos em mãos é curto. Por isso, abaixo nos baseamos no que ele afirma e no esquema geral, conhecido, de funcionamento do SSH na Runpod. Os itens específicos da interface e os parâmetros dos templates devem ser conferidos na documentação atual da plataforma.

Duas formas de entrar no pod

A Runpod tem dois modos de SSH. O primeiro funciona pelo proxy da plataforma. Sua vantagem é não exigir nenhuma configuração: você recebe um terminal interativo. Mas é só isso, um terminal. SCP, SFTP e desenvolvimento remoto em IDE não funcionam por essa conexão, porque do outro lado não há um servidor SSH completo que entenda esses protocolos.

O segundo modo é o SSH "de verdade". O sshd roda dentro do contêiner, e a porta 22 é exposta como uma porta TCP com IP público. O cliente se conecta diretamente, como a um VPS comum. É esse cenário que o tutorial detalha.

O que é preciso para configurar

O esquema é padrão para qualquer host remoto com autenticação por chave. A ordem geral é esta:

• escolher um template (imagem) em que o servidor OpenSSH esteja instalado e seja iniciado;
• adicionar sua chave pública às configurações da conta ou às variáveis de ambiente do pod;
• garantir que o pod esteja em um host com IP público e com a porta TCP 22 aberta;
• conectar com um comando como `ssh root@<IP> -p <porta externa> -i ~/.ssh/chave`;
• para copiar arquivos, usar `scp -P <porta>` ou um cliente SFTP.

Um detalhe à parte: a porta externa que o cliente enxerga normalmente não é a 22. A plataforma a exibe no card do pod, e é ela que deve ser informada na conexão. Um erro típico de iniciantes é tentar acessar a porta padrão.

Por que isso importa para engenheiros

O maior ganho está na IDE. O VS Code e o JetBrains trabalham por SSH: o código fica na máquina remota com GPU, enquanto o editor, o depurador e o terminal rodam localmente. Para quem faz fine-tuning de um modelo ou depura inferência, isso elimina a necessidade de manter o código em um Jupyter no navegador ou de copiar arquivos manualmente.

O segundo ganho é a transferência de dados. Cenários com SCP e similares ao rsync permitem recolher checkpoints e logs do pod com rapidez antes de desligá-lo. Quando o aluguel é cobrado por tempo, os minutos extras gastos para exportar artefatos viram dinheiro.

O terceiro é o redirecionamento de portas. Por um túnel SSH, é possível abrir localmente, com segurança, o TensorBoard, a interface web de um servidor de inferência ou o Jupyter, sem publicá-los na internet.

Na prática: pontos de atenção

Antes de iniciar um trabalho longo, verifique algumas coisas. Primeiro, guarde as chaves com cuidado: use um par de chaves exclusivo para a nuvem, com senha (passphrase) e login por senha desativado. IP público significa que o sshd será escaneado por bots poucos minutos depois de o pod subir.

Segundo, lembre-se de que o contêiner é efêmero. As configurações do sshd e as chaves adicionadas manualmente dentro do pod podem não sobreviver à recriação. É mais seguro incorporá-las a um template próprio ou a um script de inicialização.

Terceiro, grave tudo o que for importante em um volume persistente, e não no sistema de arquivos do contêiner. O SSH facilita o acesso, mas não muda as regras de armazenamento de dados da plataforma.

Por fim: se você precisa apenas de um terminal rápido para conferir logs, o modo proxy basta. O SSH de verdade faz sentido quando você trabalha com o pod por horas: editando código, rodando experimentos e transferindo arquivos com frequência.