Изменили SSH-конфиг, а подключение осталось старым: проверяем ControlMaster

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

Найдите настройки общего соединения

ssh -G app-lab
ssh -v app-lab

В рассчитанной конфигурации ищите controlmaster, controlpath и controlpersist. В подробном выводе реального подключения видно обращение к управляющему сокету и использование существующего master. Быстрый вход сам по себе этого не доказывает, поэтому лучше сохранить конкретный фрагмент журнала.

ControlMaster позволяет нескольким сеансам разделять одно соединение. ControlPersist может оставлять его живым после закрытия исходного терминала. Это удобно для частых операций, но создаёт важное различие: новый сеанс ещё не означает новую проверку ключа пользователя, нового proxyjump или нового сетевого пути.

Проверьте изменения независимым соединением

ssh -o ControlMaster=no -o ControlPath=none -v app-lab

ControlPath со значением none отключает совместное использование управляющего сокета для этой проверки. Теперь клиент должен установить собственный транспорт. Сравните выбранный сервер, предложенный ключ и этапы аутентификации. Команда не завершает старый master, поэтому текущие рабочие сеансы продолжают жить.

Предположим, обычный вход успешен, а независимый получает Permission denied. Это означает, что прежнее соединение маскировало проблему новой аутентификации. Исправлять следует ключ, пользователя или серверное разрешение, а не пытаться «обновить терминал». Успех независимого подключения подтверждает, что новая конфигурация действительно пригодна.

Управляйте master явно

ssh -O check app-lab

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

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

После проверки новой конфигурации можно вернуть обычное использование multiplexing. В runbook добавьте независимый вызов как отдельный этап смены доступа. Тогда успешная старая сессия не будет ошибочно считаться подтверждением нового ключа или маршрута.

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

Проверяйте доступ так, чтобы результат объяснял применённые настройки. В курсе Linux и Bash для DevOps-инженеров есть настройка окружения, доступов и диагностика сервисов. Откройте программу и используйте учебный сервер для проверки изменений без зависимости от уже открытого рабочего сеанса.

Ещё по теме

• После переустановки сервера изменился SSH host key: как обновить доверие
• Внутренняя панель через SSH-туннель: где открывается порт и кто идёт к сервису