В этом материале
Текст ошибки показывает следующий уровень проверки: транспорт, сервер и аутентификацию нужно диагностировать последовательно.
Если SSH в Runpod не работает, сначала сохраните точный текст ошибки и проверьте актуальную команду Connect. Connection timed out, Connection refused и Permission denied указывают на разные этапы соединения. Замена ключа без понимания этапа часто ничего не меняет.
Проверьте ресурс и выбранный режим
Pod должен завершить запуск, а необходимый сервис — работать внутри контейнера. Руководство подключения SSH различает базовый прокси и прямой TCP. Уточните, какую команду вы используете и что хотите сделать: открыть терминал, передать файлы или подключить инструмент разработки.
Сверьте ID Pod и параметры из текущей панели. После пересоздания нельзя рассчитывать на прежний адрес и внешний порт. Если используете сохранённый профиль SSH, временно сравните его с полной командой Connect: ошибка может находиться в старой записи, а не на стороне нового окружения.
Разделите ошибки по уровням
| Наблюдение | Что проверить первым |
|---|---|
| Соединение долго ждёт ответа | Маршрут, адрес, внешний порт и готовность ресурса |
| Сервер сразу отказывает | Прослушивается ли порт и запущен ли SSH-сервер |
| Permission denied | Имя пользователя, выбранный приватный ключ и публичную пару |
| Терминал работает, SFTP не работает | Поддерживает ли выбранный путь полноценный SSH |
Это порядок диагностики, а не однозначное объяснение каждого случая. Корпоративная сеть, клиентская конфигурация и собственный контейнер могут добавлять ограничения. Меняйте один параметр за попытку и фиксируйте результат.
Сверьте ключ без раскрытия секрета
Проверьте, что в Credentials добавлена вся публичная строка, а не отпечаток. На локальной машине команда должна выбирать соответствующий приватный файл. Если SSH-agent предлагает много других ключей, явно укажите нужный путь и изучите диагностический вывод клиента.
Запрос пароля не следует трактовать как приглашение придумать пароль от контейнера. В первую очередь проверьте настройку ключевой аутентификации. При передаче лога коллеге удалите токены и другие секреты; содержимое приватного файла для диагностики не требуется.
Убедитесь, что открыт правильный порт
Для прямого доступа нужен внешний TCP-порт, сопоставленный внутреннему SSH-порту. Документация портов Runpod объясняет это отображение. Открытие порта не запускает sshd, а работа сервиса на другом внутреннем порту не меняет команду клиента автоматически.
Практический пример: собственный образ успешно выполняет вычисления, но не содержит настроенного SSH-сервера. В такой ситуации публичный ключ уже верен, а проблема находится в составе образа. Сравнение с официальным шаблоном помогает проверить гипотезу, однако результаты и конфигурацию сохраняют до замены окружения.
Для собственного образа полезно сохранить отдельно минимальную проверенную конфигурацию доступа. Она должна объяснять, как запускается SSH-сервер и где проверять его журнал. Тогда следующая ошибка после обновления образа будет сравниваться с известным рабочим состоянием, а не со случайно оставшейся открытой сессией прошлого эксперимента.
Подготовьте проверяемый отчёт
Для обращения в поддержку соберите ID Pod, время попытки, выбранный режим, текст ошибки и результаты предыдущих шагов. Добавьте сведения о клиентской сети и том, воспроизводится ли ошибка с другой разрешённой машины. Не публикуйте команду с секретами и не отключайте все проверки доступа ради одного теста.
Настройка ключей разобрана в отдельной инструкции, а безопасный локальный доступ — в материале о туннеле. Это поможет заранее обсудить восстановление доступа и ответственность за машину.