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

Ten sam Notakey auth-proxy, który chroni już twój 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 utrzymuj tę komunikację w sieci zarządzającej albo uruchom skonteneryzowane proxy bezpośrednio na tym hoście.

Krok 0: Najpierw przygotuj wyjście awaryjne

Zanim zaczniesz modyfikować PAM, upewnij się, że działa czysto lokalne logowanie: nadaj kontu root (lub osobnemu awaryjnemu administratorowi typu break-glass) silne lokalne hasło i sprawdź je na konsoli. Poniższa konfiguracja zawsze wraca do lokalnych haseł, więc to konto będzie twoją drogą wejścia, jeśli proxy, serwer RADIUS lub sieć kiedykolwiek przestaną działać. Zrób to najpierw, a nie dopiero po awarii.

Krok 1: Zainstaluj moduł

sudo apt-get install libpam-radius-auth

Krok 2: Skieruj go na proxy

Otwórz plik /etc/pam_radius_auth.conf i dodaj 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 ogranicz 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. Ustaw go na co najmniej wartość vpn_message_ttl proxy (30 s); 60 daje wygodny zapas.

Krok 3: Włącz go w PAM

Dla każdego punktu wejścia, który chcesz chronić, dodaj 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.

Dodaj tę samą linię 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 otwórz plik /etc/pam.d/common-auth i dodaj 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: Sprawdź, 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 chcesz mieć klucz oraz push, ustaw AuthenticationMethods publickey,keyboard-interactive, ale przetestuj ten wariant osobno, zanim wdrożysz go na produkcji.

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

Oto sztuczka, dzięki której konfiguracja jest czysta: twórz użytkowników 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.

Przetestuj ostrożnie

Nie zamykaj swojej działającej sesji i zaloguj 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. Zatwierdź → powłoka. Odrzuć lub zignoruj → logowanie kończy się niepowodzeniem po upływie limitu czasu.
Upewnij się, że konto awaryjne nadal loguje się swoim lokalnym hasłem.

Zamknij pierwotną sesję 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 (zobacz krok 4).

Gdzie to znajduje zastosowanie

Jedno proxy, jeden serwer RADIUS – a teraz VPN, warstwa administracyjna routera i cała twoja 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