Как сохранить SSH-доступ при переезде на новый VPS: ключи, пользователи и firewall

Опишите текущую схему входа

Запишите, кто подключается к старому VPS, под каким пользователем, с какого адреса и каким способом подтверждает вход. Уточните, используется ли отдельная учётная запись для автоматизации, sudo, bastion-host, VPN или ограничение по исходным IP. Не переносите приватный ключ в заметки миграции: зафиксируйте только владельца ключа, назначение, дату проверки и способ его безопасного предоставления.

Отдельно проверьте резервный путь через веб-консоль или serial console провайдера. Он нужен на случай ошибки в sshd_config или firewall. Войдите через него заранее и убедитесь, что знаете, где смотреть системные логи. Если резервного доступа нет, согласуйте его с провайдером до изменения сетевых правил.

• Составьте список пользователей и автоматических подключений.
• Проверьте sudo и ограничения входа.
• Подтвердите доступ к консоли провайдера.
• Не копируйте приватные ключи в открытый документ.

Создайте доступ на новом VPS до переноса нагрузки

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

Проверьте фактический конфиг sshd после всех включаемых файлов и параметров панели. Синтаксис можно проверить штатной командой OpenSSH, а применяемые изменения вводить через предусмотренный reload/restart после проверки консольного доступа. Внимательно учитывайте, что конфигурация может собираться из нескольких файлов. Сохраните копию исходной конфигурации перед изменением и не меняйте доступ на старом VPS одновременно с новой системой.

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

Сверьте fingerprint нового сервера

При первом подключении SSH показывает host key fingerprint. Сверьте его по доверенному каналу: панели провайдера, заранее полученной консоли или администратора. Не принимайте новый fingerprint только потому, что старый VPS имел другой адрес. Новый сервер закономерно может иметь собственный host key, а предупреждение о смене ключа также может означать, что вы попали не на тот узел.

Не удаляйте старую запись known_hosts вслепую и не отключайте проверку ключа для всего соединения. Если IP или имя переиспользуется, безопасно обновите только соответствующую запись после проверки. В конфигурации SSH задайте понятный alias для нового хоста и проверьте, какие параметры реально применяются: пользователь, IdentityFile, порт и ProxyJump. Это помогает не перепутать production, staging и старую машину.

• Сверьте fingerprint через независимый доверенный канал.
• Сохраните отдельные записи для старого и нового узла.
• Обновляйте только проверенную запись known_hosts.
• Перепроверьте параметры alias и ProxyJump.

Настройте firewall с сохранением текущего сеанса

Проверьте правила на двух уровнях: сетевой экран в панели VPS и локальный firewall операционной системы. В allowlist добавьте нужный исходящий адрес администратора или VPN, а порт SSH оставьте открытым только по утверждённой схеме доступа. Не сбрасывайте правила и не включайте новые политики удалённо без проверенной консоли и возможности восстановить прежние настройки.

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

• Сверьте облачный и системный firewall.
• Сохраните текущую сессию и откройте вторую для теста.
• Проверяйте доступ после повторного подключения.
• Не расширяйте SSH-доступ на весь интернет без причины.

Перенесите автоматизацию без потери секрета

Проверьте cron, CI/CD, резервные копии и другие процессы, которые подключаются по SSH. Для каждого определите пользователя, ключ, команду, known_hosts и ограничение по источнику. Секреты вводите через целевой секрет-хранилище или защищённый интерфейс, а не вставляйте в командную историю. Если ключ был привязан к старому адресу, протестируйте новый host alias и подтверждение fingerprint до включения расписания.

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

• Инвентаризируйте SSH-подключения автоматизации.
• Проверьте known_hosts и команду отдельно.
• Сначала протестируйте безопасный режим.
• Не запускайте двойное расписание на двух VPS.

Чек-лист переключения и возврата

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

Если вход не работает, используйте консоль провайдера для диагностики пользователя, ключей, прав, службы SSH и сетевых правил. Исправляйте одну причину за раз и не отключайте проверку host key как постоянное решение. После успешного переноса отзовите ненужные ключи, но только после инвентаризации всех процессов, использовавших старую машину.

• Проверьте свежую отдельную SSH-сессию.
• Подтвердите доступ через консоль провайдера.
• Сохраните старый вход до завершения перехода.
• Отзывайте лишние ключи после проверки зависимостей.

Проверьте журнал входов и завершите переход без ослабления защиты

После переключения просмотрите системный журнал SSH на успешные и неуспешные попытки входа. Убедитесь, что новые автоматические подключения идут от ожидаемых пользователей и адресов, а неожиданные попытки не совпали по времени с изменением DNS или firewall. Не публикуйте полные журналы: они могут содержать имена пользователей, адреса и технические детали. Для передачи сведений оставьте только нужный фрагмент и удалите идентификаторы.

Когда новый VPS прошёл приёмку, удалите только те ключи и разрешения, для которых подтверждено отсутствие зависимостей. Сначала проверьте резервное копирование, CI/CD, аварийный вход и задания обслуживания. Затем обновите документацию доступа и хранение fingerprint, чтобы следующий администратор не принял предупреждение SSH за обычную помеху. Проверьте и старый сервер: открытые учётные записи и разрешённые IP не должны оставаться без владельца после окончания миграции.

Если для доступа используется промежуточный сервер, проверьте оба соединения отдельно: клиент до bastion и bastion до нового VPS. Для каждого перехода нужны корректный host key, пользователь и разрешённый порт. Если команда использует SSH agent, подтвердите, что он доступен только там, где это действительно требуется; дополнительную передачу agent forwarding включайте осознанно. Обновите локальный alias после сверки fingerprint, затем попросите второго администратора выполнить независимый вход. Это обнаружит ситуацию, когда рабочая сессия держится только на настройках одного компьютера.

• Сверьте SSH-логи с ожидаемыми подключениями.
• Скрывайте адреса и имена в передаваемых логах.
• Проверьте резервные ключи и автоматизацию.
• Закройте старые разрешения только после инвентаризации.

Частые вопросы

Можно ли оставить тот же SSH-ключ на новом VPS?

Можно, если он хранится и используется безопасно, но новый сервер нужно отдельно проверить, а fingerprint добавить только после доверенной сверки.

Почему SSH вошёл, но после закрытия окна доступа нет?

Старая сессия могла сохраниться после ошибочного изменения firewall или конфигурации. Всегда тестируйте новое соединение отдельно.

Нужно ли копировать known_hosts целиком?

Обычно нет. Проверяйте и переносите только нужные записи, особенно если адрес сервера изменился.

Документация и полезные источники

• OpenBSD manual: ssh client
• OpenBSD manual: SSH client configuration

Материал проверен 12 ноября 2026 года. Условия провайдеров, версии программ и DNS-настройки могут меняться — сверяйте актуальные данные перед выполнением переноса.