Двофакторна автентифікація (2FA) вимагає не лише пароль, а й одноразовий код із застосунку (TOTP). Навіть якщо пароль витече, обліковий запис залишиться захищеним.
Увімкнення 2FA в cPanel
Крок 1: Відкрийте налаштування
Увійдіть у cPanel → розділ «Security» → «Two-Factor Authentication».
Крок 2: Встановіть застосунок
На смартфон встановіть один із:
- Google Authenticator (iOS/Android)
- Authy (синхронізація між пристроями)
- Microsoft Authenticator
Крок 3: Відскануйте QR-код
У cPanel натисніть «Set Up Two-Factor Authentication», відкриється QR-код. Відкрийте застосунок-автентифікатор → «+» → «Scan QR Code».
Крок 4: Підтвердіть
Введіть 6-значний код із застосунку в поле «Security Code» і натисніть «Configure Two-Factor Authentication». Після цього при кожному вході в cPanel буде запитуватися код.
Вхід у cPanel з 2FA
- Введіть логін і пароль як зазвичай
- Відкрийте застосунок-автентифікатор
- Введіть 6-значний код (оновлюється кожні 30 секунд)
Відновлення доступу
Якщо загубили телефон:
- Використайте секретний ключ для відновлення в іншому застосунку
- Зверніться до техпідтримки ZevsHost із підтвердженням володіння обліковим записом
2FA для SSH (додатково)
# Встановити Google Authenticator PAM
sudo apt install -y libpam-google-authenticator
# Налаштувати для поточного користувача
google-authenticator
# Увімкнути в /etc/pam.d/sshd:
auth required pam_google_authenticator.so
# У /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Розбір типових проблем із TOTP-кодами
Більшість скарг на «не приймає код» зводиться до кількох механічних причин.
Permission denied (publickey,keyboard-interactive).— так SSH повідомляє, що всі налаштовані способи входу, включно з TOTP, не пройшли. Саме повідомлення не каже, який саме фактор підвів — пароль, ключ чи код, — це видно лише в журналі сервера.Do you want authentication tokens to be time-based (y/n)— це питання ставить утилітаgoogle-authenticatorпід час першого налаштування. Відповідайтеy: відповідьnперемикає на лічильник замість часу, а більшість застосунків на кшталт Google Authenticator і Authy працюють саме в time-based режимі й з HOTP синхронізуються погано.- Код скопійовано правильно, але сервер усе одно його не приймає — майже завжди означає розсинхронізацію годинників. TOTP базується на поточному часі, і модуль допускає лише невеликий запас відхилення.
- Повторне введення вже використаного 30-секундного коду відхиляється, хоча формально він ще «не минув» — це не помилка, а вбудований захист від повторного використання (replay protection) в самому модулі автентифікації.
- Код стабільно «відстає» чи «поспішає» на один крок — секрет введено правильно, проблема лише в годиннику телефона чи сервера, а не в самому ключі.
Порівняння застосунків для TOTP
| Застосунок | Синхронізація між пристроями | Резервне копіювання | Особливість |
|---|---|---|---|
| Google Authenticator | Немає (лише ручне перенесення QR) | Лише вручну, експортом | Простий і мінімалістичний |
| Authy | Так, між кількома пристроями | Хмарний бекап, захищений PIN-кодом | Зручність multi-device розширює поверхню атаки в разі витоку акаунта Authy |
| Microsoft Authenticator | Частково, через привʼязку до акаунта Microsoft | Через хмару Microsoft | Push-підтвердження для сервісів Microsoft |
| Апаратний ключ FIDO2/U2F | Немає | Фізичний пристрій, потрібен запасний ключ | Не піддається фішингу коду, але це вже не TOTP |
Коли 2FA в такому вигляді не підходить
- Спільний акаунт, яким одночасно користуються кілька людей — TOTP на одному телефоні блокує решту, якщо власник недоступний, а роздача спільного секрету всій команді зводить цінність другого фактора майже до нуля.
- Автоматизовані скрипти й cron-завдання, що звертаються до cPanel API — TOTP розрахований на інтерактивне введення і не вбудовується в автоматизацію; для API потрібні окремі API-токени, а не звʼязка пароль плюс код.
- Користувач без смартфона і без можливості поставити TOTP-застосунок на компʼютер — знадобиться запасний канал відновлення, інакше підтримка не зможе миттєво підтвердити особу при втраті доступу.
- Очікування, що 2FA захистить від крадіжки вже відкритої сесії — другий фактор перевіряється лише під час входу; перехоплені cookie сесії чи SSH-зʼєднання він заднім числом не розлогінить.
Перевірка, що вхід без другого фактора неможливий
# Перевірити, що модуль підключено в PAM
grep google_authenticator /etc/pam.d/sshd
# Подивитися чинну конфігурацію sshd, а не лише файл
sudo sshd -T | grep -i authenticationmethods
# Тестовий вхід в окремому вікні термінала, не закриваючи поточну сесію
ssh user@server-ip
Відкривайте нове підключення саме в окремому вікні: якщо вхід не пройде, стара сесія залишиться робочою і ви зможете відкотити налаштування, не втративши доступ до сервера. Для cPanel звіряйтеся зі списком користувачів із увімкненою двофакторною автентифікацією в WHM — там видно, для кого 2FA справді активна, а не просто колись була налаштована.