В рамках данной заметки мы настроим ssh 2fa авторизацию для дополнительной защиты входа на сервер с помощью двухфакторной аутентификации с кодами от Google Authenticator.
На смартфон, если приложение ещё не установлено, ставим Google Authenticator из Play Market. На сервер устанавливаем google-authenticator (из EPEL для CentOS) или libpam-google-authenticator. В зависимости от ОС.
В рамках заметки, автор настраивает авторизацию для пользователя root. Если ты, читатель, ранее с настройкой sshd не сталкивался, имеет смысл сначала потренироваться на каком-то другом пользователе, во избежание потери возможности входа на сервер. Разумеется, на боевой сервер эту настройку тащить имеет смысл только при полном понимании происходящего.
Первичная настройка.
На сервере настраиваем всё необходимое для авторизации. Для этого:
1. Выполняем команду google-authenticator, при этом, для нас будет сгенерирован QR-код, который мы фотографируем приложением Google Authenticator на смартфоне. Если всё сделано, верно, то в программе запустится генерация временных кодов:
# google-authenticator Do you want authentication tokens to be time-based (y/n) y
2. Отвечаем на несколько вопросов:
Do you want me to update your "/root/.google_authenticator" file? (y/n) y Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y By default, tokens are good for 30 seconds. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y
Далее, в зависимости от того, как у нас уже настроена авторизация по SSH…
Для авторизации с паролем.
Если на сервере у нас настроена авторизация с помощью пароля, то далее идём по такому пути:
3. Открываем /etc/pam.d/sshd, добавляем в него строки и сохраняем изменения:
auth required pam_unix.so no_warn try_first_pass auth required pam_google_authenticator.so
4. Открываем /etc/ssh/sshd_config, находим в нём параметр ChallengeResponseAuthentication и указываем для него yes:
ChallengeResponseAuthentication yes
5. В файле /etc/ssh/sshd_config так же дописываем следующее:
Match User root AuthenticationMethods keyboard-interactive
Для авторизации по ключам.
Если на сервере у нас используется авторизация по ключам, то пункты 3 и 5 будут выглядеть немного иначе (возможно кто-то уже настраивал авторизацию по своему):
3. Открываем /etc/pam.d/sshd, комментируем в нём две строки и добавляем одну:
#auth substack password-auth #auth required pam_unix.so no_warn try_first_pass auth required pam_google_authenticator.so
4. Открываем /etc/ssh/sshd_config, находим в нём параметр ChallengeResponseAuthentication и указываем для него yes:
ChallengeResponseAuthentication yes
5. В файле /etc/ssh/sshd_config так же дописываем следующее:
Match User root AuthenticationMethods publickey,keyboard-interactive
Завершаем настройку.
6. Убеждаемся что не допустили ошибок при модификации конфига, сохраняем изменения и перезапускаем sshd:
# systemctl restart sshd
Теперь пробуем войти на сервер, выглядеть всё будет примерно так:
$ ssh root@1.2.3.4 Password: Verification code: $ ssh root@1.2.3.4 Enter passphrase for key '/home/sysadmin/.ssh/id_rsa': Authenticated with partial success. Verification code:
Т. е. при авторизации по SSH нас сначала просят ввести пароль для доступа или ключа, а затем проверочный код. Код мы берём из приложения на смартфоне. После того как проверочный код будет введён верно, мы получаем доступ на сервер.
Спасибо!
Работает!
Добрый день.
Столкнулся с такой ситуацией.
Настроил Гугл аутенфикацию.
Но в выходные разбил телефон. Установил все на новый,но как быть с аутенфикатором?
Как мне теперь попасть на сервер?
Сочувствую, но если не сохранили QR-код или информацию для ручной настройки в программе аутентификаторе, то восстановить не получится никак. В этом случае алгоритм восстановления доступа к серверу примерно такой…
— Если на сервере стоит панель и в ней есть файл-менеджер, отменяем изменения, сделанные в рамках этой заметки оттуда.
— Если сервер виртуальный, то идём в VNC, там входим на сервер из локальной консоли и отменяем внесённые в рамках этой статьи изменения, перезапускаем sshd и проверяем — доступ на сервер должен появиться.
— Если сервер выделенный, и есть возможность подключить KVM к нему, подключаем, затем входим из локальной консоли и так же отменяем внесённые изменения, затем перезапускаем sshd.
— Если сервер выделенный, и возможности подключить к нему KVM нет, то загружаем сервер в rescue (просим поддержку сделать это или сами из панели), монтируем партацию на которой размещён /etc, откатываем внесённые изменения, сохраняем файлы, размонтируем партацию, перезагружаем сервер в обычный режим.
Если всё будет сделано верно, доступ по SSH появится вновь.
Спасибо!!
Получилось!
Если написать auth required pam_google_authenticator.so в /etc/pam.d/sshd, то если у вас есть ISP Manager, то он уже не пустит вас в панель. Поэтому, если вы его тоже используете, то пишите auth optional pam_google_authenticator.so