SSH: двухфакторная аутентификация

30

В настоящее время у меня есть Ubuntu Server 12.04, на котором работает OpenSSH, а также Samba и несколько других сервисов. В настоящее время у меня настроена аутентификация с открытым ключом, и мне интересно, возможно ли установить двухфакторную аутентификацию? Я просматривал Google Authenticator, который сейчас использую в своей учетной записи Gmail.

Я обнаружил, что модуль PAM выглядит так, как будто он будет совместимым, однако кажется, что вы вынуждены использовать пароль и сгенерированный код.

Мне интересно, есть ли способ использовать приложение Google Authenticator (или что-то подобное) вместе с моим открытым ключом для аутентификации на моем SSH-сервере?

— Конкретный осел
источник

Большинство комментариев, похоже, являются отчетами об ошибках, в которых говорится, что невозможно использовать PAM и аутентификацию с открытым ключом с OpenSSH. Я также нашел части, упоминающие, что это избыточно, поскольку я использую парольную фразу с моим ключом. Со всеми решениями, казалось бы, только Google Authenticator и пароль, а не открытый ключ. Я мог бы упустить это полностью, но я просто не вижу, как реализовать оба.

— Конкретный осел

Не уверен, почему это имеет -1, это очень интересный вопрос, и я тоже хотел бы знать ответ (не то, что я, вероятно, буду его использовать, но даже так, хорошо копить в банках знаний)

— Марк Хендерсон

@Pierre Вы пытаетесь требовать как аутентификацию с открытым ключом, так и OTP Google?

— Mgorven

@mgorven Да, я пытался настроить как открытый ключ, так и Google OTP. Я слышал, что некоторые люди говорят, что достаточно иметь ключевую фразу на ключе как два фактора, но я обеспокоен тем, что вредоносные программы крадут незашифрованный ключ из памяти. Я предпочел бы иметь два совершенно разных устройства, используемых для аутентификации, я немного параноик.

— Конкретный осел

Официально это должно быть реализовано в 6.2: bugzilla.mindrot.org/show_bug.cgi?id=983#c59

— Тобиас Кинцлер,

8

Red Hat добавил патч к OpenSSH в RHEL (и, следовательно, CentOS) 6.3, чтобы требовать нескольких механизмов аутентификации, чтобы вы могли сделать что-то вроде этого:

RequiredAuthentications2 publickey,keyboard-interactive

См. Примечания к выпуску для не очень подробной информации.

К сожалению, эта функция, по-видимому, отсутствует ни в OpenSSH, ни в Ubuntu 12.04, поэтому, если вы не хотите найти патч и перекомпилировать OpenSSH, боюсь, вам не повезло.

— mgorven
источник

Я должен сказать, что я ценю ваши усилия по поиску ответа, я, конечно, пытался просмотреть несколько страниц результатов Google, но все подразумевали то, что вы упомянули, я должен был использовать только пароль и OTP. Я, вероятно, создам виртуальную машину CentOS, чтобы поиграть с этой функцией.

— Бетонный осел

@Pierre Не что много усилий, я знал об этой функции до ;-)

— mgorven

Я нашел соответствующую ошибку и некоторые дальнейшие заметки . Ошибка включает в себя патч в качестве вложения.

— Роби Басак

А вот баг с openssh . Похоже, что подобная функциональность скоро появится в openssh.

— Роби Басак

openssh 6.2 появился в разрабатываемом выпуске Ubuntu, так что за исключением всех бедствий эта поддержка будет в ожидаемой версии 13.10. Он использует восходящие потоки AuthenticationMethodsдля указания нескольких необходимых методов, так что вам может потребоваться как ключ ssh, так и PAM, а PAM выполняет функцию Google Authenticator.

— Роби Басак

8

Вы ищете Duo Security

— Ajith
источник

1

Это. Да. Я люблю эту вещь!

— LVLAaron

Определенно - Duo легко настроить для Unix / Linux (ссылка в ответе), OpenVPN ( duosecurity.com/docs/openvpn_as ) или любой двухфакторной службы на основе OATH TOTP или для управления паролями LastPass. Любой сервис, совместимый с Google Authenticator (использующий TOTP), можно использовать с мобильным приложением Duo или с аппаратным токеном, поддерживающим TOTP.

— RichVel

5

Вы можете использовать как модуль PAM Google Authenticator, так и открытые ключи, но для данной аутентификации будет использоваться только один. То есть, если пользователь входит в систему с авторизованным открытым ключом, токен не требуется.

Или, говоря иначе: токены требуются только для аутентификации пароля, а не для ключей SSH.

Между прочим, это ограничение исходит не от модуля Google Authenticator, а от SSH, который реализует двухфакторную аутентификацию (через ChallengeResponseAuthentication) для PAM, но не вызывает PAM, когда предоставляется действительный открытый ключ.

— ℝaphink
источник

Это было правильно, но теперь изменилось. OpenSSH 6.2 добавляет AuthenticationMethodsпараметр конфигурации, который может перевернуть это. Теперь вы можете требовать и того, и другого.

— Роби Басак

3

Этот вопрос с 2012 года. С тех пор SSH изменился, и был внедрен протокол SSH2.

В более поздних версиях SSH (> = 6.2) man sshd_config упоминает:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

На этой странице http://lwn.net/Articles/544640/ также упоминается возможность одновременного использования publickey и PAM-аутентификации.

— ликвидность
источник

2

Я знаю, что этот вопрос немного устарел, но ради будущих людей (включая меня), которые ищут решение, также говорят об использовании параметра ForceCommand в файле sshd_config для запуска сценария, который затем выполняет аутентификацию. Там пример скрипта , здесь вы можете изменить немного для ваших потребностей, хотя в этом примере он называет его из файла authorized_keys вместо того , чтобы его общесистемного с ForceCommand sshd_config в.

— Amazingant
источник

1

Получите YubiKey и следуйте этому руководству http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, это лучший способ внедрить Yubikey на вашем сервере для доступа по SSH. Приведенное выше руководство позволяет вам использовать открытый ключ + yubikey, тогда как если вы пользуетесь официальным руководством ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), оно не работает с открытым ключ.

С уважением, Vip

— vagarwal
источник

0

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

что-то у вас есть - ваш личный ключ
что-то, что вы знаете - пароль для вашего личного ключа

— Барт Б
источник

3

Два пароля не выполняют двухфакторную аутентификацию. Сам ключ не является действительным «чем-то, что у вас есть», потому что это не вещь, а просто часть информации. Эта вещь должна быть не копируемой или, по крайней мере, нетривиально копируемой, чтобы ее можно было использовать как фактор аутентификации.

— MadHatter поддерживает Монику

2

Я полностью не согласен. Если ключи и сертификаты не являются «чем-то, что у вас есть», то что это? Они определенно не являются «чем-то, что вы знаете» (у вас есть привычка изучать свой SSH-ключ?), И абсолютно не «тем, кем вы являетесь». Это единственные три варианта, поэтому в процессе исключения они, безусловно, являются «чем-то, что у вас есть».

— Барт Б

1

Я согласен; для меня проблема в максиме (то, что у вас есть | знаете | есть). Идея двухфакторной аутентификации состоит в том, чтобы требовать членов двух классов с разными свойствами; что-то, что вы знаете, легко переносить, но оно может быть известно кому-то еще в то же время, что и вы; поэтому мы добавим второй, другой фактор. «Что-то, что у вас есть» отличается только в том случае, если его невозможно скопировать (или трудно скопировать) В противном случае, конечно, это не то, что вы знаете, но это не качественно отличается от того, что вы знаете , потому что кто-то другой может иметь это в то же время, что и вы.

— MadHatter поддерживает Монику

2

Я определенно согласен с тем, что защищенная паролем пара ключей является большим улучшением безопасности по сравнению с прямым именем пользователя + паролем. К сожалению, я не согласен с тем, что такая пара считается двухфакторной, и нам, вероятно, придется согласиться с этим не согласиться.

— MadHatter поддерживает Монику

3

Если у вас есть секретный ключ с зашифрованной парольной фразой, вы докажете серверу только одно: ваш клиент знает закрытый ключ. Сервер не докажет, что вы знаете свою фразу-пароль; сервер даже не знает о существовании вашей парольной фразы. Поэтому это только «то, что вы знаете» (поскольку ваш клиент знает это) и только один фактор. Если злоумышленник захватит только одну вещь (ваш закрытый ключ), то вы скомпрометированы. Это один из факторов. Утверждение, что ваша парольная фраза и закрытый ключ считаются двумя факторами, является лишь упражнением в софистике. Что важно, так это то, что происходит на проводе.

— Роби Басак