Аутентификация и безопасный доступ в Linux: Pмическое руководство по настройке PAM, SSH и sudo для администраторов (2026) | AdminWiki
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Аутентификация и безопасный доступ в Linux: Pмическое руководство по настройке PAM, SSH и sudo для администраторов (2026)

23 апреля 2026 8 мин. чтения

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

Это руководство предоставляет проверенные на практике, готовые конфигурации для Pluggable Authentication Modules (PAM), SSH и sudo. Вы получите пошаговые инструкции по безопасному отключению парольной аутентификации в SSH, настройке политик сложности паролей через PAM и гранулярному делегированию полномочий через sudo. Каждый шаг сопровождается предупреждениями о рисках и командами для отката изменений, что минимизирует вероятность ошибок в рабочей среде.

Инструкции адаптированы для основных семейств дистрибутивов - Debian/Ubuntu и RHEL/AlmaLinux/Rocky Linux - и учитывают особенности версий ПО в 2026 году.

Подготовка и философия безопасности: принцип наименьших привилегий

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

Создание безопасного стенда для тестирования: что делать, если доступ будет потерян

Изменить конфигурацию PAM, SSH или sudo без подготовки - это риск заблокировать себя на сервере. Следуйте этому обязательному плану действий.

  1. Откройте вторую сессию SSH к серверу или подключитесь через физическую или виртуальную консоль (например, через гипервизор).
  2. В этой резервной сессии получите права суперпользователя: sudo su - или sudo -i.
  3. Только после успешного получения root в резервной сессии начинайте вносить изменения в первой, основной сессии.

Для отката изменений создайте резервные копии ключевых файлов перед их редактированием.

cp /etc/pam.d/common-auth /etc/pam.d/common-auth.backup
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
cp /etc/sudoers /etc/sudoers.backup

Если изменения приводят к потере доступа, восстановите оригинальные файлы из резервной сессии:

cp /etc/pam.d/common-auth.backup /etc/pam.d/common-auth
cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
cp /etc/sudoers.backup /etc/sudoers

Проверяйте каждую команду и изменение конфигурации в контексте вашего конкретного дистрибутива и версии ПО.

PAM (Pluggable Authentication Modules): центральный пульт управления доступом

PAM предоставляет единый механизм для управления аутентификацией, авторизацией и управлением сессиями. Все службы - локальный вход, SSH, sudo - используют модули PAM, что позволяет централизовать политики безопасности. Конфигурация хранится в файлах директории /etc/pam.d/.

Стек PAM состоит из модулей, каждый из которых выполняет конкретную функцию. Управление поведением стека определяется параметрами control: required, sufficient, optional. Например, модуль pam_unix.so проверяет пароль по системному файлу /etc/shadow.

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

# /etc/pam.d/common-auth (Debian/Ubuntu пример)
auth    required        pam_unix.so     nullok
auth    optional        pam_permit.so

Для настройки политики сложности паролей используется модуль pam_pwquality (или pam_cracklib в старых системах). Его параметры задаются в /etc/pam.d/common-password или через отдельный файл конфигурации.

password requisite pam_pwquality.so retry=3 minlen=12 difok=3 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1

Двухфакторная аутентификация повышает безопасность. Модуль pam_google_authenticator интегрирует Google Authenticator в процесс входа. После установки пакета libpam-google-authenticator и генерации секрета для пользователя, добавьте строку в common-auth:

auth required pam_google_authenticator.so

Готовые конфигурации PAM для основных дистрибутивов (Debian/Ubuntu vs RHEL/AlmaLinux)

Основные различия между дистрибутивами касаются имен модулей и структуры файлов.

Дистрибутив Модуль для проверки пароля Основные файлы конфигурации Модуль для блокировки учетных записей
Debian/Ubuntu pam_unix.so /etc/pam.d/common-* pam_tally2.so
RHEL/AlmaLinux/Rocky Linux pam_unix.2.so (в составе system-auth) /etc/pam.d/system-auth, /etc/pam.d/password-auth pam_faillock.so

Настройка политики паролей в Debian/Ubuntu выполняется через /etc/pam.d/common-password. В RHEL и его производных политика часто задается в /etc/security/pwquality.conf и затем включается в system-auth через модуль pam_pwquality.

Настройка политики паролей и блокировки учетных записей

Политика паролей определяет требования к их сложности. Ключевые параметры модуля pam_pwquality:

  • minlen=12 - минимальная длина пароля.
  • difok=3 - минимальное количество символов, отличающихся от предыдущего пароля.
  • dcredit=-1, ucredit=-1, lcredit=-1, ocredit=-1 - требуют наличие хотя бы одной цифры, заглавной буквы, строчной буквы и специального символа соответственно.

Автоматическая блокировка учетной записи после нескольких неудачных попыток входа защищает от брутфорса. На RHEL/AlmaLinux используется pam_faillock:

# В /etc/pam.d/system-auth и password-auth
auth required pam_faillock.so preauth silent deny=5 unlock_time=600
auth required pam_faillock.so authfail deny=5 unlock_time=600

На Debian/Ubuntu применяется модуль pam_tally2:

auth required pam_tally2.so deny=5 unlock_time=600 onerr=fail

Для проверки количества неудачных попыток используйте команду pam_tally2 --user username или faillock --user username.

SSH: Полный переход на ключевую аутентификацию и отказ от паролей

Аутентификация по SSH-ключам исключает риск перехвата паролей при brute-force атаках. Переход должен выполняться поэтапно, чтобы избежать блокировки.

Генерация ключевой пары выполняется на клиентской машине. Для новых систем рекомендуется алгоритм Ed25519:

ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519

Для совместимости с старыми системами можно использовать RSA с длиной ключа 4096 бит: ssh-keygen -t rsa -b 4096. Ключ должен защищаться парольной фразой (passphrase), которую можно управлять через ssh-agent.

Правильная настройка прав на файлы предотвращает ошибки аутентификации.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Ключевые параметры файла /etc/ssh/sshd_config для повышения безопасности:

  • PermitRootLogin prohibit-password или no - запрещает вход root по паролю или полностью.
  • PasswordAuthentication no - отключает парольную аутентификацию.
  • PubkeyAuthentication yes - разрешает аутентификацию по ключам.
  • AllowUsers user1 user2 - ограничивает доступ конкретными пользователями.

Перед применением изменений проверьте конфигурацию командой sshd -t. Перезагрузите службу: systemctl reload sshd или systemctl restart sshd.

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

Этот сценарий гарантирует, что вы не потеряете доступ к серверу.

  1. Добавьте свой открытый ключ в файл ~/.ssh/authorized_keys на сервере и убедитесь, что вход по ключу работает: ssh -i ~/.ssh/id_ed25519 user@server.
  2. В файле /etc/ssh/sshd_config установите PasswordAuthentication yes и ChallengeResponseAuthentication no. Перезагрузите sshd: systemctl reload sshd.
  3. Откройте новое подключение по SSH с использованием ключа. Убедитесь, что сессия устанавливается успешно.
  4. Только после подтверждения работы новой сессии измените PasswordAuthentication на no в конфигурации.
  5. Снова перезагрузите службу sshd.
  6. Протестируйте, что вход по паролю теперь отклоняется. Попробуйте подключиться без указания ключа: ssh user@server. Система должна вернуть ошибку.

Дополнительно можно настроить нестандартный порт (например, Port 2222) и ограничить доступ по IP через firewall (iptables/nftables).

Алгоритмы шифрования и безопасность ключей в 2026 году

Выбор алгоритма шифрования влияет на безопасность и производительность.

Алгоритм Ключевые особенности Рекомендация
Ed25519 Короткие ключи (256 бит), высокая скорость, устойчивость к ряду атак. Основной выбор для новых систем и клиентов.
ECDSA (напр., nistp256) Высокая производительность, широкоя поддержка. Альтернатива Ed25519 для совместимости.
RSA Универсальная поддержка, требует длинных ключей (минимум 2048, лучше 4096 бит). Для legacy систем; избегайте ключей меньше 2048 бит.

Конвертация старых ключей RSA в более безопасные форматы возможна через повторную генерацию. Использование парольной фразы для ключа и ее сохранение в ssh-agent (ssh-add ~/.ssh/id_ed25519) повышает защиту без ущерба удобству.

sudo: Тонкая настройка прав и аудит действий

sudo предоставляет механизм делегирования полномочий без раздачи пароля root. Основной файл конфигурации - /etc/sudoers. Его редактирование выполняется только через команду visudo, которая проверяет синтаксис и предотвращает ошибки, блокирующие доступ.

Для добавления новых правил создавайте отдельные файлы в директории /etc/sudoers.d/. Это улучшает управление и снижает риск повреждения основного файла.

Синтаксис правила: User Host=(Runas_User:Runas_Group) Command. Флаг NOPASSWD позволяет выполнять команды без запроса пароля, что удобно для автоматизации, но повышает риск. Флаг SETENV разрешает сохранение переменных среды.

Настройка детального логирования всех команд sudo обеспечивает аудит и помогает в расследовании инцидентов. Добавьте следующие параметры в /etc/sudoers через visudo:

Defaults logfile="/var/log/sudo.log"
Defaults log_input, log_output

Убедитесь, что файл лога существует и имеет правильные права: touch /var/log/sudo.log && chmod 600 /var/log/sudo.log. Для ротации логов настроите logrotate.

Практические примеры правил sudoers для типовых ролей

Готовые шаблоны правил позволяют быстро настроить доступ для конкретных задач.

Для пользователя deploy, который управляет веб-сервером:

# /etc/sudoers.d/deploy
deploy ALL=(root) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl reload nginx

Для группы администраторов admins с полным доступом, но с обязательным логированием и запросом пароля:

# /etc/sudoers.d/admins
%admins ALL=(ALL) ALL

Для пользователя мониторинга zabbix, которому нужен доступ только к чтению логов и проверке состояния:

# /etc/sudoers.d/zabbix
zabbix ALL=(root) NOPASSWD: /bin/cat /var/log/nginx/access.log, /bin/cat /var/log/nginx/error.log, /usr/bin/df -h

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

Настройка полного аудита команд sudo

Логирование ввода и вывода команд sudo создает полную трассировку действий.

Параметр log_input записывает все введенные команды и аргументы. Параметр log_output сохраняет вывод команды (stdout и stderr) в отдельные файлы в директории, указанной в logfile или iolog_dir.

Пример записи в /var/log/sudo.log с включенным log_input:

Apr 23 10:15:00 : deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/systemctl restart nginx

При использовании log_output вывод команды будет сохранен в файле с уникальным идентификатором в указанной директории. Это позволяет воспроизвести сессию для аудита.

Настройка ротации через logrotate предотвращает заполнение диска:

# /etc/logrotate.d/sudo
/var/log/sudo.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
}

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

Итоговая проверка и чек-лист безопасности

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

  1. Настройка PAM: Проверьте политики паролей и блокировки учетных записей. Убедитесь, что файлы /etc/pam.d/common-auth, common-password (или system-auth) соответствуют требованиям.
  2. SSH-ключи: Сгенерированы и размещены на сервере. Права на файлы ~/.ssh/authorized_keys установлены в 600. Парольная аутентификация в sshd_config отключена (PasswordAuthentication no). Проверьте текущие настройки SSH: sshd -T | grep passwordauthentication.
  3. Правила sudo: Созданы в /etc/sudoers.d/. Синтаксис проверен через visudo -c. Логирование настроено и работает.
  4. Общая проверка: Откройте новую SSH сессию с ключом. Попробуйте выполнить команду через sudo согласно новым правилам. Проверьте соответствующие лог-файлы (/var/log/sudo.log, /var/log/auth.log или /var/log/secure).

Таблица рекомендуемых параметров для быстрого копирования:

Компонент Рекомендуемая настройка
SSH Алгоритм ключа Ed25519
Политика паролей PAM minlen=12 difok=3 (минимум один символ каждого типа)
Блокировка учетной записи PAM deny=5 unlock_time=600 (5 попыток, блокировка 10 минут)
Основные опции sudoers Defaults logfile="/var/log/sudo.log" log_input

Команды для проверки текущего состояния:

  • SSH: sshd -T выводит все текущие параметры.
  • sudo: sudo -l показывает права текущего пользователя.
  • PAM блокировка: faillock --user username или pam_tally2 --user username.

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

Поделиться:
Сохранить гайд? В закладки браузера