Ограничьте вход по SSH и используйте сертификаты

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

Предварительные условия

• Включено вход по ключам, см. SSH Level 2.
• У вашего пользователя есть права sudo, см. Подготовка сервера.
• Консоль в Proxmox открыта. Это запасной вариант на случай блокировки доступа к SSH.

Отключите вход по паролю и под учётной записью root

Служба SSH считывает настройки из файла /etc/ssh/sshd_config и из файлов в каталоге /etc/ssh/sshd_config.d/. Создайте отдельный файл, чтобы легко отслеживать внесённые изменения и при необходимости отменить их:

sudo nano /etc/ssh/sshd_config.d/10-sikker.conf

Введите:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no отключает обычную аутентификацию по паролю. KbdInteractiveAuthentication no также отключает интерактивную аутентификацию с клавиатуры, которая в противном случае может принимать пароль через PAM. PermitRootLogin no полностью запрещает вход под пользователем root.

Для большинства настроек SSH действует первое значение, которое считывает служба. Поэтому ваш файл не всегда автоматически имеет приоритет над другими файлами: расположение директивы Include, предыдущие настройки и возможные блоки Match могут повлиять на результат. Проверьте эффективные значения перед применением изменений.

Проверьте настройки перед их загрузкой:

sudo sshd -t

Если сообщение не появляется, синтаксис корректен. Затем посмотрите, какие значения даёт новая конфигурация:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

Все три должны показывать no. Если вы получаете другие значения, проверьте файл /etc/ssh/sshd_config и файлы, которые он включает, прежде чем продолжать. С помощью правил Match также проверяйте текущее соединение с помощью команды sudo sshd -T -C user=user,addr=CLIENT_IP,host=HOSTNAME, заменив примерные значения на имя пользователя, адрес клиента и имя хоста для тестируемого входа в систему. Выполните ту же проверку трех настроек.

После того как значения станут правильными, перезагрузите изменения:

sudo systemctl reload ssh

Не закрывайте окно, в котором вы вошли в систему. Откройте новое терминальное окно и протестируйте:

ssh debian-vm                 # должен работать
ssh root@SERVER-IP            # должен быть отклонен
ssh -o PubkeyAuthentication=no user@SERVER-IP   # должен быть отклонен, без запроса пароля

Пароль пользователя по-прежнему требуется для sudo. Он вводится на сервере, а не передаётся через сеть.

Углубление: сертификаты SSH

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

С помощью сертификатов орган сертификации (CA) подписывает ваш ключ. Серверы доверяют CA, а не каждому отдельному ключу. Сертификат также содержит:

• principals: имена, для которых действует сертификат, например admin
• срок действия: когда сертификат перестанет действовать

Настройка сервера

Вам нужен публичный ключ от лица, управляющего центром сертификации (например, учителя). Поместите его на сервере:

sudo nano /etc/ssh/lab_user_ca.pub

Определите, какие субъекты имеют право входить как пользователь user:

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Сообщите службе SSH о сертификате центра сертификации (CA):

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u заменяется именем пользователя, под которым выполняется вход в систему. Проверьте и перезагрузите с помощью команд sudo sshd -t и sudo systemctl reload ssh.

Вход с использованием сертификата

Сертификат находится рядом с приватным ключом и заканчивается на -cert.pub. Просмотрите его содержимое:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Ищите Principals, Valid и Signing CA. Поместите сертификат в ~/.ssh/config:

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Теперь вы входите с помощью ssh debian-vm, хотя ваш ключ отсутствует в файле authorized_keys на сервере.

Как ЦС подписывает (для оператора ЦС)

ssh-keygen -t ed25519 -f lab_user_ca                  # создайте ключ CA один раз и храните его в безопасности
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n — это principals (принципалы), -V — срок действия, а -I — идентификатор, отображаемый в журналах сервера. Приватный ключ CA предоставляет доступ ко всем серверам, которые доверяют ему, поэтому он никогда не должен храниться на сервере или передаваться кому-либо.

Если что-то пошло не так

1. Вы заблокированы от доступа: Войдите в консоль Proxmox, удалите файл, который вы создали в /etc/ssh/sshd_config.d/, и выполните sudo systemctl reload ssh.
2. Команда sshd -t возвращает сообщение об ошибке: Сообщение указывает имя файла и номер строки. Исправьте опечатку перед загрузкой конфигурации.
3. Сертификат не принимается: Убедитесь, что principal из сертификата (команда ssh-keygen -L) указан в файле /etc/ssh/auth_principals/user, и что срок действия сертификата еще не истек. На сервере команда sudo journalctl -u ssh -n 20 показывает причину отказа в доступе.

Важные понятия

Проверки

• Команда ssh root@SERVER-IP отклоняется.
• Вход по паролю через SSH отклоняется.
• Вы можете объяснить, почему вы протестировали соединение в новом окне перед закрытием старого.
• Углубление: вы можете объяснить,为什么 использование ЦА проще, чем authorized_keys, на многих серверах.

Источник: OpenSSH – sshd_config.