2FA dla SSH w Linuksie z pam_radius – zatwierdzanie na telefonie dla SSH i sudo

Ten sam Notakey auth-proxy, który chroni już Państwa VPN oraz logowanie administratora do MikroTika, może chronić także logowanie do Linuksa. Stos PAM w Linuksie zawiera standardowy moduł RADIUS: wystarczy skierować go na proxy, aby SSH, sudo i su wymagały zatwierdzenia na telefonie oprócz hasła.

sshd / sudo ──PAM──▶ pam_radius ──RADIUS──▶ Notakey auth-proxy ──▶ your RADIUS server
                                                    │
                                                    └──▶ push ──▶ user's phone

Ten przewodnik dotyczy dystrybucji Debian/Ubuntu (libpam-radius-auth); w dystrybucjach z rodziny RHEL moduł jest dostępny jako pakiet pam_radius (EPEL), a pliki PAM znajdują się w tym samym układzie katalogu /etc/pam.d/.

Wymagania

Działający auth-proxy przed serwerem RADIUS, skonfigurowany dokładnie tak jak w krokach 1–3 przewodnika po VPN.
Ta sama nazwa użytkownika w docelowym serwerze RADIUS, w usłudze Notakey (z zarejestrowanym telefonem) oraz jako konto na maszynie z Linuksem. PAM jedynie uwierzytelnia; użytkownik nadal potrzebuje lokalnego konta (lub konta katalogowego), na które się loguje.
Maszyna z Linuksem musi mieć dostęp do proxy na porcie UDP 1812. Hasło jest przesyłane między nimi jako PAP, dlatego należy utrzymywać tę komunikację w sieci zarządzającej albo uruchomić skonteneryzowane proxy bezpośrednio na tym hoście.

Krok 0: Najpierw przygotowanie wyjścia awaryjnego

Zanim zaczną Państwo modyfikować PAM, należy upewnić się, że działa czysto lokalne logowanie: nadać kontu root (lub osobnemu awaryjnemu administratorowi typu break-glass) silne lokalne hasło i sprawdzić je na konsoli. Poniższa konfiguracja zawsze wraca do lokalnych haseł, więc to konto będzie Państwa drogą wejścia, jeśli proxy, serwer RADIUS lub sieć kiedykolwiek przestaną działać. Należy to zrobić najpierw, a nie dopiero po awarii.

Krok 1: Instalacja modułu

sudo apt-get install libpam-radius-auth

Krok 2: Skierowanie modułu na proxy

Należy otworzyć plik /etc/pam_radius_auth.conf i dodać jedną linię – adres proxy, współdzielony sekret (odpowiadający wartości vpn_secret_in w proxy) oraz limit czasu w sekundach:

# server[:port]    shared_secret            timeout (s)
10.0.1.20          secret_to_radius_server  60

Następnie należy ograniczyć uprawnienia do pliku, ponieważ zawiera on sekret:

sudo chmod 0600 /etc/pam_radius_auth.conf

Limit czasu to ta sama pułapka co wszędzie indziej w tej serii. Domyślnie moduł ustawia 3 sekundy: wystarczające do sprawdzenia hasła, beznadziejne przy zatwierdzaniu przez człowieka. Należy ustawić go na co najmniej wartość vpn_message_ttl proxy (30 s); 60 daje wygodny zapas.

Krok 3: Włączenie modułu w PAM

Dla każdego punktu wejścia, który ma być chroniony, należy dodać jedną linię bezpośrednio nad linią @include common-auth. Dla SSH:

sudo nano /etc/pam.d/sshd

auth sufficient pam_radius_auth.so
@include common-auth

sufficient oznacza: jeśli RADIUS odpowie Access-Accept (hasło zweryfikowane po stronie docelowej oraz push zatwierdzony), logowanie od razu się powiedzie. W przeciwnym razie PAM przechodzi do zwykłego sprawdzenia lokalnego hasła poniżej.

Tę samą linię należy dodać do dowolnego z poniższych, według potrzeb:

/etc/pam.d/login dla logowań z konsoli
/etc/pam.d/sudo – każde sudo pyta telefon (mocne zabezpieczenie, ale uciążliwe; pamięć podręczna danych logowania sudo sprawia, że pozostaje znośne)
/etc/pam.d/su do przełączania użytkowników

Na koniec należy otworzyć plik /etc/pam.d/common-auth i dodać try_first_pass do istniejącej linii pam_unix.so:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

(Pozostałe opcje w tej linii różnią się w zależności od wydania; dodawana jest tylko opcja try_first_pass.) Bez niej użytkownik korzystający z awaryjnego uwierzytelniania lokalnego zostaje poproszony o hasło po raz drugi; z nią już wpisane hasło jest po cichu wykorzystywane ponownie.

Krok 4: Sprawdzenie, czy sshd rzeczywiście używa PAM

W pliku /etc/ssh/sshd_config uwierzytelnianie oparte na PAM wymaga:

UsePAM yes
KbdInteractiveAuthentication yes

(oba są ustawieniami domyślnymi w Debianie/Ubuntu). Warto wiedzieć jedno: logowanie SSH kluczem publicznym całkowicie pomija fazę uwierzytelniania PAM, więc logowanie oparte na kluczu nie wyzwoli powiadomienia push. Jeśli chcą Państwo mieć klucz oraz push, należy ustawić AuthenticationMethods publickey,keyboard-interactive, ale ten wariant warto przetestować osobno, zanim wdrożą go Państwo na produkcji.

Krok 5: Utworzenie użytkowników korzystających wyłącznie z push

Oto sztuczka, dzięki której konfiguracja jest czysta: użytkowników tworzy się bez lokalnego hasła.

sudo useradd -m -G sudo john

Bez późniejszego polecenia passwd lokalne hasło konta pozostaje zablokowane. Taki użytkownik ma teraz dokładnie jedną drogę wejścia: RADIUS przez proxy, czyli hasło oraz zatwierdzenie na telefonie. Nie ma niczego lokalnego, co można by złamać atakiem siłowym. Awaryjny administrator z kroku 0 pozostaje jedynym kontem z czysto lokalnym hasłem.

Ostrożne testowanie

Nie zamykając działającej sesji, należy zalogować się przez SSH z drugiego terminala, używając nazwy użytkownika RADIUS:

Monit o hasło zachowuje się jak zwykle; po jego wpisaniu sesja czeka: to proxy utrzymuje wymianę otwartą.
Powiadomienie push pojawia się na telefonie. Zatwierdzenie → powłoka. Odrzucenie lub zignorowanie → logowanie kończy się niepowodzeniem po upływie limitu czasu.
Należy upewnić się, że konto awaryjne nadal loguje się swoim lokalnym hasłem.

Pierwotną sesję należy zamknąć dopiero po pomyślnym przejściu obu testów.

Rozwiązywanie problemów

Logowanie kończy się natychmiast niepowodzeniem, brak push. Limit czasu w /etc/pam_radius_auth.conf wciąż ma domyślne 3 sekundy albo sekret nie zgadza się z wartością vpn_secret_in proxy.
Brak push, ale występuje oczekiwanie. Niezgodność nazwy użytkownika między RADIUS a usługą Notakey albo telefon nie został zarejestrowany w tej aplikacji.
Pytanie o hasło pojawia się dwa razy. W linii pam_unix w pliku common-auth brakuje opcji try_first_pass.
Logowania SSH kluczem nie generują push. To normalne; uwierzytelnianie kluczem publicznym pomija fazę uwierzytelniania PAM (zob. krok 4).

Gdzie to znajduje zastosowanie

Jedno proxy, jeden serwer RADIUS – a teraz VPN, warstwa administracyjna routera i cała Państwa flota maszyn z Linuksem wymagają zatwierdzenia na telefonie. Wszystko, co posługuje się protokołem RADIUS lub PAM, może dołączyć do tej samej konfiguracji.

Powiązane przewodniki

2FA dla VPN z RADIUS – pełna konfiguracja auth-proxy: konfiguracja proxy, na której opiera się ten przewodnik
2FA dla logowania do routera MikroTik: ten sam wzorzec dla logowania WinBox/SSH samego routera