SSH: Uwierzytelnianie dwuskładnikowe

30

Obecnie mam Ubuntu Server 12.04 z OpenSSH wraz z Sambą i kilkoma innymi usługami. Obecnie mam skonfigurowane uwierzytelnianie za pomocą klucza publicznego i zastanawiam się, czy można skonfigurować uwierzytelnianie dwuskładnikowe? Patrzyłem na Google Authenticator, którego obecnie używam na moim koncie Gmail.

Znalazłem moduł PAM, który wygląda na zgodny, jednak wydaje się, że musisz użyć hasła i wygenerowanego kodu.

Zastanawiam się, czy istnieje sposób na użycie aplikacji Google Authenticator (lub czegoś podobnego) wraz z moim kluczem publicznym do uwierzytelnienia na moim serwerze SSH?

ssh authentication public-key two-factor Betonowy osioł
źródło
Większość komentarzy wydaje się być raportami o błędach, w których wspomina się, że nie można używać PAM i uwierzytelniania za pomocą klucza publicznego w OpenSSH. Znalazłem również fragmenty, w których wspomniałem, że są zbędne, ponieważ używam hasła z kluczem. Przy wszystkich rozwiązaniach pozornie dopuszcza się tylko Google Authenticator i hasło, a nie klucz publiczny. Mogłem tego całkowicie przegapić, ale po prostu nie wiem, jak zaimplementować oba.
Concrete Donkey
Nie jestem pewien, dlaczego to ma -1, to jest bardzo interesujące pytanie i ja też chciałbym poznać odpowiedź (nie, że prawdopodobnie będę go używał, ale mimo to dobrze jest schować się w bankach wiedzy)
Mark Henderson
@Pierre Czy próbujesz wymagać zarówno uwierzytelnienia za pomocą klucza publicznego, jak i Google OTP?
mgorven
@mgorven Tak, próbowałem skonfigurować zarówno klucz publiczny, jak i Google OTP. Słyszałem, jak niektórzy twierdzą, że wystarczające jest użycie hasła do klucza, który liczy się jako dwa czynniki, ale martwię się, że złośliwe oprogramowanie wykradnie niezaszyfrowany klucz z pamięci. Wolę mieć dwa całkowicie oddzielne urządzenia używane do uwierzytelniania, jestem nieco paranoikiem.
Betonowy osioł
Zostanie to oficjalnie zaimplementowane w wersji 6.2: bugzilla.mindrot.org/show_bug.cgi?id=983#c59
Tobias Kienzler

Odpowiedzi:

8

Red Hat dodał łatkę do OpenSSH w RHEL (i dlatego CentOS) 6.3, aby wymagać wielu mechanizmów uwierzytelniania, dzięki czemu możesz zrobić coś takiego:

RequiredAuthentications2 publickey,keyboard-interactive

Niewiele więcej szczegółów można znaleźć w informacjach o wersji .

Niestety ta funkcja nie wydaje się być dostępna w OpenSSH ani w Ubuntu 12.04, więc chyba, że ​​chcesz znaleźć łatkę i ponownie skompilować OpenSSH, obawiam się, że nie masz szczęścia.

mgorven
źródło
Muszę powiedzieć, że doceniam wysiłek włożony w znalezienie odpowiedzi, z pewnością próbowałem przejrzeć kilka stron wyników Google, ale wszystkie sugerowały to, o czym wspomniałeś, że musiałem używać tylko hasła i OTP. Prawdopodobnie utworzę maszynę Wirtualną CentOS do zabawy z tą funkcją.
Concrete Donkey
@Pierre Nie , że wiele wysiłku, wiedziałem o tej funkcji przed ;-)
mgorven
Znalazłem odpowiedni błąd i kilka dalszych uwag . Błąd zawiera łatkę jako załącznik.
Robie Basak
A tutaj błąd upsh openss . Wygląda na to, że podobna funkcjonalność zostanie wkrótce uruchomiona w openssh.
Robie Basak
openssh 6.2 wylądował w wydaniu deweloperskim Ubuntu, więc poza wszelkimi katastrofami, wsparcie będzie w oczekiwanej wersji 13.10. Wykorzystuje upstream AuthenticationMethodsdo określenia wielu wymaganych metod, dzięki czemu można wymagać zarówno klucza ssh, jak i PAM, przy czym PAM wykonuje koniec Google Authenticator.
Robie Basak
8

Szukasz Duo Security

Ajith
źródło
1
To. Tak. Kocham to!
LVLAaron
Zdecydowanie - Duo można łatwo skonfigurować dla systemów Unix / Linux (link w odpowiedzi), OpenVPN ( duosecurity.com/docs/openvpn_as ) lub dowolnej usługi dwuskładnikowej opartej na OATH TOTP lub do zarządzania hasłami LastPass. Każda usługa zgodna z Google Authenticator (która używa TOTP) może być używana z aplikacją mobilną Duo lub tokenem sprzętowym obsługującym TOTP.
RichVel
5

Możesz użyć zarówno modułu PAM Google Authenticator, jak i kluczy publicznych, ale tylko jeden będzie jednocześnie używany do danego uwierzytelnienia. Oznacza to, że jeśli użytkownik zaloguje się przy użyciu autoryzowanego klucza publicznego, token nie będzie wymagany.

Lub, mówiąc inaczej: tokeny są wymagane tylko do uwierzytelnienia hasła, a nie klucze SSH.

Nawiasem mówiąc, to ograniczenie nie pochodzi z modułu Google Authenticator, ale z SSH, który implementuje tylko dwa czynniki uwierzytelniania (via ChallengeResponseAuthentication) dla PAM, ale nie wywołuje PAM, gdy podany jest prawidłowy klucz publiczny.

Inkaphink
źródło
To było poprawne, ale teraz się zmieniło. openssh 6.2 dodaje parametr AuthenticationMethodskonfiguracyjny, który może to odwrócić. Teraz możesz wymagać obu.
Robie Basak
3

To pytanie pochodzi z 2012 roku. Od tego czasu zmienił się SSH i wdrożono protokół SSH2.

W nowszych wersjach SSH (> = 6.2) man sshd_config wspomina:

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.

Na tej stronie http://lwn.net/Articles/544640/ wspomniano również o możliwości jednoczesnego korzystania z klucza publicznego i uwierzytelniania PAM.

płynność
źródło
2

Wiem, że to pytanie jest trochę nieaktualne, ale ze względu na przyszłych ludzi (w tym mnie), którzy szukają rozwiązania, mówi się również o użyciu opcji ForceCommand w pliku sshd_config w celu uruchomienia skryptu, który następnie wykonuje uwierzytelnienie. Jest tutaj przykładowy skrypt , który możesz nieco zmodyfikować do swoich potrzeb, chociaż w tym przykładzie wywołuje go z pliku autoryzowanego_klucza zamiast uczynić go ogólnosystemowym za pomocą ForceCommand sshd_config.

Amazingant
źródło
1

Zdobądź YubiKey i postępuj zgodnie z tym przewodnikiem http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, jest to najlepszy sposób na wdrożenie Yubikey na serwerze w celu uzyskania dostępu SSH. Powyższy przewodnik umożliwia korzystanie z klucza publicznego + yubikey, natomiast jeśli korzystasz z oficjalnego przewodnika ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), nie działa on z public- klawisz.

Pozdrawiam, Vip

Vagarwal
źródło
0

Jeśli ustawisz hasło dla klucza prywatnego, to masz już uwierzytelnianie dwuskładnikowe. Aby się zalogować, ludzie będą potrzebować:

  1. coś, co masz - swój klucz prywatny
  2. coś, co wiesz - hasło do twojego klucza prywatnego
Bart B.
źródło
3
Dwa hasła nie powodują uwierzytelnienia dwuskładnikowego. Sam klucz nie jest prawidłowym „czymś, co masz”, ponieważ to nie jest rzecz, tylko informacja. Ta rzecz nie może być kopiowana, a przynajmniej nietrywialnie kopiowalna, aby mogła być używana jako czynnik uwierzytelniający.
MadHatter obsługuje Monikę
2
Całkowicie się nie zgadzam. Jeśli klucze i certyfikaty nie są „czymś, co masz”, to czym one są? Na pewno nie są „czymś, co wiesz” (czy masz zwyczaj uczyć się na kluczu SSH?) I absolutnie nie są „czymś, czym jesteś”. Są to jedyne trzy opcje, więc w procesie eliminacji z pewnością są one „czymś, co masz”.
Bart B
1
Zgadzam się; dla mnie problem leży w maksimum (coś, co | wiesz | są). Ideą uwierzytelniania dwuskładnikowego jest wymaganie członków dwóch klas o różnych właściwościach; coś, co wiesz, jest łatwe do noszenia, ale może być znane przez kogoś innego w tym samym czasie, co znasz; więc dodajemy drugi, inny czynnik. „Coś, co masz” jest inne tylko wtedy, gdy jest niemożliwe do skopiowania (lub trudne do skopiowania). W przeciwnym razie, oczywiście, nie jest to coś, co wiesz, ale nie różni się jakościowo od czegoś, co wiesz , ponieważ ktoś inny może mieć to w tym samym czasie, co ty.
MadHatter obsługuje Monikę
2
Zdecydowanie zgadzam się, że para kluczy chronionych hasłem to duża poprawa bezpieczeństwa w porównaniu z prostą nazwą użytkownika + hasłem. Nie zgadzam się niestety, że taka para liczy się jako czynnik dwuskładnikowy i prawdopodobnie będziemy musieli zgodzić się na to.
MadHatter obsługuje Monikę
3
Jeśli masz klucz prywatny zaszyfrowany hasłem, udowodnisz serwerowi tylko jedną rzecz: klient zna klucz prywatny. Serwer nie dowodzi, że znasz swoje hasło; serwer nawet nie wie o istnieniu twojego hasła. Dlatego jest to tylko „coś, co wiesz” (ponieważ klient o tym wie) i tylko jeden czynnik. Jeśli atakujący przejmie tylko jedną rzecz (twój klucz prywatny), wtedy zostaniesz narażony na szwank. To jeden czynnik. Argumentowanie, że twoje hasło i klucz prywatny liczą się jako dwa czynniki, jest tylko ćwiczeniem w zakresie sofistyki. Liczy się to, co dzieje się na drucie.
Robie Basak