- Что такое SSH и как работает протокол
- Почему SSH используется в продакшн-среде
- Основные способы подключения к серверу
- Аутентификация по паролю и по ключам
- Настройка SSH-ключей
- Ограничение доступа по IP
- Отключение root-доступа
- Изменение стандартного порта SSH
- Логирование подключений
- Типичные ошибки при настройке SSH
- Рекомендации по безопасному администрированию серверов
- Итоги
Неправильно настроенный SSH в production‑среде – это прямая угроза безопасности инфраструктуры. Открытый порт 22, аутентификация по паролю, неограниченный доступ – типичные уязвимости, которыми охотно пользуются злоумышленники.
Чтобы минимизировать риски, недостаточно полагаться на настройки по умолчанию. В статье разберем практические шаги по настройке SSH.
Что такое SSH и как работает протокол
SSH (Secure Shell) — это безопасный способ удалённо подключиться к серверу, даже через ненадёжную сеть. Он заменил небезопасный Telnet, в котором данные передавались почти без защиты.
По архитектуре SSH состоит из трех уровней: транспортного, уровня аутентификации пользователя и уровня соединения. Транспортный уровень отвечает за шифрование, целостность и проверку сервера; уровень аутентификации проверяет пользователя; уровень соединения позволяет запускать shell-сессии, передавать файлы и использовать туннелирование.
На практике работа выглядит так:
- Клиент подключается к серверу.
- Стороны согласуют криптографические алгоритмы.
- Сервер подтверждает свою подлинность host key.
- Затем пользователь проходит аутентификацию – например, паролем или SSH-ключом.
- После этого открывается защищенная сессия, через которую администратор выполняет команды, копирует файлы или настраивает туннели.
Для production-проектов, где нужен полный контроль над окружением, подойдут виртуальные серверы от Spaceweb. Администратор получает доступ к системе через SSH и может самостоятельно управлять сервером: настраивать службы, разворачивать приложения, обновлять ПО, ограничивать доступ по ключам и IP, контролировать пользователей и безопасность инфраструктуры. Это удобно для сайтов, backend-сервисов, тестовых стендов и рабочих приложений, которым требуется надежная серверная среда.
Почему SSH используется в продакшн-среде
В production SSH нужен для управляемого и защищенного доступа к серверам. Через него администраторы обновляют систему, анализируют логи, перезапускают сервисы, разворачивают приложения, настраивают конфигурации и устраняют аварии.
Основная ценность SSH – сочетание шифрования, проверки подлинности и гибкого контроля доступа. Для продакшн-среды это критично: серверы часто доступны из внешних сетей, а удаленный доступ должен быть не только удобным, но и контролируемым. NIST в рекомендациях по удаленному доступу отдельно подчеркивает необходимость документировать требования к таким подключениям, использовать криптографическую защиту и контролировать удаленные методы доступа.
Основные способы подключения к серверу
Подключиться к серверу по SSH можно несколькими способами. Самый простой вариант – войти по имени пользователя и IP-адресу сервера:
Если сервер использует доменное имя, вместо IP можно указать домен:
При нестандартном порте подключение выполняется с параметром -p:
Для подключения по конкретному SSH-ключу используется параметр -i:
Чтобы не вводить параметры каждый раз, можно добавить настройки в файл ~/.ssh/config:
HostName 203.0.113.10
User deploy
Port 2222
IdentityFile ~/.ssh/id_ed25519
После этого подключение будет короче:
В production-среде часто используют промежуточный сервер – бастион-хост или инсталляционный сервер. Администратор сначала подключается к нему, а уже через него получает доступ к внутренним серверам, которые не открыты напрямую в интернет:
Для передачи файлов применяют scp, sftp или rsync поверх SSH. Например:
В продакшене лучше не открывать SSH-доступ для всех адресов. Безопаснее подключаться через VPN, бастион-хост, firewall-правила или allowlist доверенных IP. Это снизит количество случайных сканирований и ограничит круг тех, кто вообще может обратиться к SSH-порту.
Аутентификация по паролю и по ключам
Аутентификация по паролю – это достаточно привычный способ: пользователь просто вводит логин и пароль. Но у нее есть и минусы – риск перебора, утечки пароля и повторного использования одного пароля в разных системах. В OpenSSH параметр PasswordAuthentication отвечает за разрешение входа по паролю. По умолчанию он может быть включен, поэтому настройку важно целенаправленно проверять.
Аутентификация по ключам надежнее для продакшна. У пользователя есть приватный ключ, который хранится локально, и публичный ключ, добавленный на сервер. Сервер проверяет, что клиент владеет приватным ключом, не передавая сам ключ по сети. В OpenSSH публичные ключи обычно хранятся в ~/.ssh/authorized_keys, а параметр PubkeyAuthentication отвечает за разрешение входа по ключам.
Настройка SSH-ключей
Создать ключ можно следующим образом:
Чтобы создать ключ в OpenSSH, используйте команду ssh-keygen. Без дополнительных параметров она сгенерирует ключ типа Ed25519 (это стандарт по умолчанию). Обязательно задайте passphrase для приватного ключа — это защитит его: даже если файл окажется у злоумышленника, без фразы доступа он не сможет им воспользоваться.
Публичный ключ нужно добавить на сервер:
Или вручную скопировать содержимое .pub-файла в:
Права должны быть строгими:
chmod 600 ~/.ssh/authorized_keys
Проверив вход по ключу, вы можете отключить парольную аутентификацию:
PubkeyAuthentication yes
Но изменения в /etc/ssh/sshd_config лучше проверить до перезапуска:
И только затем перезагрузить SSH-сервис.
Ограничение доступа по IP
Ограничение по IP снижает площадь атаки: к SSH-порту смогут обращаться только доверенные адреса, например офисный VPN, бастион-хост или IP CI/CD-системы.
Пример для UFW:
Чтобы защитить SSH, используйте сетевой экран — например, встроенный firewall облачного провайдера, security groups или локальные инструменты вроде nftables и iptables. Можно также настроить сетевые ACL. В файле sshd_config дополнительно укажите, кто может подключаться, через параметр AllowUsers. Там можно писать как просто имена пользователей, так и в формате USER@HOST (пользователь с определённого адреса). OpenSSH понимает и CIDR‑диапазоны — например, 192.168.1.0/24.
Отключение root-доступа
Прямой вход под root в проду лучше отключить. Вместо этого создайте отдельного пользователя и добавьте его в группу с правом sudo. Так все административные действия будут выполняться через повышение привилегий, а в логах будет видно, кто именно подключался и какие команды выполнял.
В конфигурации SSH обычно используют:
В OpenSSH параметр PermitRootLogin управляет тем, может ли root входить через SSH. Среди допустимых значений есть yes, prohibit-password, forced-commands-only и no; в документации OpenSSH указано, что значение по умолчанию – prohibit-password.
Изменение стандартного порта SSH
По умолчанию SSH-сервер слушает порт 22. Это стандартное поведение OpenSSH, которое задается параметром Port.
Изменить порт можно так:
Смена порта не заменяет ключи, firewall и отключение root-доступа. Она лишь уменьшает количество автоматических сканирований и шум в логах.
Важно сначала открыть новый порт в firewall, проверить конфигурацию командой sshd -t, оставить текущую SSH-сессию открытой и только после успешного тестового входа закрывать старый порт.
Логирование подключений
Логи SSH помогают расследовать инциденты, отслеживать перебор паролей, видеть успешные и неуспешные входы, а также контролировать административную активность. В разных дистрибутивах записи могут попадать в journalctl, /var/log/auth.log или /var/log/secure.
Полезные команды:
journalctl -u sshd
grep sshd /var/log/auth.log
grep sshd /var/log/secure
В OpenSSH параметр LogLevel задает подробность логирования; значение по умолчанию – INFO. Уровни DEBUG, DEBUG2 и DEBUG3 лучше не держать постоянно в продакшене: они нужны для диагностики и могут создавать лишний шум.
Типичные ошибки при настройке SSH
Ошибки в настройке SSH часто проявляются не сразу: сервер может продолжать работать, но доступ к нему становится либо небезопасным, либо нестабильным. В production-среде важно проверять изменения до перезапуска службы и не отключать резервные способы доступа, пока новая конфигурация не протестирована.
| Ошибка | Чем опасна | Как исправить |
| Отключили парольный вход до проверки ключей | Администратор может потерять доступ к серверу, если ключ добавлен неверно или указан не тот пользователь | Сначала проверить вход по ключу в новой SSH-сессии, затем отключать PasswordAuthentication |
| Неправильные права на .ssh и authorized_keys | SSH может игнорировать ключи, даже если они добавлены правильно | Установить права: chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys |
| Оставлен вход под root | Злоумышленнику проще атаковать сервер: имя пользователя уже известно | Создать отдельного пользователя с sudo, а в конфигурации указать PermitRootLogin no |
| SSH открыт для всех IP-адресов | Сервер постоянно получает автоматические попытки перебора и сканирования | Ограничить доступ через firewall, security groups, VPN или bastion host |
| Используется парольная аутентификация | Пароль можно подобрать, украсть или случайно использовать повторно на другом сервисе | Перейти на SSH-ключи и отключить вход по паролю |
| Приватный ключ хранится без passphrase | При краже файла ключ можно сразу использовать для входа | Защитить ключ passphrase и хранить его только на доверенных устройствах |
| Один SSH-ключ используется для всех серверов и сотрудников | Сложно понять, кто подключался, и невозможно безопасно отозвать доступ одного человека | Выдавать персональные ключи и регулярно удалять неактуальные из authorized_keys |
| Изменили порт SSH, но не открыли его в firewall | После перезапуска SSH новый порт может оказаться недоступен | Сначала открыть новый порт, затем проверить подключение и только потом закрывать старый |
| Конфигурацию не проверили перед применением | Ошибка в sshd_config может нарушить работу SSH | Перед перезапуском выполнить sudo sshd -t |
| Нет мониторинга и просмотра логов | Неудачные попытки входа, перебор паролей и подозрительная активность остаются незамеченными | Регулярно проверять journalctl, /var/log/auth.log или /var/log/secure |
| Разрешен доступ лишним пользователям | Увеличивается риск компрометации через забытые или слабозащищенные аккаунты | Ограничить список через AllowUsers или группы доступа |
| Нет резервного способа доступа | При ошибке в настройках сервер может стать недоступным | Держать открытой текущую SSH-сессию и иметь доступ к консоли провайдера |
Перед любыми изменениями в SSH лучше действовать по безопасному сценарию: открыть вторую сессию, проверить новую конфигурацию, протестировать вход и только после этого закрывать старые варианты доступа.
Рекомендации по безопасному администрированию серверов
Безопасное администрирование SSH в production строится на простом принципе: доступ должен быть персональным, ограниченным и контролируемым.
Используйте отдельные учетные записи для каждого администратора. Не стоит работать через общий аккаунт: так сложнее понять, кто подключался к серверу и какие действия выполнял.
Для входа лучше использовать SSH-ключи, а парольную аутентификацию отключить после проверки доступа:
- PasswordAuthentication no
- PubkeyAuthentication yes
Приватные ключи храните только на доверенных устройствах и защищайте passphrase. Не пересылайте их в мессенджерах и не используйте один ключ для всех серверов.
Отключите прямой вход под root:
Административные действия лучше выполнять через отдельного пользователя с правами sudo.
Ограничьте доступ к SSH по IP через firewall, security groups, VPN или bastion host. Не оставляйте SSH открытым для всего интернета, если в этом нет необходимости.
Перед изменениями в конфигурации всегда проверяйте настройки:
- sudo sshd -t
Текущую SSH-сессию лучше не закрывать, пока новый вход не протестирован.
Регулярно просматривайте логи подключений:
- journalctl -u ssh
- journalctl -u sshd
Также важно своевременно обновлять систему и OpenSSH, удалять неактуальные ключи из authorized_keys, ограничивать права пользователей и не выдавать полный sudo без необходимости.
Итоги
SSH – это надежный способ удаленно управлять серверами, который широко используется в рабочих инфраструктурах. Чтобы сделать его максимально безопасным, лучше пользоваться ключами вместо паролей, запретить вход под учетной записью root, ограничить подключения по IP‑адресам, не забывать про логирование и всегда проверять настройки перед перезапуском сервиса.
Смена стандартного порта поможет сократить автоматические сканирования, но сама по себе не обеспечит защиту. Настоящая безопасность достигается только за счёт комплексного подхода: грамотной аутентификации, сетевых ограничений, регулярного аудита и ответственного администрирования.