Руководство по порту SSH: безопасный удаленный доступ к серверу

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

После аутентификации SSH может предоставить интерактивную оболочку, выполнить одну удаленную команду, перенаправить порты, скопировать файлы или использовать такие мощные инструменты, как Git, rsync, Ansible и конвейеры развертывания. Именно эта гибкость объясняет, почему SSH важен с эксплуатационной точки зрения и почему его доступность требует тщательной политики.

Откройте SSH, когда администраторам, инструментам автоматизации, заданиям CI/CD, управлению конфигурацией, службам Git или рабочим процессам восстановления необходим удаленный доступ к серверу или устройству. Для серверов публичного облака SSH часто является первым путем управления, используемым перед установкой инструментов более высокого уровня.

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

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

Средство проверки портов может подтвердить, доступен ли TCP 22 извне вашей сети, но не может доказать, что пользователь может безопасно войти в систему. Используйте ssh -vvv, журналы сервера и тесты на уровне учетной записи для проверки доверия ключей хоста, разрешений ключей, политик MFA, доступа к оболочке и правил sudo.

На Windows Server установите и включите сервер OpenSSH, запустите службу sshd и разрешите входящий TCP 22 в брандмауэре Защитника Windows. Серверам Windows, размещенным в облаке, также необходимы соответствующие правила облачного брандмауэра или группы безопасности.

В Linux установите OpenSSH Server, проверьте sshd_config и разрешите TCP 22 через брандмауэр хоста, например ufw, firewalld, nftables или iptables. Облачные экземпляры также требуют, чтобы группа безопасности поставщика разрешила использование одних и тех же исходных сетей.

В macOS включите удаленный вход, если в доверенных сетях требуется SSH. Для доступа к Интернету используйте те же элементы управления, что и на сервере: аутентификация на основе ключей, область видимости брандмауэра, ведение журналов и своевременные обновления.

Начните с проверки внешнего порта по общедоступному имени хоста или IP-адресу и порту 22. Если результат открыт, значит, TCP-путь к SSH доступен. Затем запустите ssh user@example.com или ssh -vvv user@example.com, чтобы проверить ключ хоста, метод аутентификации и настройку сеанса.

На сервере подтвердите прослушиватель с помощью ss -tlnp, netstat или PowerShell. Если задействован облачный сервер, сравните правила брандмауэра хоста с группой облачной безопасности, поскольку любой уровень может блокировать SSH, даже если другой выглядит правильно.

Если порт 22 закрыт, sshd может быть остановлен, установлен на другой порт, привязан только к частному интерфейсу или заблокирован брандмауэром хоста. Если время проверки истекло, пакеты могут быть отброшены группой безопасности облака, правилом NAT маршрутизатора, фильтром интернет-провайдера, политикой VPN или списком разрешенных IP-адресов источника.

Если порт открыт, но вход невозможен, проверьте имя пользователя, разрешения ключа, файл авторизованных_ключей, политику паролей, требования MFA, правила AllowUsers или DenyUsers, настройки входа в систему root и журналы сервера. Многие сбои SSH связаны с проблемами авторизации, а не с портами.

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

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