Попытка получить SSH с открытым ключом (без пароля) + аутентификатор Google, работающий на Ubuntu 14.04.1


20

Я использую Ubuntu 14.04.1 (с OpenSSH 6.6 и libpam-google-authenticator 20130529-2).

Я пытаюсь настроить SSH-входы, в которых открытый ключ аутентифицируется (без пароля), а пользователю предлагается ввести код от Google Authenticator.

Следуя / адаптируя эти инструкции, я получил запрос на ввод пароля и запрос на аутентификацию Google:

Я установил пакет, отредактировал мой /etc/ssh/sshd_configи /etc/pam.d/sshфайлы

В /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods  publickey,keyboard-interactive
UsePAM yes

и в нижней части /etc/pam.d/ssh:

auth required pam_google_authenticator.so nullok # (I want to give everyone a chance to set up their 2FA before removing "nullok")

Я знаю, что PAM зависит от порядка, но sshd_configтакже?

Что я делаю неправильно? Любая помощь будет оценена.

Ответы:


28

Получил это работает хорошо, сначала сделал:

apt-get install libpam-google-authenticator

В /etc/pam.d/sshdя изменил / добавил следующие строки (вверху):

# @include common-auth
auth required pam_google_authenticator.so

И в /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Работает хорошо, и теперь я получаю подсказку «Код подтверждения» после аутентификации с открытым ключом. Я не уверен, как разрешить аутентификацию с паролем + токеном ИЛИ ключом + токеном, поскольку теперь я фактически удалил метод аутентификации по паролю из PAM.

Использование Ubuntu 14.04.1 LTS (GNU / Linux 3.8.0-19-generic x86_64) с ssh -v: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 января 2014 г.


Итак, ради потомков, я понял свою проблему. Я тоже пытался PasswordAuthentication no, но это было не так. Проблема была / была в том, что у меня были / have ControlMaster autoи ControlPathдирективы в моем ~ / .ssh / config файле. Я хотел убедиться, что я не блокируюсь, поэтому я всегда оставляю сеанс SSH открытым. Так как мой компьютер просто использовал бы их повторно, я всегда входил без системы, запрашивающей токен. Я пометил ваш ответ как правильный, так как кто-то, следовавший ему, действительно получил бы рабочую установку. Благодарность!
JT.

2
Я использую CentOS 7. У меня есть PasswordAuthentication no, ChallengeResponseAuthentication yes, AuthenticationMethods publickey,keyboard-interactiveи UsePAM yesв sshd_config. Он проверяет мой ключ, а затем запрашивает у меня токен Google Authenticator, а также запрашивает мой пароль. Заставляет меня делать все три - не могу пропустить ни одного из них. Я также попробовал, AuthenticationMethods publickey,keyboard-interactive:pamкак предложено на странице руководства, но это ничего не изменило. Любые идеи?
Ник Уильямс

6
@NickWilliams У меня была такая же проблема. Что исправило это для меня, так это то, что мне нужно было выделить @include common-authстроку, которую показывают ответы. pam_google_authenticatorСначала я подумал, что это комментарий к строке в /etc/pam.d/sshd.
Freb

5
Спасибо! Мое решение не было таким же (мне нужно было закомментировать auth substack password-auth), но ваш комментарий решил мою проблему!
Ник Уильямс


7

Я, наконец, смог заставить это работать, разместив auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullokна вершине /etc/pam.d/sshd.

Согласно справочной странице pam.d :

  • success=done означает, что если Google Authenticator выйдет из системы, аутентификация больше не будет выполняться, что означает отсутствие дополнительной подсказки пароля.
  • default=die означает, что если Google Authenticator отклоняет попытку входа в систему, аутентификация сразу же завершится неудачей, пропуская запрос пароля.

То [success=done new_authtok_reqd=done default=die]же самое можно сказать и о сочетании значений управления sufficientи requisite, так как мы хотим, чтобы поведение было и тем и другим: в случае успеха немедленно завершить (достаточное), а в случае неудачи также немедленно завершить (обязательное).

Обратите внимание, что nullokаргумент pam_google_authenticator.so означает, что если ~/.google_authenticatorфайл не найден для пользователя, аутентификация с открытым ключом выполняется как обычно. Это полезно, если я хочу заблокировать только часть своих учетных записей с 2FA.


6

Ответ Линуса Кендалла должен работать на старых системах, но на более новых машинах Linux это проблематично; на моем веб-сервере arch linux эта конфигурация приводит к тому, что pam запрашивает мой код аутентификатора и мой пароль после получения моего ключа ssh (т.е. мне нужны все 3).

Более простое решение, которое предотвращает эту проблему и должно работать в каждой системе, состоит в том, чтобы изменить запись /etc/pam.d/sshdна:

auth sufficient pam_google_authenticator.so

А затем внести те же правки в `` / etc / ssh / sshd`, которые упоминал Линус:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Это должно спросить вас о вашем токене аутентификатора после того, как сервер примет ваш открытый ключ. Он не должен спрашивать ваш пароль.

В качестве примечания: если вы хотите иметь учетную запись пользователя sftp, вам, вероятно, потребуется обойти аутентификатор google, чтобы заставить его работать. Вот предложение о том, как сделать это безопасно с помощью sftp jail. В etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match User ftp-user
  PasswordAuthentication yes
  AuthenticationMethods password
  ChrootDirectory /path/to/ftp/dir
  ForceCommand internal-sftp

Вам нужно будет сделать разрешения только для записи / path / to / ftp / dir root (например chown root:root /path/to/ftp/dir, chmod 755 /path/to/ftp/dirвсем родителям выше этого каталога также нужны безопасные разрешения. Обычно я делаю это путем создания каталога chroot /home/shared/user, создания там каталог (например, 'data') и затем монтируем любой каталог, которым я хочу поделиться, вот так:sudo mount -o bind /path/to/ftp/dir /home/shared/user/data

Если вы выполните все эти шаги, у вас будет открытый ключ + логин google authenticator для ваших пользователей ssh ​​и функциональная защищенная паролем учетная запись sftp для передачи данных.


Это прекрасно работает. И поскольку по какой-то причине я просто не чувствую себя комфортно, комментируя общую аутентичность, это было более идеальным, чем решение Линуса.
Люк Сапан

Большое спасибо! потратил ночь на отладку ssh, удивляясь, почему мне все еще приходится вводить пароль после pubkey + authcode ……
felix021
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.