Источник: https://github.com/AnaktaCTF/CTF/blob/main — Misc/SSH.md

Авторизация через SSH: как устроен SSH-сервер, ключи аутентификации и PAM-аутентификация

SSH (Secure Shell) — один из важнейших инструментов для удалённого управления серверами и рабочими станциями. При использовании SSH все данные, передаваемые между клиентом и сервером, шифруются, что защищает от подслушивания и атак «человек посередине». Здесь мы рассмотрим, как именно устроен SSH-сервер, в чём заключается суть ключей аутентификации, а также объясним, какую роль играет PAM-аутентификация в среде SSH.

1. Краткая история и предназначение SSH

Изначально, до появления SSH, многие администраторы использовали Telnet или rsh (remote shell). Основная проблема этих протоколов заключалась в том, что данные, включая пароли, передавались в открытом виде. Это означало, что любой, кто имел доступ к сети, мог потенциально увидеть данные проходящего сеанса.

SSH был создан в 1995 году, его целью было обеспечить надёжный и защищённый способ подключения к удалённому терминалу. Со временем SSH стал стандартом де-факто для безопасного управления Unix-подобными системами, а также часто используется и в Windows-средах (через сторонние программы или встроенный клиент, начиная с Windows 10).

Документация по современному протоколу SSH (версия 2) описана в нескольких RFC, среди которых:

  • RFC 4251 (общее описание архитектуры),
  • RFC 4252 (аутентификация),
  • RFC 4253 (транспортный уровень),
  • RFC 4254 (механизм каналов).

2. Общая архитектура SSH-сервера

Наиболее распространённая реализация SSH — OpenSSH, изначально разработанная проектом OpenBSD. Она включает в себя несколько компонентов, но главным для нас будет серверный демон, обычно называемый sshd. В большинстве современных Linux-дистрибутивов этот демон запускается как системная служба и прослушивает TCP-порт (по умолчанию 22) на предмет входящих соединений.

При запуске SSH-сессии на стороне клиента (например, при вводе команды ssh user@host):

  1. Устанавливается транспортный уровень: клиент и сервер обмениваются приветственными сообщениями, согласовывают версию протокола (в наше время почти всегда SSH-2).
  2. Происходит обмен ключами (Key Exchange, или KEX): стороны договариваются об алгоритме шифрования (часто это варианты на основе Diffie-Hellman или Curve25519), вырабатывается сессионный ключ. Сервер отправляет свой хост-ключ, по которому клиент может удостовериться, что «разговаривает» именно с нужной машиной, а не с подменённым узлом.
  3. Аутентификация: клиент представляет доказательства своей подлинности — это может быть пароль, ключ, либо более сложная схема с привлечением PAM, двухфакторной аутентификации и т. д.
  4. Открываются каналы: после успешного входа внутри зашифрованного сеанса создаётся виртуальный канал, в котором можно запустить интерактивную оболочку (shell), выполнять команды, копировать файлы через SCP/SFTP, организовать туннели и т. д.

3. Ключи аутентификации и их преимущества

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

Как это работает на практике:

  1. Генерация ключа: На локальном компьютере пользователь запускает, к примеру, ssh-keygen -t rsa -b 4096, либо ssh-keygen -t ed25519, в результате чего формируется пара файлов. Приватный ключ (например, id_rsa) крайне важно хранить в секрете. Публичный ключ (например, id\_rsa.pub) можно копировать на сервер.

Генерация ключа

  1. Копирование ключа: В домашней директории пользователя на сервере есть каталог ~/.ssh, где расположен файлauthorized\_keys. Туда добавляется содержимое вашего публичного ключа. Можно сделать это вручную или воспользоваться утилитой ssh-copy-id.

Копирование ключа

  1. Процесс аутентификации: Когда клиент инициирует SSH-подключение, сервер видит, что для учётной записи есть публичный ключ. Он посылает клиенту случайную строку (challenge), зашифрованную публичным ключом пользователя. Если на стороне клиента есть соответствующий приватный ключ, он может расшифровать строку и отправить правильный ответ. Таким образом, сервер убеждается, что пользователь действительно владеет приватным ключом.

Аутентификация

Основное преимущество такого подхода — сложность взлома. Длина SSH-ключа (2048 и более бит) делает перебор практически нереалистичным для современных вычислительных мощностей. Кроме того, по ключу удобно работать в автоматизированных сценариях (деплой, скрипты резервного копирования и т. п.): не требуется интерактивный ввод пароля.

4. Обзор основных настроек SSH-сервера

Файл, в котором задаются основные параметры работы sshd, обычно находится по пути /etc/ssh/sshd\_config. Примеры важных опций:

  • Port: указывает, на каком TCP-порту будет слушать sshd. По умолчанию 22, но многие администраторы меняют его, чтобы снизить количество автоматических попыток взлома.

Port

  • PermitRootLogin: разрешает или запрещает прямой вход под пользователем root. Часто ставят no для повышения безопасности.

PermitRootLogin

  • PubkeyAuthentication и PasswordAuthentication: включают или отключают вход по ключам и паролю соответственно.

PasswordAuthentication
PubkeyAuthentication

  • AuthorizedKeysFile: определяет, где искать публичные ключи пользователей (по умолчанию ~/.ssh/authorized\_keys).

AuthorizedKeysFile

  • KbdInteractiveAuthentication: активирует механизмы, задействующие PAM или иные методы аутентификации.

AuthorizedKeysFile

После изменения параметров в sshd\_config нужно перезапустить службу (например, sudo systemctl restart sshd в системах с systemd). Подробное описание каждой настройки можно найти в документации OpenSSH, а также через команду man sshd\_config.

Дополнительно многие операционные системы ведут логи, связанные с SSH, в файлах вроде /var/log/auth.log или /var/log/secure. Там видны сведения о том, кто когда заходил, были ли попытки неправильного пароля и т. п.

5. Что такое PAM и зачем он нужен?

PAM (Pluggable Authentication Modules) — это модульная система аутентификации в Unix-подобных ОС. Она позволяет гибко настроить, как именно должны проверяться учетные данные пользователя. При работе с SSH PAM открывает путь к дополнительным возможностям:

  1. Аутентификация с помощью пароля: PAM может сверяться с локальными базами паролей (/etc/shadow), LDAP, Kerberos и другими внешними сервисами.
  2. Двухфакторная аутентификация: с помощью PAM-модулей можно подключить проверку одноразовых паролей (TOTP), SMS-коды и др.
  3. Ограничения на время и место: PAM-модули могут не пускать пользователей, если они пытаются войти в неподходящее время суток или с нежелательного IP-адреса.

При входе по SSH, когда пользователь указывает пароль, демон sshd часто делегирует проверку этого пароля системе PAM. То есть sshd говорит: «Пожалуйста, проверь эти учетные данные, а я подожду ответа — пускать или нет?» В результате администратор может тонко регулировать правила доступа, не меняя самого кода OpenSSH, а лишь корректируя конфигурацию PAM.

6. Как работает PAM-аутентификация в SSH

При включенном параметре UsePAM yes в sshd\_config сервер SSH взаимодействует с PAM в соответствии с правилами, определёнными в файлах конфигурации, обычно лежащих в /etc/pam.d/. Там могут находиться строки вида:


auth       required     pam\_sepermit.so

auth       include      password-auth

account    required     pam\_nologin.so

account    include      password-auth

...

Эти строки означают, какие модули нужно запускать для аутентификации (auth), какие для проверки учётной записи (account) и так далее. PAM-модули могут:

  • Проверять пароль в /etc/shadow.
  • Сверяться с внешним сервером (LDAP или RADIUS).
  • Выполнять дополнительный скрипт, например, для записи лога или проверок на предмет блокировки учётной записи.

Благодаря PAM появляется возможность, например, задействовать Google Authenticator (TOTP), не меняя sshd на уровне исходного кода. Достаточно установить соответствующий пакет и прописать нужный PAM-модуль в конфигурации. При очередном входе сервер SSH попросит ввести не только пароль, но и одноразовый код из приложения на смартфоне.

7. Режимы и механизмы аутентификации в SSH

SSH предлагает несколько механизмов проверки личности пользователя:

  1. Парольная аутентификация (PasswordAuthentication). Пользователь вводит пароль, который передаётся на сервер в зашифрованном виде. Сервер, в зависимости от настроек, может проверять пароль локально (через /etc/shadow) или передавать его PAM-модулям для дальнейшей валидации (LDAP, Kerberos, RADIUS и т. д.).
  2. Аутентификация по ключу (PubkeyAuthentication). Более безопасный метод, когда на клиенте хранится приватный ключ, а на сервере — соответствующий публичный ключ (в ~/.ssh/authorized_keys). При подключении сервер шифрует случайные данные публичным ключом и требует у клиента правильный ответ, который может дать только владелец приватного ключа.
  3. Клавиатурно-интерактивная аутентификация (Keyboard-Interactive). Гибкая схема, которая может быть настроена по-разному — от простого ввода пароля (вопрос-ответ) до сложного взаимодействия с PAM (например, двухфакторная аутентификация). Сервер может присылать набор «вопросов», а клиент в интерактивном режиме передаёт «ответы». По сути, этот механизм тоже часто используют для вызова PAM или других дополнительных проверок.
  4. GSSAPI. Используется в корпоративных окружениях и базируется на Kerberos для единого входа (Single Sign-On). Позволяет пользователям, уже прошедшим аутентификацию в домене (Kerberos-реалм), подключаться к серверам без повторного ввода пароля или ключа.
  5. Host-Based Редко используемая в публичных сетях схема, при которой аутентификация идёт не только на уровне учётной записи пользователя, но и проверяется доверие к хосту-клиенту (сравнивается ключ «хоста»). Это может быть полезно в строго контролируемых внутрикорпоративных сетях, но в большинстве случаев популярностью не пользуется.

В современных конфигурациях SSH чаще всего применяют два первых способа (пароль и ключ), а в более продвинутых сценариях добавляют GSSAPI или двухфакторную аутентификацию на базе PAM через механизм keyboard-interactive. Такой набор методов соответствует тому, что описывается в официальных руководствах по SSH и в других источниках, в том числе и по ссылке из вопроса.

Для повышения общей надёжности многие администраторы запрещают использование паролей вовсе (устанавливая PasswordAuthentication no) и разрешают лишь вход по ключам. Это существенно снижает риск брутфорса или угадывания пароля.

8. Практические советы по настройке SSH и PAM

  • Отключайте неиспользуемые способы входа. Если нет необходимости в GSSAPI или каких-то экзотических механизмах, лучше отключить их в sshd\_config. Это сузит потенциальную поверхность атаки.
  • Используйте сильные ключи. Если вы выбираете RSA, берите ключи длиной не менее 2048 или даже 4096 бит. Также популярны Ed25519-ключи, которые короче и обычно считаются безопасными и быстродействующими.
  • Не используйте пароль root. PermitRootLogin no — один из главных постулатов безопасности. Либо разрешайте root-вход только по ключу, если очень нужно.
  • Следите за логами. В файлах /var/log/auth.log, /var/log/secure или эквивалентных видно, какие IP пытались подключаться и какие ошибки при этом возникали.
  • Fail2ban или аналоги. Инструменты вроде Fail2ban анализируют логи и блокируют IP-адреса, пытающиеся многократно подобрать пароль. Это особенно полезно, если парольный вход не отключён полностью.
  • PAM-модули. Если хотите добавить двухфакторную аутентификацию, создайте резервное копирование сеансов или сделать иной нестандартный сценарий, изучите возможности PAM. Достаточно установить нужный модуль и прописать пару строк в конфигурации, чтобы сервер SSH начал запрашивать дополнительные данные.

9. Распространённые заблуждения

  • «SSH полностью неуязвим»: на самом деле любой сервис может содержать уязвимости, если не обновляться или использовать слабые конфигурации (например, слишком короткие ключи, доступ root с простым паролем и т. д.).
  • «Достаточно сменить порт 22»: перенос SSH на непопулярный порт (например, 2222) действительно уменьшает количество автоматических сканирований, но не является полноценной мерой безопасности. Лучше сочетать это с другими подходами — ключами, Fail2ban, запретом root-доступа.
  • «PAM— это только про пароли»: PAM позволяет интегрировать самые разные схемы. Он может проверять биометрию, чиповые карты, токены TOTP и т. д.

Заключение

SSH остаётся одним из важнейших инструментов для удалённого управления. В основе его работы лежат надёжные криптографические механизмы и продуманная архитектура с разделением на транспорт, аутентификацию и каналы для сессий. Демон sshd предоставляет гибкие возможности настройки: можно выбирать разные алгоритмы шифрования, методы подтверждения личности (пароли, ключи, Kerberos и др.), а также подключать модули PAM, которые открывают дополнительный простор для интеграции с внешними сервисами и усиления безопасности.

Чтобы получить максимально безопасную конфигурацию, стоит ориентироваться на ряд принципов:

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

Дополнительную информацию можно найти в официальной документации OpenSSH, а также в локальных руководствах по командам man sshd и man sshd\_config. Если работать с учётом этих рекомендаций, SSH будет оставаться надёжным средством администрирования и защищённого доступа в самых разных сценариях, от локальных сетей до крупных облачных инфраструктур.