Двофакторна автентифікація (2FA) вимагає не лише знання пароля/ключа, а й наявності фізичного пристрою (смартфона) з одноразовим кодом TOTP. Навіть у разі витоку SSH-ключа зловмисник не зможе увійти без другого фактора.
2FA для SSH через Google Authenticator
apt install libpam-google-authenticator -y
# Налаштувати для кожного користувача (запустити від користувача!)
su - admin
google-authenticator
# Відповісти Y, Y, N, Y, Y
# Відсканувати QR-код в Authy/Google AuthenticatorНалаштування PAM і sshd_config
# /etc/pam.d/sshd
auth required pam_google_authenticator.so
# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
# (потребує ключ І одноразовий код)
systemctl reload sshdКоди екстреного відновлення
Під час налаштування google-authenticator збережіть резервні коди відновлення (emergency scratch codes) у надійному місці. Без них у разі втрати телефона ви втратите доступ до сервера.
# Розташування файлу 2FA користувача
cat ~/.google_authenticator
# Перший рядок — секретний ключ
# Рядки з ** — коди відновлення (одноразові)2FA для WordPress
Встановіть плагін WP 2FA або Two Factor Authentication:
- Встановити плагін із WordPress Repository
- Увімкнути для всіх адміністраторів у налаштуваннях плагіна
- Кожен користувач налаштовує свій TOTP під час наступного входу
2FA для ISPmanager 6
# ISPmanager підтримує 2FA через TOTP
# Налаштування → Профіль → Двофакторна автентифікація
# Або через API:
# POST /api/ispmgr/totp.set із параметрами користувачаПідтримувані застосунки-автентифікатори
| Застосунок | Платформа | Особливості |
|---|---|---|
| Authy | iOS, Android, Desktop | Синхронізація між пристроями |
| Google Authenticator | iOS, Android | Простота, без синхронізації |
| Microsoft Authenticator | iOS, Android | Хмарне резервне копіювання |
| Bitwarden (Premium) | Усі | Вбудований у менеджер паролів |
| 1Password | Усі | Вбудований у менеджер паролів |
Рекомендація: Використовуйте Authy або зберігайте TOTP-секрет у менеджері паролів (Bitwarden, 1Password). Це дозволить відновити 2FA у разі втрати телефона без кодів відновлення.
Типові помилки 2FA
| Симптом | Причина | Що робити |
|---|---|---|
| Invalid verification code за правильно введеного коду | Розсинхронізація системного часу сервера — TOTP чутливий до зсуву понад 1–2 хвилини | Синхронізуйте час: timedatectl set-ntp true і перевірте timedatectl status |
| PAM authentication failure в auth.log за правильного коду | Рядок pam_google_authenticator.so стоїть у неправильному порядку відносно pam_unix.so або common-auth | Розмістіть його вище @include common-auth у /etc/pam.d/sshd і перезапустіть sshd |
| Користувач загубив телефон, коди відновлення не збережені | Файл ~/.google_authenticator прив'язаний до пристрою, резервних кодів немає | Інший адміністратор заходить по SSH-ключу і видаляє/перестворює файл 2FA для користувача |
| Time out of sync у застосунку-автентифікаторі | Годинник смартфона розійшовся з реальним часом | Увімкніть автоматичну синхронізацію часу в налаштуваннях телефона |
Порівняння методів другого фактора
| Метод | Захист від фішингу | Потрібна підтримка на сервері |
|---|---|---|
| TOTP (Google Authenticator) | Немає — код можна перехопити і ввести вручну на підробній сторінці | Немає, достатньо PAM-модуля |
| SSH-сертифікати (CA) | Так, прив'язані до пари ключів, а не до введеного коду | Так, потрібен власний центр сертифікації |
| U2F / WebAuthn (для веб-панелей) | Так, криптографічно прив'язаний до домену — не спрацює на фішинговому сайті | Так, підтримка має бути в самій панелі та браузері |
Коли 2FA не підходить
- Автоматичні скрипти та cron-завдання, що використовують SSH-ключ без інтерактивної сесії — TOTP через AuthenticationMethods заблокує такий вхід
- Велика розподілена команда з частою зміною складу — керувати централізовано простіше через SSH-сертифікати, а не особисті TOTP-секрети кожного
- Аварійний сценарій без другого адміністратора з доступом — якщо єдина людина з 2FA загубила телефон і коди, відновлення потребує доступу через консоль хостинг-провайдера
- Тестовий VPS з низькою цінністю даних для особистих експериментів — додатковий крок входу не виправданий ризиками
Базове налаштування sshd_config, на яке спирається ця схема, розібрано у статті «SSH Hardening: безпечне налаштування сервера від злому». Для веб-панелей на кшталт cPanel є окремий розбір у статті «Двофакторна автентифікація в cPanel: налаштування 2FA».
Перевірка результату
Переконайтеся, що 2FA справді вимагається під час входу, а не просто налаштована:
# Перевірити, що вхід лише за ключем без TOTP відхиляється
ssh -o PreferredAuthentications=publickey user@server
# Очікується запит verification code, а не миттєвий вхід
# Права на файл секрету мають бути закриті від інших користувачів
stat -c "%a %n" ~/.google_authenticator
# Перевірити активні методи автентифікації в поточній конфігурації
sshd -T | grep -i authenticationmethodsЯкщо потрібен стійкіший до крадіжки ключів варіант входу для команди, варто подивитися на «SSH-сертифікати: вхід через центр сертифікації».