2FA для SSH через PAM і TOTP – це другий фактор для SSH-входу, який додає одноразовий код через PAM-модуль. Схема доречна для інтерактивного доступу до Linux-серверів, але легко відрізає вхід після помилки в sshd_config або /etc/pam.d/sshd. Тут – коли її ставити, як увімкнути без самоблокування і чим перевірити результат.
Для homelab і невеликих серверів проблема зазвичай не у встановленні пакета. Падає доступ після першого reload, коли код починає вимагатися в automation, backup job або в аварійній сесії з чужого ноутбука. Через це TOTP варто вмикати лише там, де є жива авторизація і зрозумілий шлях відкату.
Коли 2FA для SSH через PAM і TOTP справді має сенс
2FA для SSH через PAM і TOTP виправдана там, де на сервер заходять люди, а не тільки скрипти, і де SSH доступний із зовнішніх мереж. Типовий сценарій – адміністрування VPS, bastion-хоста або кількох Linux-вузлів, куди входять з ноутбука по ключу.
Якщо сервер виставлений в інтернет, другий фактор добре доповнює SSH keys, але не замінює їх. Для входу за паролем захист відчутно зростає. Для входу по ключу користь скромніша, зате з’являється бар’єр на випадок витоку приватного ключа без passphrase.
У невеликій інфраструктурі це працює нормально, коли є 2-5 адміністраторів, окремі користувачі і зрозумілий контроль над файлами в /etc/pam.d/. Коли хости десятками піднімаються через automation, схема стає тягарем. Тоді частіше виграє доступ через VPN або bastion, а сам SSH краще лишити на ключах.
Якщо основна проблема – brute force по 22 порту, спершу варто закрити поверхню атаки. Часто більше користі дає Fail2ban для SSH або доступ до SSH без відкриття портів через Cloudflare Tunnel. TOTP тут – додатковий бар’єр, а не заміна базової схеми доступу.
Де SSH з TOTP ламає доступ частіше, ніж допомагає
Найчастіші збої з’являються після редагування PAM, після зміни AuthenticationMethods в sshd_config і при роботі з користувачами, які ще не ініціалізували TOTP-секрет. Однієї помилки в будь-якому з цих місць вистачає, щоб нові входи перестали працювати.
Коли код вимагається, а секрет ще не створений
Типова пастка – увімкнути PAM-модуль для всіх користувачів, а вже потім запускати налаштування TOTP. Тоді SSH коректно просить verification code, але перевіряти нічого, бо файла з секретом ще немає. Нові сесії не відкриваються.
Особливо боляче це б’є по root або по єдиному sudo-користувачу. Якщо облікові записи розкладені хаотично, спершу варто розділити ролі й доступи. Для цього доречний окремий матеріал про керування обліковими записами в Linux.
Коли PAM чіпляється не туди
На Debian і Ubuntu модуль часто підключають у /etc/pam.d/sshd. Невдалий рядок може зачепити всі SSH-авторизації, включно з тими, де пароль взагалі не використовувався. На частині схем це закінчується циклом запитів або відмовою без зрозумілого повідомлення.
Ще один частий збій – змішати кілька модулів із жорсткими прапорцями required без розуміння порядку виконання. PAM читається зверху вниз. Якщо TOTP-модуль стоїть раніше, ніж треба, діагностика стає дуже неприємною.
Коли збивається час
TOTP залежить від часу. Якщо на сервері немає нормальної синхронізації через NTP, коди починають відхилятися. Симптом дивний: QR-код уже прив’язаний, застосунок показує числа, але вхід постійно завершується помилкою.
На одному сервері це рідкість. На старих VM або після ручних втручань у час проблема спливає регулярно. Насамперед перевіряють timedatectl і стан NTP.
Як підготувати сервер до 2FA для SSH без ризику залишитися зовні
Перед змінами в PAM і sshd потрібні друга активна SSH-сесія, доступ до консолі поза SSH і резервні копії конфігів. Без цього звичайне редагування легко перетворюється на аварійне відновлення через панель хостера або IPMI.
- Відкрийте другу SSH-сесію і не закривайте першу до завершення перевірок.
- Переконайтеся, що є доступ до веб-консолі VPS, IPMI, iDRAC, iLO або локальної консолі.
- Збережіть копії
/etc/ssh/sshd_configі/etc/pam.d/sshd. - Перевірте синхронізацію часу командою
timedatectl. - Підготуйте окремого sudo-користувача для тесту, не root.
Для серверів за VPN ризик нижчий. Якщо доступ уже йде через mesh VPN, ускладнювати сам SSH часто не варто. У такому випадку корисніше порівняти Tailscale чи WireGuard і вирішити, чи взагалі потрібен TOTP на рівні SSH.
Що зберегти перед редагуванням конфігів
Копії файлів мають лежати поруч і мати зрозумілі назви. Це економить хвилини, коли треба швидко відкотитися через консоль.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak
Перед застосуванням змін варто одразу перевірити синтаксис SSH-конфіга. Помилка в одному параметрі валить сервіс повністю.
sudo sshd -t
Як налаштувати PAM і TOTP для SSH на Linux-сервері покроково
2FA для SSH через PAM і TOTP на Linux зазвичай вмикають через пакет libpam-google-authenticator, зміну /etc/pam.d/sshd і параметри в sshd_config. Безпечний порядок такий: встановити пакет, створити секрет для тестового користувача, підключити PAM, перевірити конфіг і лише тоді перезавантажити SSH.
1. Встановіть PAM-модуль для TOTP
На Debian і Ubuntu достатньо стандартного пакета.
sudo apt update sudo apt install libpam-google-authenticator
Пакет використовує формат TOTP, сумісний з багатьма authenticator-застосунками. Деталі по модулю і форматах є на офіційній сторінці Google Authenticator PAM.
2. Створіть TOTP-секрет для користувача
Секрет треба створити від імені того користувача, який входитиме по SSH. Для першого тесту краще брати окремий адміністративний акаунт, а не root.
google-authenticator
Під час ініціалізації утиліта покаже QR-код, secret key і emergency scratch codes. Scratch codes треба зберегти поза сервером. Якщо телефон недоступний, саме вони рятують від зайвого входу в консоль хостера.
3. Підключіть модуль у PAM для SSH
У файлі /etc/pam.d/sshd додайте рядок для TOTP. Для першого запуску безпечніше використати nullok. Це дозволяє входити користувачам без налаштованого секрету, поки схема тестується. Після перевірки цей прапорець варто прибрати.
auth required pam_google_authenticator.so nullok
Рядок зазвичай ставлять на початку auth-секції або близько до неї. Головне – не перемішати його навмання з локальними кастомізаціями PAM. Якщо на сервері вже стоять нетипові модулі, спершу переглядають увесь стек авторизації.
4. Увімкніть keyboard-interactive в SSH
Для TOTP через PAM треба дозволити keyboard-interactive і задати методи автентифікації. У /etc/ssh/sshd_config мінімальний робочий набір такий:
UsePAM yes KbdInteractiveAuthentication yes ChallengeResponseAuthentication yes PasswordAuthentication no PubkeyAuthentication yes AuthenticationMethods publickey,keyboard-interactive
Тут сервер спершу приймає ключ, а потім просить TOTP-код. Це кращий варіант, ніж пароль плюс код. Якщо лишити PasswordAuthentication yes, кількість сценаріїв відмов зросте, а користі для підготовленого середовища небагато.
Параметр ChallengeResponseAuthentication на нових системах може бути застарілим синонімом або взагалі не потрібним, але на частині інсталяцій він досі трапляється в чинних конфигах. Якщо sshd -t не скаржиться, конфіг узгоджений.
5. Перевірте конфіг і перезавантажте SSH
Перед reload перевіряють синтаксис. Після цього краще виконати reload, а не повний restart.
sudo sshd -t sudo systemctl reload ssh
На деяких дистрибутивах сервіс називається sshd, а не ssh. Через це легко зробити хибний висновок, ніби конфіг не застосувався.
Як перевірити, що 2FA для SSH працює саме так, як задумано
Перевірка має йти в новій сесії, поки стара залишається відкритою. Правильний результат такий: сервер приймає ключ, потім просить verification code, після чого відкриває shell. Якщо щось іде не так, доступ відновлюють зі старої сесії або через консоль.
Тестовий вхід без розриву чинної сесії
З іншого термінала підключіться до сервера звичайною командою:
ssh [email protected]
Якщо схема зібрана правильно, запит пароля зникне, а після перевірки ключа з’явиться запрошення ввести TOTP-код. Якщо сервер одразу відмовляє, перевіряють /var/log/auth.log або journal для sshd.
sudo tail -f /var/log/auth.log
Що саме має насторожити
Небезпечний симптом – нова сесія входить без коду, хоча TOTP уже нібито ввімкнений. Це означає, що PAM не зачепив SSH або в конфігу лишився обхідний метод входу. Такий стан гірший за явну помилку, бо створює фальшиве відчуття захисту.
Ще одна ознака проблеми – код приймається лише інколи. Тоді насамперед дивляться на час сервера і наявність кількох конфліктних параметрів у sshd_config. Якщо лишався nullok, після успішного тесту його краще прибрати й перезавантажити демон ще раз.
Чому 2FA через PAM не підходить для automation, Ansible і backup jobs
2FA для SSH через PAM і TOTP погано сумісна з automation, бо скрипт не може стабільно ввести одноразовий код у потрібний момент. Після ввімкнення TOTP ламаються Ansible-підключення, rsync по cron, backup jobs і будь-які non-interactive SSH-сесії, якщо вони проходять тим самим шляхом авторизації.
Обхід через спільний TOTP-секрет для сервісного акаунта створює зайві проблеми. Секрет доведеться десь зберігати, ротація стане ручною, а аудит доступу погіршиться. Для automation нормальний варіант інший: окремий технічний користувач, тільки SSH keys, жорстко обмежені права й, за потреби, from= у authorized_keys.
Як розділити людський і машинний доступ
Найчистіша схема – вимагати TOTP лише для адміністративних акаунтів, якими користується людина, а для automation лишити окремий шлях без PAM-TOTP. Це можна зробити через окремих користувачів, групи або навіть інший SSH-вхідний контур на bastion-хості.
Коли машин багато, дешевше по супроводу захищати сам периметр доступу. Тут часто краще винести SSH за VPN. Для домашньої інфраструктури корисний сценарій – доступ через Tailscale exit node або іншу закриту мережу, а не TOTP на кожному вузлі окремо.
Коли краще залишити SSH keys, VPN або bastion замість TOTP
TOTP для SSH не універсальна відповідь. Якщо вузли доступні тільки через VPN, якщо вхід іде через bastion або якщо є багато automation, кращий результат дають SSH keys, закритий мережевий контур і контроль точки входу. У таких схемах менше шансів заблокувати легітимний доступ, а супровід простіший.
| Підхід | Де виграє | Де слабке місце |
|---|---|---|
| SSH keys + TOTP через PAM | Окремі сервери з інтерактивним адмін-доступом | Ламає automation, вимагає уважного PAM |
| SSH keys без TOTP | Закриті мережі, внутрішні вузли, CI/CD | Ключ без passphrase стає єдиною точкою ризику |
| VPN, наприклад Tailscale або WireGuard | Кілька серверів і постійний приватний доступ | Треба підтримувати окремий мережевий шар |
| Bastion | Кілька адміністраторів і сегментована інфраструктура | Потрібно правильно вести аудит і доступи |
Для одного VPS з відкритим 22 портом другий фактор ще має сенс. Для десяти вузлів за VPN ця схема вже часто зайва. Якщо мета – не світити SSH назовні, доступ без відкритих портів дає чистіший результат, ніж PAM-модулі на кожному сервері.
2FA для SSH через PAM і TOTP варто ставити на інтерактивні сервери з прямим SSH-доступом, де є консоль відновлення і зрозумілий поділ користувачів. Для automation, закритих мереж і більших наборів хостів виграють ключі, VPN або bastion. Тут межа застосовності важливіша за сам факт другого фактора.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.