Настройка безопасного Ssh-доступа к linux-серверам: пошаговое руководство

Безопасный SSH-доступ строится на ключах вместо паролей, запрете прямого входа root, ограничении сетевого доступа и проверке конфигурации до её применения. Настройку SSH сервера Linux выполняйте поэтапно: сначала проверьте вход по ключу и подготовьте резервную сессию, затем меняйте правила sshd и firewall. Так проще избежать блокировки администраторов.

Контрольные ориентиры для защищённого SSH-доступа

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

Определите модель доступа и угрозы для сервера

Эта инструкция подходит для Linux-сервера, которым управляют по SSH через доверенные рабочие станции, VPN или административную сеть. Она полезна при первичной настройке и при усилении уже работающего узла; принципы применимы к администрированию Linux серверов в облаке и локальной инфраструктуре.

Не ограничивайте доступ по IP, если администраторы регулярно подключаются из меняющихся сетей, пока не настроен VPN или другой предсказуемый маршрут. Не отключайте пароли и не меняйте firewall, если у вас нет проверенного ключевого входа, консоли провайдера или другого способа восстановления.

Создайте ключи SSH и защитите их парольной фразой

Понадобятся учётная запись с правом администрирования, доступ к серверу и клиент OpenSSH на рабочей станции. Для настройки SSH ключей Linux создайте отдельную пару для администратора; приватный ключ храните на клиенте и не копируйте на сервер.

1. Создайте ключевую пару. На клиенте выполните ssh-keygen -t ed25519 и задайте парольную фразу. Если инфраструктура или клиент не поддерживают Ed25519, выберите совместимый алгоритм согласно политике организации.
2. Установите открытый ключ на сервер. Используйте ssh-copy-id имя_пользователя@адрес_сервера, если утилита доступна. Иначе добавьте содержимое открытого файла ключа в ~/.ssh/authorized_keys нужной учётной записи.
3. Проверьте подключение в новой сессии. Выполните ssh имя_пользователя@адрес_сервера и убедитесь, что вход работает с ключом. Не закрывайте исходную сессию, пока проверка не завершена.

Файл приватного ключа не отправляйте по почте и не добавляйте в репозитории. При подозрении на утечку удалите соответствующий открытый ключ с серверов и создайте новую пару.

Ограничьте вход в sshd: отключите пароли и root-доступ

Перед изменениями убедитесь, что вход по ключу работает, а у администратора есть права на повышение привилегий. Директивы обычно задаются в /etc/ssh/sshd_config или подключаемых файлах каталога /etc/ssh/sshd_config.d/; фактический путь и порядок обработки зависят от конфигурации дистрибутива.

• Изменение настроек может немедленно лишить вас удалённого доступа при ошибке или несовпадении имени учётной записи.
• Firewall провайдера и локальный firewall могут применяться одновременно; правило только в одном месте не гарантирует доступность SSH.
• Параметры в подключаемых файлах могут переопределять ожидаемые значения в основном конфигурационном файле.
• Не применяйте изменения, пока не проверили вход по ключу в отдельной сессии и не подготовили способ восстановления.

1. Создайте обычную административную учётную запись. Выдайте ей только необходимые права через используемый в дистрибутиве механизм, например группу sudo или wheel. Проверьте повышение привилегий до ограничения root-входа.
2. Настройте параметры sshd. В применяемом конфигурационном файле задайте значения:
   • PubkeyAuthentication yes
   • PasswordAuthentication no
   • KbdInteractiveAuthentication no
   • PermitRootLogin no

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

3. Проверьте итоговую конфигурацию. Выполните sudo sshd -t. Если команда сообщает об ошибке, не перезапускайте службу: исправьте синтаксис или верните предыдущий файл.
4. Примените изменения и проверьте вход. Перезагрузите конфигурацию способом, принятым в вашей системе, например через sudo systemctl reload ssh или sudo systemctl reload sshd. Оставьте текущую сессию открытой и проверьте новое подключение по ключу.
5. Убедитесь, что ограничения действуют. Проверьте, что вход администратором по ключу работает, а парольная аутентификация и прямой вход root отклоняются. Не проверяйте запрет на единственной доступной сессии.

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

Сузьте сетевую поверхность SSH с помощью firewall и allowlist

Ограничивайте SSH на уровне облачной группы безопасности, сетевого firewall или локального firewall. Вносите правила только после определения адресов, с которых администраторам действительно нужен доступ; для меняющихся адресов рассмотрите VPN или bastion-хост.

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

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

Добавьте второй фактор и управляйте доступом пользователей

Для критичных систем рассмотрите второй фактор через поддерживаемую инфраструктурой схему OpenSSH и PAM либо доступ через VPN или bastion-хост. Сначала проверьте совместимость метода с клиентами, резервные способы входа и процедуру восстановления; настройка второго фактора не должна оставлять сервер без доступного администрирования.

Частые ошибки, которых следует избегать:

• Отключение паролей до проверки входа по ключу в новой сессии.
• Использование одной пары ключей несколькими администраторами вместо отдельных учётных данных.
• Хранение приватного ключа на сервере или без парольной фразы на общей рабочей станции.
• Добавление ключа не той учётной записи или неверные права на каталог ~/.ssh и файл authorized_keys.
• Запрет парольного входа без проверки того, как настроены PAM и второй фактор.
• Ограничение доступа по устаревшему IP-адресу без доступной консоли или VPN.
• Сохранение ключей у пользователей после увольнения или смены их роли.

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

Проверьте конфигурацию и настройте безопасный откат

Прежде чем закрывать текущую сессию, проверьте вход по ключу, применение ограничений и доступность сервера с нужной сети. Для защиты SSH сервера от взлома важны не только параметры sshd, но и актуальные учётные записи, сетевые правила, хранение ключей и возможность восстановления.

1. Сохраните копию конфигурации. Перед редактированием скопируйте изменяемые файлы и запишите, какие сетевые правила были добавлены.
2. Проверьте синтаксис и эффективные параметры. Используйте sshd -t; для просмотра вычисленных параметров можно применить sshd -T, учитывая, что условные блоки конфигурации могут зависеть от пользователя и адреса клиента.
3. Проверьте результат из независимой сессии. Подключитесь заново с клиентской машины и убедитесь, что вход и необходимые административные действия доступны.
4. Подготовьте откат. Если новая конфигурация нарушила доступ, восстановите копию через активную сессию или консоль провайдера, затем проверьте файл командой sshd -t и повторно примените настройки.

В зависимости от инфраструктуры подходят следующие варианты:

• Прямой доступ с allowlist. Уместен, если у администраторов есть стабильные внешние адреса и правила можно проверить вне сервера.
• VPN. Подходит, когда адреса клиентов меняются, но доступ к серверу требуется только из управляемой частной сети.
• Bastion-хост. Полезен при централизованном контроле доступа к нескольким серверам; его самого необходимо защищать и обслуживать.

Безопасный удаленный доступ к Linux серверу должен включать проверенный маршрут восстановления: консоль провайдера, out-of-band-доступ или заранее протестированное соединение через VPN. Не рассчитывайте на откат, который требует того же недоступного SSH-подключения.

Практические решения для сложных случаев SSH-доступа

Что делать, если после отключения пароля ключ не принимается?

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

Нужно ли менять стандартный порт SSH?

Это не заменяет ключи, ограничения пользователей и firewall. Меняйте порт только при необходимости и одновременно обновляйте правила локального и внешнего firewall, иначе соединение станет недоступным.

Можно ли полностью запретить вход пользователю root?

Да, если проверена отдельная административная учётная запись с необходимыми правами. Установите PermitRootLogin no и проверьте работу нового подключения до закрытия текущей сессии.

Как разрешить SSH только из VPN?

Ограничьте порт SSH адресом или подсетью VPN на всех применяемых уровнях firewall. Сначала проверьте подключение через VPN, а затем включайте ограничение для внешних сетей.

Как безопасно применить изменение sshd удалённо?

Оставьте текущую сессию открытой, сделайте резервную копию файлов, выполните sshd -t и примените настройки. Затем проверьте вход в отдельной сессии, прежде чем закрывать старую.

Как отозвать доступ у бывшего администратора?

Удалите его открытый ключ из всех соответствующих файлов authorized_keys, отключите ненужную учётную запись и проверьте, не применялся ли тот же ключ на других серверах. Если приватный ключ мог быть скомпрометирован, замените его везде.

Что выбрать: VPN или bastion-хост?

VPN удобен, когда доступ к SSH должен идти из частной сети. Bastion-хост подходит для централизованного доступа к нескольким узлам; выбор зависит от архитектуры, контроля пользователей и доступных способов восстановления.

Автор: Денис Соболев.