Runpod: как настроить полноценный SSH для SCP и IDE на GPU-подах

Облачные GPU-платформы продают прежде всего вычисления, но повседневная работа инженера упирается в мелочи: как залить датасет на 50 ГБ, как открыть проект в привычной IDE, как пробросить порт до Jupyter. Runpod опубликовал в блоге руководство, которое закрывает именно этот слой. Речь о настройке полноценного SSH-демона на поде, после которого работают SCP и подключение редакторов кода.

Исходный материал в нашем распоряжении короткий, поэтому ниже мы опираемся на то, что в нём заявлено, и на общеизвестную схему работы SSH в Runpod. Конкретные пункты интерфейса и параметры шаблонов лучше сверять с актуальной документацией платформы.

Два способа зайти на под

В Runpod есть два режима SSH. Первый работает через прокси платформы. Он удобен тем, что не требует ничего настраивать: вы получаете интерактивный терминал. Но это именно терминал. SCP, SFTP и удалённая разработка в IDE через такое соединение не работают, потому что на другой стороне нет полноценного SSH-сервера, который понимает эти протоколы.

Второй режим — «настоящий» SSH. Внутри контейнера запускается sshd, а порт 22 открывается наружу как TCP-порт с публичным IP. Клиент подключается напрямую, как к обычному VPS. Именно этот сценарий и разбирает туториал.

Что нужно для настройки

Схема стандартна для любого удалённого хоста с ключевой аутентификацией. Общий порядок такой:

• выбрать шаблон (образ), в котором установлен и запускается OpenSSH-сервер;
• добавить свой публичный ключ в настройки аккаунта или в переменные окружения пода;
• убедиться, что под размещён на хосте с публичным IP и открыт TCP-порт 22;
• подключиться командой вида `ssh root@<IP> -p <внешний порт> -i ~/.ssh/ключ`;
• для копирования файлов использовать `scp -P <порт>` или SFTP-клиент.

Отдельный нюанс: внешний порт, который видит клиент, обычно не равен 22. Платформа отображает его в карточке пода, и именно его нужно указывать при подключении. Типичная ошибка новичков — пытаться стучаться на стандартный порт.

Зачем это инженерам

Главный выигрыш — IDE. VS Code и JetBrains умеют работать по SSH: код лежит на удалённой машине с GPU, а редактор, отладчик и терминал работают у вас локально. Для разработчика, который дообучает модель или отлаживает инференс, это снимает необходимость держать код в браузерном Jupyter или копировать файлы вручную.

Второй выигрыш — передача данных. SCP и rsync-подобные сценарии позволяют быстро забирать чекпоинты и логи с пода до его остановки. Когда аренда считается по времени, лишние минуты на выгрузку артефактов превращаются в деньги.

Третий — проброс портов. Через SSH-туннель можно безопасно открыть локально TensorBoard, веб-интерфейс инференс-сервера или Jupyter, не публикуя их в интернет.

Практика: на что обратить внимание

Прежде чем запускать длительную работу, проверьте несколько вещей. Во-первых, храните ключи по-человечески: отдельная пара ключей для облака, парольная фраза, запрет входа по паролю. Публичный IP означает, что sshd будет сканироваться ботами уже через считаные минуты после запуска пода.

Во-вторых, учтите эфемерность контейнера. Настройки sshd и ключи, добавленные вручную внутри пода, могут не пережить пересоздание. Надёжнее зашить их в собственный шаблон или стартовый скрипт.

В-третьих, пишите всё важное на постоянный том, а не в файловую систему контейнера. SSH упрощает доступ, но не меняет правил хранения данных на платформе.

И последнее: если вам нужен только быстрый терминал для проверки логов, прокси-режима достаточно. Настоящий SSH имеет смысл, когда вы работаете с под часами: правите код, гоняете эксперименты и регулярно переносите файлы.