SSH: Двофакторна автентифікація


30

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

Я знайшов модуль PAM, схожий на те, що він буде сумісним, однак здається, що ви змушені використовувати пароль та згенерований код.

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


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

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

@Pierre Ви намагаєтеся вимагати як автентифікації відкритого ключа, так і Google OTP?
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, боюся, вам не пощастило.


Треба сказати, що я ціную зусилля, які ви доклали до пошуку відповіді, я, безумовно, намагався перейти кілька сторінок результатів Google, але все означало, що ви згадали, що я повинен використовувати лише пароль та OTP. Я, мабуть, створити CentOS VM, щоб пограти з цією функцією.
Бетонний віслюк

@Pierre Чи не що багато зусиль, я знав про цю функцію до ;-)
mgorven

Я знайшов відповідну помилку та деякі подальші примітки . Помилка включає в себе вкладений патч.
Робі Басак

І ось вища помилка openstream . Схоже, незабаром подібний функціонал буде відкритий у відкритому напрямку.
Робі Басак

openssh 6.2 потрапив у версію розробки Ubuntu, тому зберегти для будь-яких катастроф ця підтримка буде в очікуваному 13.10. Він використовує вихідні потоки AuthenticationMethodsдля визначення декількох необхідних методів, так що ви можете вимагати як ключ ssh, так і PAM, при цьому PAM закінчується Google Authenticator.
Робі Басак

8

Ви шукаєте Duo Security


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, а від SSH, який реалізує лише два факторні аутентифікацію (через ChallengeResponseAuthentication) для PAM, але не викликає PAM, коли надається дійсний відкритий ключ.


Це було правильно, але тепер змінилося. 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 в.


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 ), він не працює з відкритим ключем ключ.

З повагою, Вип


0

Якщо ви встановите пароль для свого приватного ключа, тоді у вас вже є двофакторна автентифікація. Для того, щоб увійти, люди потребують:

  1. щось у вас є - ваш приватний ключ
  2. щось, що ви знаєте - парольна фраза до вашого приватного ключа

3
Два паролі не роблять двофакторної аутентифікації. Сам ключ не є дійсним "щось у вас є", тому що це не річ, а лише інформація. Ця річ повинна бути неможливою для копіювання, або, принаймні, нетривіально копіювальною, для будь-якого використання як фактора аутентифікації.
MadHatter підтримує Моніку

2
Я цілком не згоден. Якщо ключі та сертифікати не "щось у вас є", то що вони? Вони, безумовно, не "те, що ти знаєш" (ти маєш звичку вивчати свій ключ SSH?), І зовсім не "щось ти є". Це єдині три варіанти, тому шляхом усунення вони, безумовно, є "чимось у вас є".
Барт Б

1
Я згоден; для мене проблема полягає в максимумі (те, що ви | знаєте | є). Ідея двофакторної аутентифікації - вимагати від членів двох класів з різними властивостями; те, що ви знаєте, легко переносити, але його може знати хтось інший, коли ви знаєте це; тому ми додаємо другий, різний коефіцієнт. "Щось у вас є" відрізняється лише тоді, коли його неможливо скопіювати (або важко скопіювати). В іншому випадку, звичайно, це не те, що ви знаєте, але це не якісно відрізняється від того, що ви знаєте , тому що хтось інший може мати його одночасно з вами.
MadHatter підтримує Моніку

2
Я, безумовно, погоджуюся, що захищений паролем ключ ключа - це велике поліпшення безпеки щодо прямого імені користувача + пароля. Я, на жаль, не згоден, що така пара вважається двофакторною, і нам, мабуть, доведеться погодитися з цим не погоджуватися.
MadHatter підтримує Моніку

3
Якщо у вас є приватний ключ із зашифрованою парольною фразою, ви доказуєте серверу лише одне: що ваш клієнт знає приватний ключ. Це не доводить серверу, що ви знаєте свою парольну фразу; сервер навіть не знає про існування вашої парольної фрази. Тому це лише "щось, що ви знаєте" (оскільки ваш клієнт це знає) і лише один фактор. Якщо зловмисник здобуде лише одну річ (ваш приватний ключ), тоді ви зірветесь. Це один із факторів. Стверджуючи, що ваша парольна фраза та приватний ключ вважаються двома факторами - лише вправа в софістиці. Важливо те, що відбувається на дроті.
Робі Басак
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.