В этом материале
В облако добавляют публичную часть ключа; способ SSH выбирают по нужным операциям и возможностям конкретного Pod.
Для SSH в Runpod добавьте публичную часть ключа в Credentials и используйте команду из Connect у нужного Pod. Приватная часть остаётся на вашем компьютере. Перед подключением определите режим доступа: базовый SSH через прокси и полноценное соединение по открытому TCP имеют разные возможности.
Подготовьте пару ключей
Официальная инструкция SSH описывает настройку ключей и оба пути соединения. В облако копируют строку из файла с окончанием .pub, например начинающуюся с ssh-ed25519. Отпечаток вида SHA256:... не заменяет публичный ключ.
Создавайте отдельный ключ для рабочей машины или участника команды. Понятное имя и комментарий упрощают отзыв доступа. Если пара уже используется, сначала проверьте, какой файл является публичным, а какой приватным. Нельзя вставлять приватный ключ в форму, startup-скрипт или переписку ради ускорения настройки.
Выберите подходящий способ SSH
Базовое подключение Runpod доступно через проксируемый путь. Оно подходит для терминальной работы, но документация отдельно указывает отсутствие поддержки SCP и SFTP в этом режиме. Для инструментов, которым нужны такие возможности, изучите прямое TCP-подключение.
Полный SSH требует публичного IP, открытого внутреннего порта SSH и работающего сервера sshd внутри окружения. Готовый шаблон может настраивать это заранее; собственный образ необходимо проверять. Наличие программы ssh на ноутбуке не запускает сервер в контейнере автоматически.
Возьмите параметры из текущего Pod
Команду подключения копируют из Connect после готовности экземпляра. В прямом режиме внешний порт может отличаться от внутреннего 22. Для параметра -p нужен внешний порт из панели, а для -i — путь к приватному ключу на вашем компьютере.
Описание открытых портов помогает связать внутренний сервис с внешним адресом. Не переносите команду от старого Pod в новую сессию без сверки. Идентификатор, адрес и назначенный порт относятся к конкретному ресурсу.
Пример первого подключения исследователя
Сотрудник получил доступ к проекту и хочет загрузить таблицу через SFTP. Он добавляет свой публичный ключ, выбирает Pod с полноценным SSH и проверяет обычный вход в терминал. Только после этого настраивает файловый клиент на тот же адрес и внешний порт.
Если терминал работает лишь через базовый прокси, ошибка SFTP ещё не доказывает неправильность ключа. Нужно проверить выбранный режим. Такой порядок сокращает бесполезную замену ключей и отделяет проблему аутентификации от ограничения транспорта.
Сохраните в инструкции команды без секретов: название ключа, путь к локальному файлу, источник адреса и ответственного за доступ. Приватный материал в такую инструкцию не включают даже для удобства следующего участника.
При первом соединении клиент показывает сведения о сервере. Сверяйте их предусмотренным способом и сохраняйте понятную запись о ресурсе. Предупреждение об изменении идентичности после пересоздания нужно исследовать: оно может объясняться новым экземпляром, но не должно автоматически игнорироваться в любой ситуации.
Проверьте завершение сессии
После теста закройте ненужные соединения и решите, должен ли ключ оставаться у облачного аккаунта и внутри созданного окружения. Изменение списка ключей в панели и содержимое authorized_keys уже работающей системы могут требовать отдельных действий.
При неполадках пригодится диагностика SSH Runpod, для локального сервиса — инструкция туннеля.