SSH-ключі та вимкнення парольної автентифікації: як захистити сервер WordPress

Чому SSH-ключ кращий за пароль

Під час входу за паролем сервер перевіряє введену комбінацію символів. Зловмисник може автоматично надсилати тисячі спроб, використовуючи словники, повторно застосовані паролі або дані з витоків. Складний пароль зменшує ризик, але не усуває сам механізм підбору.

SSH-ключ складається з приватної та публічної частин. Приватний ключ зберігається на вашому комп’ютері, а публічний — у профілі користувача на сервері. Сервер не отримує приватний ключ і перевіряє криптографічний доказ під час підключення. Для додаткового захисту приватний ключ слід обов’язково захистити passphrase.

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

• Ключ має бути індивідуальним для кожного адміністратора.
• Не надсилайте приватний ключ через месенджери, пошту або систему заявок.
• Не використовуйте один ключ на всіх працівників: у такому разі неможливо відкликати доступ лише однієї людини.
• Для серверів зазвичай обирають сучасний тип ключа Ed25519, якщо його підтримують клієнт і сервер.

Створення окремого користувача та SSH-ключа

Не варто виконувати повсякденне адміністрування під root. Створіть звичайний обліковий запис, надайте йому права sudo лише за потреби та спочатку перевірте, що він справді може виконувати необхідні завдання.

Команди нижче виконують на вашому локальному комп’ютері для створення ключа, а потім — на сервері під наявним адміністратором. Назву користувача замініть на власну.

• У Linux або macOS ключ можна створити командою ssh-keygen.
• У Windows аналогічні команди доступні в OpenSSH у PowerShell; також можна використовувати сумісний SSH-клієнт.
• Під час створення задайте passphrase. Вона захищає приватний ключ, якщо файл потрапить до сторонніх.

ssh-keygen -t ed25519 -C "admin@example.com"

# На сервері під root або іншим адміністратором
adduser deploy
usermod -aG sudo deploy

# Передайте публічний ключ користувачу
ssh-copy-id deploy@SERVER_IP

Якщо ssh-copy-id недоступна

Публічний ключ можна додати вручну до файлу ~/.ssh/authorized_keys користувача deploy. Важливо створити каталог із правильними правами та не вставити приватну частину ключа.

• У файл authorized_keys додають рядок із розширенням .pub, а не вміст приватного ключа.
• Для каталогу ~/.ssh зазвичай встановлюють права 700, для authorized_keys — 600.
• Власником файлів має бути сам користувач deploy.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Перевірка підключення до вимкнення паролів

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

Відкрийте друге вікно термінала або окрему сесію й підключіться новим користувачем із використанням ключа. Не закривайте перше підключення, доки не перевірите вхід, sudo та доступ до потрібних файлів.

• Перевірте вхід саме з того комп’ютера або VPN, з якого надалі адмініструватимете сервер.
• Переконайтеся, що SSH-клієнт використовує правильний ключ: ssh -i ~/.ssh/імя_ключа deploy@SERVER_IP.
• Виконайте sudo -v або іншу безпечну команду sudo та перевірте, що права налаштовані правильно.
• Якщо підключення не працює, подивіться детальний журнал клієнта через параметр -v і журнали SSH на сервері.

ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP
sudo -v

# Перевірка конфігурації sshd до перезапуску
sudo sshd -t

Чому не слід одразу закривати стару сесію

Поточна сесія не завжди розривається після помилки в sshd_config. Це може створити хибне відчуття безпеки: після виходу повторний вхід уже буде неможливим. Тримайте старе підключення відкритим до завершення всіх перевірок і майте доступ до консольного керування хостинг-провайдера або резервний канал відновлення.

• Не редагуйте конфігурацію без резервної копії.
• Застосовуйте зміни після перевірки синтаксису.
• Для критичних серверів плануйте роботи у вікно обслуговування.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo sshd -t

Як вимкнути root і парольну автентифікацію

Основні параметри SSH зазвичай розміщені в /etc/ssh/sshd_config, але конкретна система може також підключати фрагменти з каталогу /etc/ssh/sshd_config.d/. Перевірте ефективні налаштування та переконайтеся, що пізніший фрагмент конфігурації не перевизначає ваші параметри.

Після перевірки входу під окремим користувачем додайте або змініть такі директиви. Значення PasswordAuthentication no забороняє саме парольний спосіб входу через SSH.

• PermitRootLogin no — забороняє прямий SSH-вхід під root.
• PasswordAuthentication no — вимикає вхід за паролем.
• PermitEmptyPasswords no — не дозволяє вхід обліковим записам із порожнім паролем.
• AllowUsers deploy — обмежує SSH-доступ указаним користувачем.

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
AllowUsers deploy

Обережно з KbdInteractiveAuthentication

Деякі системи або схеми багатофакторної автентифікації використовують keyboard-interactive замість класичної парольної автентифікації. Не вимикайте KbdInteractiveAuthentication механічно, якщо через нього працює MFA або інший потрібний механізм входу. Спочатку з’ясуйте, який спосіб використовує ваша конфігурація.

• Якщо MFA не використовується і ви хочете повністю прибрати інтерактивний парольний вхід, параметр можна вимкнути після тестування.
• Після змін виконайте sshd -t.
• Перечитайте ефективну конфігурацію, якщо система має багато підключених фрагментів.

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers'

Застосування змін і обмеження доступу firewall

Після редагування конфігурації перевірте її синтаксис і перезавантажте службу SSH. Назва служби може бути ssh або sshd залежно від дистрибутива. Використовуйте reload, якщо він доступний: це дає змогу застосувати конфігурацію без безпідставного розриву активних сесій.

Додатковий рівень захисту — обмежити доступ до SSH на firewall. Найкращий варіант — дозволити порт лише з фіксованих IP-адрес офісу, VPN або адміністративної мережі. Зміна стандартного порту може зменшити шум у журналах, але не замінює ключі, firewall та вимкнення паролів.

• Перед увімкненням firewall дозвольте SSH із вашої поточної IP-адреси або VPN.
• Не обмежуйте доступ лише за IP, якщо адреса провайдера часто змінюється і немає резервного каналу.
• Перевірте правила з другого підключення, а не після завершення поточної сесії.
• Fail2ban може зменшити кількість повторних спроб, але не є заміною ключовій автентифікації та firewall.

sudo sshd -t
sudo systemctl reload ssh
# На деяких системах назва служби інша:
# sudo systemctl reload sshd

# Приклад для UFW: замініть адресу на свою або адресу VPN
sudo ufw allow from ADMIN_IP to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Типові помилки під час налаштування SSH

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

• Публічний ключ додано до /root/.ssh/authorized_keys, хоча підключення виконується як deploy.
• Каталог .ssh або authorized_keys належить root чи доступний для запису іншим користувачам.
• У конфігурації є помилка, тому службу SSH не вдається перезавантажити.
• AllowUsers не містить адміністративний акаунт або містить неправильне ім’я.
• Firewall дозволяє SSH не з тієї IP-адреси, яку ви фактично використовуєте.
• Усі ключі співробітників скопійовані в один акаунт без позначок і контролю.
• Єдиний приватний ключ зберігається на незашифрованому або спільному комп’ютері.

namei -l /home/deploy/.ssh/authorized_keys
sudo journalctl -u ssh --no-pager -n 50
ssh -v deploy@SERVER_IP

Що робити після звільнення адміністратора

Доступ колишнього працівника потрібно відкликати на сервері, а не лише видалити його з корпоративного чату. Визначте, який саме рядок у authorized_keys належить цьому користувачу, видаліть його та перевірте журнали входів. Якщо є підозра, що приватний ключ скопійовано, його слід вважати скомпрометованим і замінити.

• Використовуйте коментарі в кінці рядка ключа: ім’я, пристрій або дата.
• Регулярно проводьте інвентаризацію authorized_keys.
• Для командних середовищ розгляньте централізоване керування доступом і короткострокові облікові дані.
• Не видаляйте останній робочий ключ, доки не перевірите інший.

Що ще важливо для сервера WordPress та Elementor

Захист SSH не замінює оновлення WordPress, тем, плагінів, PHP та самої операційної системи. Якщо зловмисник отримав доступ до панелі WordPress або вразливого плагіна, SSH-ключі не усунуть наслідки компрометації сайту.

Адміністративний SSH-акаунт має отримувати лише ті права, які потрібні для обслуговування. Не запускайте вебсервер і PHP-процеси від root, не зберігайте приватні ключі у каталозі сайту та не додавайте ключі в резервні копії, доступні через веб.

Регулярно перевіряйте журнали входів, створюйте резервні копії поза сервером і тестуйте відновлення. Для WordPress-сайта це важливо не менше, ніж блокування ботів: резервна копія має дозволяти повернути працездатну версію після помилки оновлення або інциденту.

• Увімкніть багатофакторний захист для панелі WordPress та облікових записів хостингу.
• Оновлюйте Elementor, WordPress, плагіни, тему та системні пакети після перевірки сумісності.
• Обмежуйте права файлової системи й не використовуйте спільні адміністративні акаунти.
• Зберігайте резервні копії окремо від сервера та перевіряйте їх відновлення.
• Майте аварійний доступ через консоль провайдера або документований процес відновлення.