# Runpod SSH key: как подготовить ключ и выбрать способ подключения

Как добавить публичный SSH-ключ в Runpod, найти актуальную команду подключения и отличить базовый доступ от прямого TCP для SCP и SFTP.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/runpod-ssh-public-key-setup/
Language: ru

Для SSH в Runpod добавьте публичную часть ключа в Credentials и используйте команду из Connect у нужного Pod. Приватная часть остаётся на вашем компьютере. Перед подключением определите режим доступа: базовый SSH через прокси и полноценное соединение по открытому TCP имеют разные возможности.

## Подготовьте пару ключей

[Официальная инструкция SSH](https://docs.runpod.io/pods/configuration/use-ssh) описывает настройку ключей и оба пути соединения. В облако копируют строку из файла с окончанием `.pub`, например начинающуюся с `ssh-ed25519`. Отпечаток вида `SHA256:...` не заменяет публичный ключ.

Создавайте отдельный ключ для рабочей машины или участника команды. Понятное имя и комментарий упрощают отзыв доступа. Если пара уже используется, сначала проверьте, какой файл является публичным, а какой приватным. Нельзя вставлять приватный ключ в форму, startup-скрипт или переписку ради ускорения настройки.

## Выберите подходящий способ SSH

Базовое подключение Runpod доступно через проксируемый путь. Оно подходит для терминальной работы, но документация отдельно указывает отсутствие поддержки SCP и SFTP в этом режиме. Для инструментов, которым нужны такие возможности, изучите прямое TCP-подключение.

Полный SSH требует публичного IP, открытого внутреннего порта SSH и работающего сервера `sshd` внутри окружения. Готовый шаблон может настраивать это заранее; собственный образ необходимо проверять. Наличие программы `ssh` на ноутбуке не запускает сервер в контейнере автоматически.

## Возьмите параметры из текущего Pod

Команду подключения копируют из Connect после готовности экземпляра. В прямом режиме внешний порт может отличаться от внутреннего `22`. Для параметра `-p` нужен внешний порт из панели, а для `-i` — путь к приватному ключу на вашем компьютере.

[Описание открытых портов](https://docs.runpod.io/pods/configuration/expose-ports) помогает связать внутренний сервис с внешним адресом. Не переносите команду от старого Pod в новую сессию без сверки. Идентификатор, адрес и назначенный порт относятся к конкретному ресурсу.

## Пример первого подключения исследователя

Сотрудник получил доступ к проекту и хочет загрузить таблицу через SFTP. Он добавляет свой публичный ключ, выбирает Pod с полноценным SSH и проверяет обычный вход в терминал. Только после этого настраивает файловый клиент на тот же адрес и внешний порт.

Если терминал работает лишь через базовый прокси, ошибка SFTP ещё не доказывает неправильность ключа. Нужно проверить выбранный режим. Такой порядок сокращает бесполезную замену ключей и отделяет проблему аутентификации от ограничения транспорта.

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

При первом соединении клиент показывает сведения о сервере. Сверяйте их предусмотренным способом и сохраняйте понятную запись о ресурсе. Предупреждение об изменении идентичности после пересоздания нужно исследовать: оно может объясняться новым экземпляром, но не должно автоматически игнорироваться в любой ситуации.

## Проверьте завершение сессии

После теста закройте ненужные соединения и решите, должен ли ключ оставаться у облачного аккаунта и внутри созданного окружения. Изменение списка ключей в панели и содержимое `authorized_keys` уже работающей системы могут требовать отдельных действий.

При неполадках пригодится [диагностика SSH Runpod](/ru/journal/runpod-ssh-connection-debug/), для локального сервиса — [инструкция туннеля](/ru/journal/runpod-private-port-forward/).