02.06.2017 | 07:21

krystian

Jak zabezpieczyć logowanie do serwera za pomocą jednorazowych tokenów

Wielu zwykłym administratorom serwerów wystarcza możliwość logowania do SSH za pomocą loginu i hasła. Niektórzy używają też swojego klucza. My chcemy zaproponować inne ciekawe rozwiązanie – tokeny z aplikacji Google Authenticator.

W poprzednich artykułach opisywaliśmy w jaki sposób możemy udowodnić swoją tożsamość łącząc się do usługi SSH z wykorzystaniem kluczy publicznych oraz prywatnych. W tym artykule przedstawimy kolejny sposób na wzmocnienie procesu uwierzytelniania stosując uwierzytelnianie wielopoziomowe (ang. multi-factor authentication).

Artykuł pod patronatem Aruba Cloud

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci i jak zacząć serwer zabezpieczać, jak postawić swój własny zdalny pulpitswój serwer WWWjak monitorować zmiany w plikachjak zablokować reklamy na komórce oraz jak skonfigurować bezpieczną kopię zapasową.

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

Uwierzytelnianie

Uwierzytelnianie jest procesem udowadniania swojej tożsamości. Jednym z powszechnych sposobów uwierzytelniania jest podanie informacji, które znamy (ang. somehing you know) – zazwyczaj jest to nazwa użytkownika i hasło. Proces uwierzytelniania może wymagać od nas dodatkowych czynników, tj:
– czegoś co posiadamy (ang. something you have) – na przykład urządzenie z kodem uwierzytelniającym, token,
– czegoś unikatowego powiązanego z naszą osobą (ang. something you are), na przykład odcisk palca, głos, obraz siatkówki oka.

Dwuskładnikowe uwierzytelnianie

Często stosuje się dwuskładnikowe uwierzytelnianie (two-factor authentication, 2FA) czyli łączące dwie wyżej wymienione metody. Przykładem takiego użycia może być proces logowania przez protokół SSH: po podaniu poprawnego loginu (coś, co wiemy) zostaniemy poproszeni o podanie informacji z tokena (coś, co posiadamy). W niniejszym artykule pokażemy jak skonfigurować serwer w Aruba Cloud aby po nawiązaniu połączenia przez protokół SSH uwierzytelnić się za pomocą loginu, hasła oraz tokenu.

Urządzenie mobilne jako token

Przed rozpoczęciem konfiguracji serwera musimy zaopatrzyć się w aplikację, która będzie pełniła rolę naszego programowego tokenu. W tym celu skorzystamy z aplikacji „Google Authenticator”, dostępnej dla Androida oraz dla iOS. Aplikacja ta może przydać się także do zabezpieczenia konta Google, Twittera czy nawet Wykopu.

Konfiguracja serwera

Cały proces możecie obejrzeć na poniższym filmie, a pod nim znajdziecie wersję tekstową instrukcji.

Zanim przystąpisz do konfiguracji upewnij się, że na Twoim serwerze jest poprawnie ustawiony czas. Tokeny są powiązane z funkcją czasu.

1) Instalujemy repozytorium EPEL – w nim znajduje się wymagany pakiet – google-authenticator

# yum install epel-release

2) Instalujemy pakiet google-authenticator z repozytorium EPEL:

# yum install google-authenticator

3) Rekonfigurujemy PAM i wskazujemy bibliotekę pam_google_authenticator.so dopisując na końcu pliku /etc/pam.d/sshd następującą linię:

auth required pam_google_authenticator.so nullok

Słowo „nullok” na końcu linii oznacza, że metoda autoryzacji za pomocą tokenu jest opcjonalna. Użytkownicy, którzy nie mają wygenerowanych tokenów autoryzacyjnych wciąż będą mogli zalogować się na przykład za pomocą kluczy SSH.

4) Restartujemy usługę SSH

# service sshd restart

Tworzenie tokenu

1) Uruchamiamy polecenie google-authenticator z konta, które będzie wymagało dwuskładnikowego logowania. W naszym przypadku będzie to konto o loginie `krystian`:

$ google-authenticator
Do you want authentication tokens to be time-based (y/n) y

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/krystian@aruba-cloud%3Fsecret%3DFKNIJIGAEUJNR7ETHDWQJK3ZHU%26issuer%3Daruba-cloud
Your new secret key is: FKNIJIGAEUJNR7ETHDWQJK3ZHU

Your verification code is 148080
Your emergency scratch codes are:
85594429
47984450
29535448
18966056
35833203

Do you want me to update your "/home/krystian/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) 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) y

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) y

W konsoli zostanie wygenerowany obraz QR. Jeśli napotkamy problemy ze zeskanowaniem kodu QR możemy odwiedzić adres www,  który został wygenerowany w domenie google.com.

Google Authenticator – programowy token uwierzytelniania dwuetapowego

Jak korzystać z 2FA?

Łącząc się do serwera Aruba Cloud za pomocą protokołu SSH zostaniemy poproszeni o podanie kodu jednorazowego:

$ ssh krystian@aruba-cloud
Password: 
Verification code: 
[krystian@aruba-cloud ~]$ 

Jak zatem widać, nie jest to szczególnie skomplikowane, a może w znaczący sposób podnieść bezpieczeństwo procesu logowania. Co jednak zrobić gdy zgubimy telefon lub nie mamy go akurat przy sobie? Jeśli utracimy urządzenie autoryzacyjne wciąż będziemy mogli zalogować się do konta korzystając z kodów pomocniczych. Kody te (’emergency scratch codes’) zostały wygenerowane podczas tworzenia tokenu i są zapisane w pliku /home/krystian/.google_authenticator (linie 8-12):

$ cat .google_authenticator

FKNIJIGAEUJNR7ETHDWQJK3ZHU
" RATE_LIMIT 3 30 1495813727
" WINDOW_SIZE 17
" DISALLOW_REUSE 49860448 49860450
" TOTP_AUTH
85594429
47984450
29535448
18966056
35833203

Warto je zapisać w bezpiecznym ale jednocześnie dostępnym miejscu by nie stracić możliwości połączenia z serwerem w krytycznym momencie. Łącząc się do usługi SSH możemy podać jeden ze zdefiniowanych kodów pomocniczych. Każdy kod możemy wykorzystać tylko raz – po zalogowaniu się kod pomocniczy jest usuwany z pliku .google_authenticator.

Oczywiście opisywana metoda dwuskładnikowego uwierzytelnienia jest jednym z wielu dostępnych wariantów – biorąc jednak pod uwagę fakt, że jego wdrożenie generuje jedynie koszt spędzonego nad nim czasu a poziom bezpieczeństwa rośnie, to rekomendujemy je wszystkim administratorom.

Dla pełnej przejrzystości – za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.

Powrót

Komentarze

  • 2017.06.02 07:34 Krzysztof

    Działa przy tym „Google Prompt” – powiadomienia push z opcją zatwierdź logowanie? Czy trzeba przepisywać kod za każdym razem?

    Odpowiedz
  • 2017.06.02 08:26 Mariusz

    Pomysł super, tylko czy jest jakieś rozwiązanie bez słowa „Google”? Chętnie widziałbym w tym miejscu słowo „open”.

    Odpowiedz
  • 2017.06.02 08:27 Jan

    A czy w ten sposob da sie zabezpieczyć, by 2fa dotyczył tylko specyficznej grupy w systemie ?

    Odpowiedz
    • 2017.06.02 13:01 Koral

      O ile dobrze pamiętam da się do konkretnych użytkowników

      Odpowiedz
  • 2017.06.02 08:35 malpiadama

    Czy nie da się takiego rozwiązania wdrożyć bez informowania Google kiedy i gdzie się logujemy?

    Odpowiedz
    • 2017.06.02 10:26 jjjjj

      yubikey

      Odpowiedz
    • 2017.06.02 15:56 Serpens

      Rozwiązanie opisane w artykule nie wysyła nic do Google.

      Odpowiedz
  • 2017.06.02 09:57 p

    Możecie też użyć yubi key.

    Odpowiedz
  • 2017.06.02 10:38 cyfrowy_ja

    Zawsze się zastanawiam, czy to bezpieczniejsze niż klucze SSH. Co myślicie?

    Odpowiedz
    • 2017.06.02 11:33 zakius

      do przejęcia klucza zazwyczaj wystarczy przejęcie komputera

      Odpowiedz
  • 2017.06.02 11:28 Lukasz

    Wszystko fajnie, tylko… nie dziala. Przynajmniej na debianie. Wszystko zainstalowane jak byc powinno, konfig zmieniony wg informacji tutaj, ale jednak nie dziala.

    Nie pyta o token, pyta o haslo. Jak wpisuje prawidlowe haslo, to w logach jest:
    sshd(pam_google_authenticator)[7285]: Invalid verification code

    Gdzie zatem robie blad? Ktos? Cos? Debian 8.

    Odpowiedz
    • 2017.06.02 20:50 Paweł Drzewiecki

      Musisz dodać metodę autoryzacji do sshd_config o ktorej autor nie wspomina:

      #1
      ChallengeResponseAuthentication yes
      #2
      User krystian# w tym przypadku AuthenticationMethods keyboard-interactive

      Daj znac czy działa

      Odpowiedz
      • 2017.06.05 10:07 Lukasz

        Pawel: zagadalo jak powinno:

        Password:
        Verification code:

        Odpowiedz
        • 2017.06.05 17:08 Przemmm

          Możesz wrzucić sshd_confg
          Bo ja nie mogę zmienić tej kolejności i męczę się już 2 godziny
          Zawsze woła o google auth na początku ale nie wyświetla promptu

          Odpowiedz
  • 2017.06.02 11:29 Paweł

    W podobny sposób (i w pełni darmowy), można zabezpieczyć dostęp do serwerów Windows z wykorzystaniem aplikacji Ekran System https://www.ekransystem.com/pl/two-factor-authentication-tool

    Odpowiedz
  • 2017.06.02 11:48 Maciej

    1. „Działa przy tym „Google Prompt”” – nie, zawsze należy przepisać kod
    2. „Chętnie widziałbym w tym miejscu słowo „open”.”- źródła są „open” na GitHubie i nic nie idzie na serwery Googla.
    3. „(…) da sie zabezpieczyć, by 2fa dotyczył tylko specyficznej grupy w systemie ?” – tak, można zrobić to przez modyfikacje w pam, ale prościej jest skorzystać z instrukcji i nie generować plików .google_authenticator dla tych, którzy nie mają się tak logować
    4. „Czy nie da się takiego rozwiązania wdrożyć bez informowania Google kiedy i gdzie się logujemy?” – nic nie wychodzi za serwer. W skrócie soft liczy sumę kontrolną czasu, to samo na telefonie i porównuje się wyniki.
    5. „Zawsze się zastanawiam, czy to bezpieczniejsze niż klucze SSH. Co myślicie?” – bezpieczniejsze, ale tylko dlatego, że kradzież/skopiowanie klucza może być dla ofiary niezauważalne, a telefonu już raczej nie.
    Osobiście stosuję to tak:
    konta admina: login + klucz (z ustawionym hasłem) + google_authenticator.
    Uprzywilejowani login + klucz
    Konto, na które muszę się czasem awaryjnie zalogować z niezaufanego PC to login + hasło + google_authenticator
    Login + klucz ma tę przewagę, że pod dodaniu klucza do ssh_agent nie trzeba nic robić co logowanie.

    Odpowiedz
  • 2017.06.02 12:41 Mariusz Grudzień

    Proponuje alternatywę – sprzętowe portfele:
    – trezor https://doc.satoshilabs.com/trezor-apps/sshagent.html
    i chyba wkrótce też ledger
    http://www.dongleauth.info/#remote

    Odpowiedz
  • 2017.06.02 18:49 Szymon

    Ok, tylko to rozwiązanie nie działa w połączeniu z logowaniem po kluczu :p

    Odpowiedz
    • 2017.06.02 20:53 hazy77

      Szymon mogę Cię zapewnić że działa w połączeniu z kluczem. Sprawdzone na Debianie.

      Odpowiedz
    • 2017.06.02 20:54 Paweł Drzewiecki

      Oczywiscie ze działa w kombinacji mieszanej:
      #1
      PasswordAuthentication no
      #2
      Match User krystian# w tym przypadku
      #3
      AuthenticationMethods publickey,keyboard-interactive

      Odpowiedz
  • 2017.06.02 23:29 Baltazar

    Ale można bez google. Można skorzystać np z FIDO U2F SECURITY KEY.

    Odpowiedz
  • 2017.10.14 19:02 gosc

    A jeszcze inni w sposób szyfrowany z przez dowolny hosting wysyłają sobie IP w celu dostępu do serwera.
    Potem dostęp jest chroniony haslem, kluczem i okreslonym czasem.

    Odpowiedz
  • 2017.11.21 20:57 Mieczysław

    Wpisałem kawałek konfigu sshd i pama i dostałem ze strony z3s alarm cloudflare ze probuje hackować stronę. Dobre hehe

    Odpowiedz
  • 2017.11.21 20:58 Mieczysław

    Udało mi sie uruchomić ale tylko wersję bez hasła. Tzn wpisuję login zaraz potem dostaje prompta o topt i loguję się z sukcesem
    sshd_config
    AuthenticationMethods keyboard-interactive
    pam.d sshd
    auth required pam_google_authenticator.so nullok

    Gdy zmieniam na
    AuthenticationMethods password,keyboard-interactive

    niestety pyta o hasło i nawet jak wpiszę poprawne to w logach sshd zrzuca „niepoprawne topt” a w ogole nie dostaje prompta o topt. Z kolei klient dostaje „wrong password”

    Odpowiedz
  • 2017.11.22 17:41 Mieczysław

    Rozwizanie podane przez Pawła wyżej w komentarzach działa tzn wystarczy samo
    AuthenticationMethods keyboard-interactive

    taka konfiguracja oznacza ze PAM zapyta zarówno o hasło jak i o OTP w drugim kroku.

    Wiersz include common-auth powinien być zahaszowany bo jeśli mamy autentykację PAM interactive to on już zadba o zapytanie o hasło i otp

    Odpowiedz

Zostaw odpowiedź do Lukasz

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Jak zabezpieczyć logowanie do serwera za pomocą jednorazowych tokenów

Komentarze