Yandex Cloud: После настройки группы безопасности не открывается SSH

#Признаки неисправности и область применимости

После изменения правил группы безопасности Yandex Cloud SSH к виртуальной машине перестал отвечать или завершается по тайм-ауту. Исправление начинается с поиска правила именно у сетевого интерфейса ВМ и сравнения внешнего адреса клиента с разрешённым диапазоном.

#Почему это происходит

#Пошаговая диагностика и устранение

1. Не закрывайте последнюю работающую сессиюЕсли SSH ещё открыт на одном компьютере, оставьте его подключённым до конца проверки. При полной потере входа используйте серийную консоль или штатный механизм восстановления доступа, если он доступен в конфигурации ВМ.

1. Узнайте актуальный адрес и статус ВМВ консоли откройте каталог → Compute Cloud → «Виртуальные машины». Убедитесь, что ВМ запущена, а публичный IP в её карточке совпадает с тем, куда вы подключались. Если IP изменился, попробуйте актуальный адрес без изменения правил.

1. Найдите реально применённые группы безопасностиВ карточке ВМ в блоке сети откройте сетевой интерфейс и запишите список привязанных групп. Откройте Virtual Private Cloud → «Группы безопасности» и найдите каждую по идентификатору; похожее название другой группы не означает, что она используется.

1. Проверьте входящий порт и источникПосмотрите правила входящего трафика: протокол TCP, порт 22 либо ваш специально настроенный порт и диапазон IP источника. Узнайте текущий внешний IP своего компьютера через доверенный сервис. Для изменяющегося IP обновите правило на свой новый /32; не открывайте SSH для 0.0.0.0/0 без крайней необходимости.

1. Согласуйте изменения с владельцем сетиПеред сохранением сделайте скриншот прежних правил. Добавьте минимальное разрешающее правило входящего TCP только от доверенного IP к нужному порту. Не удаляйте существующие правила других сервисов и не назначайте целой подсети широкий доступ.

1. Проверьте SSH с клиентского компьютераВ локальном терминале выполните подключение к актуальному адресу; сообщения Permission denied означают, что сеть до SSH уже работает и надо проверять учётную запись/ключ, Connection refused — что порт отвечает отказом, а тайм-аут обычно связан с фильтрацией/маршрутом.
2. Замените имя пользователя и IP

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Замените имя пользователя и IP. Диагностическая команда на вашем компьютере, не требует администратора; -vv показывает отладку без разглашения приватного ключа.

   ssh -vv -o ConnectTimeout=8 user@PUBLIC_IP

1. Проверьте SSH-службу при наличии аварийного доступаЕсли правила верны, зайдите по серийной консоли/восстановлению доступа, проверьте состояние SSH и слушающий порт. На Debian/Ubuntu обычно служба ssh, на других системах может быть sshd. Не меняйте конфигурацию удалённо, пока не проверена возможность входа.
2. Linux внутри ВМ, проверка слушающего порта 22

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Linux внутри ВМ, проверка слушающего порта 22. При нестандартном порте замените число; отсутствие строки требует проверки конфигурации SSH.

   sudo ss -lntp | grep -E ":22[[:space:]]"

1. Верните минимальный набор правилУбедитесь, что доступ появился только с разрешённого IP. Если восстановление не помогло, отмените последнее добавленное правило и вернитесь к снимку прежней конфигурации для разбирательства. Не перезапускайте ВМ ради эксперимента без резервного канала доступа.

#Как проверить, что проблема исправлена

SSH подключается с разрешённого адреса и по прежнему не открывается с посторонних адресов; список групп в карточке интерфейса соответствует проверенным правилам. Для штатной работы пройдите аутентификацию своим ключом.

#Если проблема осталась

Если после настройки сети остаётся Permission denied, проверьте логин, ключ и authorized_keys. Если есть только тайм-аут, исследуйте подсети, маршруты, локальный брандмауэр и рабочий адрес, не снижая защиту всей группы.