Заборона входу по SSH за паролем та використання сертифікатів

Коли вхід за ключами працює, серверу більше не потрібно приймати паролі через мережу. Це зупиняє всіх, хто намагається підібрати пароль. У цьому розділі ви безпечно вимикаєте вхід за паролем та як користувача root. Нарешті, ви побачите, як сертифікати SSH спрощують керування доступом до багатьох серверів.

Передумови

• Увійти за допомогою ключа працює, див. [[SSH Level 2 - Ноклер іstedet для пароля|SSH Level 2]].
• Ваш користувач має sudo, див. [[Установка сервера Рівень 4 - Підготуйте сервер|Підготовте сервер]].
• Консоль у 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=KLIENT-IP,host=KLIENTNAVN; замініть приклади значень на користувача, адресу клієнта та ім’я клієнта для входу, який ви тестуєте. Проведіть ту саму перевірку трьох налаштувань.

Коли значення будуть правильними, застосуйте зміну:

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):

# Redigerer SSH-konfigurasjon for lab CA (Lab CA configuration editing)
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

Шукайте Принципиали, Дійсні та Підписуючий ЦА. Додайте сертифікат у файл ~/.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 — це principal, -V — термін дії, а -I — ідентифікатор, який відображається у журналах на сервері. Приватний ключ ЦС надає доступ до всіх серверів, яким він довіряють, тому його ніколи не слід зберігати на сервері або передавати іншим.

Якщо щось піде не так

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 відхиляється.
• Ви можете пояснити, чому ви тестували в новому вікні перед закриттям старого.
• Глибше: ви можете пояснити, чому CA є простішою альтернативою для authorized_keys на багатьох серверах.

Джерело: OpenSSH – sshd_config.