Двухфакторная авторизация по протоколу SSH, используя Google Authenticator

Google Authenticator — это мобильное приложение, которое позволяет генерировать одноразовые коды, используемые при двухэтапной авторизации, согласно алгоритмам TOTP (Time-based One-time Password Algorithm) и HOTP (HMAC-based One-time Password Algorithm).

Смысл авторизации в 2 этапа состоит в том, что помимо имени пользователя и пароля, запрашивается дополнительный код, который меняется примерно раз в 30 секунд. Также большим преимуществом Google Authenticator является отсутствие необходимости доступа в интернет, он может работать в Offline режиме.

Чтобы обезопасить свой сервер, потребуется несколько простых действий в консоли. Для начала, подключимся к серверу по SSH, используя для входа только пароль.

Для дистрибутивов на базе Debian в репозиториях есть соответствующий пакет, установим его:

sudo apt install libpam-google-authenticator

После установки пакета отредактируем файл /etc/pam.d/sshd

sudo nano /etc/pam.d/sshd

В самый конец файла, добавим строчку «auth required pam_google_authenticator.so nullok». Конец фала должен выглядеть таким образом:

. . . 
@include common-password
auth required pam_google_authenticator.so nullok

Слово «nullok» в конце строки указывает на то, что данный метод авторизации опционален для каждого из пользователей. Это нужно, если у вас на червере несколько SSH пользователей, и не всем нужна защита Google Authenticator. Если же вы единственный администратор сервера, то можете убрать слово «nullok» из конфигурационного файла.

Теперь нужно разрешить использовать PAM модули в SSH, для этого отредактируем файл /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

Ищем строку «ChallengeResponseAuthentication» (в nano поиск вызывается по хоткею Ctrl + W), и ставим значение данного параметра «yes», в итоге строка должна иметь следующий вид:

. . .
ChallengeResponseAuthentication yes
. . .

Теперь нужно сгенерировать секретный ключ, для этого вводим в терминал команду:

google-authenticator

Утилита потребует ответа на ряд вопросов, и исходя из ответов сгененрирует конфигурационный файл.

Первый вопрос: Do you want authentication tokens to be time-based (y/n). 

Есть 2 вида токенов:

  • sequential-based — код имеет некоторое начальное значение, а затем увеличивается при каждом ипользовании;
  • time-based — код изменяется на случайное значение после истечения его срока старения.

Использование time-based токена более безопасный вариант, потому отвечаем на этот вопрос Y.

После этого, нам в консоль выдаст секретный ключ, для добавления его в мобильное приложение. Для удобства можно просто сканировать QR код. Также нам выдадут несколько одноразовых кодов, на случай если мобильный телефон будет утерян, следует сохранить их в надежном месте.

Второй вопрос: Do you want me to update your «/home/shifthackz/.google_authenticator» file (y/n).

Это просто запрос на перезапись файла с секретным ключом, отвечаем Y.

Третий вопрос: Do you want to disallow multiple uses of the same authentication token?

Позволяет предотвратить использование одного и того же токена разными пользователями, отвечаем 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).

Если ответить на этот вопрос положительно, то система будет принимать до 8 кодов за 4 минуты. Отрицательный ответ введет ограничение на 3 кода за 1,5 минуты. Более безопасен второй вариант, отвечаем N.

Но если в будущем у вас будут проблемы с авторизацией, можно войти под резервным кодом, сгенерировать новый ключ, и ответить на 4-й вопрос положительно.

Пятый и последний: 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).

Положительный ответ позволит ограничить количество попыток правильного ввода одноразовго кода до 3-х. Отвечаем Y.

Для того чтобы изменения вступили в силу, перезагружаем демон SSH.

sudo systemctl restart sshd.service

[!] ВАЖНО: Ни в коем случае не закрывайте терминал с активной SSH сессией. В случае если вы разорвете текущую сессию, и у вас возникнут проблемы с авторизацией, вы останетесь без доступа к серверу. 

Теперь берем в руки смартфон на базе iOS или Android, устанавливаем приложение Google Authenticator. В приложении нажимаем кнопку добавить и сканируем QR код с экрана компьютера, если камера плохо работает, можно ввести ключ вручную.

На компьютере открываем второй терминал, затем пробуем подключиться к серверу по SSH:

ssh {имя пользователя}@{IP адрес}

Сначала вводим пароль, который использовали до этого для авторизации, а затем вводим код из приложения Google Authenticator. Если все было настроено правильно, а также пароль и одноразовый код подходят, мы попадем в удаленную консоль сервера:

Если что-то пойдет не так, есть окно терминала с активной SSH сессией, где можно почитать логи, исправить ошибку, или временно отключить дополнительную защиту.

Вот таким простым способом можно уберечь свой сервер от взлома. Данную технологию можно использовать не только для защиты SSH, в следующей статье рассмотрим как обезопасить свой сайт на WordPress.

ShiftHackZ

ShiftHackZ

Автор блога LocalHost // Blog. Интересуюсь компьютерными технологиями, системным администрированием и веб-разработкой. Днями напролет провожу время за своим компьютером и самосовершенствуюсь. Подробнее

Читайте также:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *