Po pewnej przerwie wracam(y) do tematów związanych – mniej lub bardziej bezpośrednio – z bezpieczeństwem (zabezpieczaniem) serwerów (dedykowane, VPS, Raspberry Pi).
W tym wpisie postaram się pokazać, jak można zabezpieczyć proces logowania do systemu przez SSH/SCP za pomocą dodatkowego składnika uwierzytelniającego – jednorazowego kodu generowanego przez programowy token, który będzie wymagany do za zalogowania się do systemu (oczywiście oprócz loginu i hasła).
Spis treści w artykule
Logowanie do systemu przez SSH/SCP z Google Authenticator (2FA)
Standardowo by zalogować się do do zdalnego systemu przez SSH/SCP wystarczy podać nazwę użytkownika i hasło – i z racji tego, że są to dane stałe (oczywiście hasło można zmienić, ale chyba nikt nie zmienia hasła po każdym logowaniu ;-)), to można założyć, że mogą zostać przejęte przez osoby postronne, które zdecydowanie nie powinny móc się zalogować do naszego systemu.
By temu przeciwdziałać do procesu logowani dołożymy jeszcze jeden element – znany choćby z bankowości mobilnej kod jednorazowy, który jednak nie będzie przychodził do nas SMSem, a będzie generowany przez specjalną aplikację, zgodną ze standardem wykorzystywanym w mechanizmie Google Authenticator (OATH – Initiative for Open Authentication), który zostanie wykorzystany w tym poradniku.
Programowy token
Aplikacji które można w tym celu wykorzystać jest całkiem sporo – choćby Google Authenticator (Android, iOS, BlackBerry), czy Authy (Android, iOS, oraz Linux, Windows, OSX jako dodatek do przeglądarki Chrome), którą to aplikacje osobiście preferuje, choćby ze względu na synchronizację skonfigurowanych kont (tokenów) między różnymi urządzeniami (od razu zdradzę, że usługa Authy pojawi się jeszcze przynajmniej raz, przy okazji jednego z zaplanowanych wpisów o alternatywnej metodzie do opisanej w tym wpisie).
W telefonie możecie ustawić „czas operatora”, w komputerze z systemem Windows czas pewnie też macie synchronizowany zdalnie.
Instalacja na przykładzie systemu Debian
Instalacja aplikacji (modułu PAM) nienależny do specjalnie skomplikowanych/trudnych czynności, a to dzięki temu, że odpowiednie pliki znajdziemy w repozytoriach systemu Debian, a więc wystarczy skorzystać z polecenia:
sudo apt-get install libpam-google-authenticator
Choć oczywiście nic nie stoi na przeszkodzie, by bardziej zaawansowani (lub korzystających z innych dystrybucji/systemów) użytkownicy skompilowanie odpowiedni pakiet wprost ze źródeł.
Tworzenie/konfigurowanie tokena
Po instalacji – a jeszcze przed konfiguracją SSH – możemy przystąpić do tworzenia (konfigurowania) tokenów dla poszczególnych użytkowników. W tym celu wystarczy skorzystać z polecenia:
google-authenticator
W tym momencie zostanie wyświetlony kod QR który wystarczy zeskanować za pomocą wybranej aplikacji:
W sytuacji gdy z jakiś przyczyn nie możecie zeskanować kodu QR (np. nie mieści się na ekranie), możecie dodać do aplikacji konto wpisując ręcznie „secret key” (na powyższym przykładzie jest to XHAOGG4EQACDI7X2).
Kod QR możecie wygenerować również w przeglądarce, korzystając z adresu:
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/[NAZWA]%3Fsecret%3D[KOD]
W miejsce [NAZWA] wystarczy wstawić nazwę jaką chcecie przypisać do konta w aplikacji, a wygenerowany „secret key” wstawcie zamiast znacznika [KOD].
Dodatkowo zostanie wygenerowanych 5 kodów zapasowych – do wykorzystania w sytuacji gdybyście akurat nie mieli dostępu np. do telefonu, dzięki czemu w takiej sytuacji będzie możliwe awaryjne zalogowanie się do systemu.
Na koniec jeszcze kilak odpowiedzi tak/nie (yes/no), zależnie od Waszych preferencji (np. y, y, n, y) i token/konto jest skonfigurowane.
Konfiguracja usługi SSH
Gdy wszyscy użytkownicy korzystający z połączenia SSH/SCP mają wygenerowane i skonfigurowane opcje dotyczące autoryzacji (generowanie kodów jednorazowych) można przystąpić do konfiguracji samej usługi SSH, tak by kody jednorazowe były wymagane do zalogowania się do systemu.
sudo nano /etc/pam.d/sshd
I dodajmy – np. na samym dole – linijkę:
auth required pam_google_authenticator.so
Przed tą modyfikacją aktywujcie/wygenerujcie token dla każdego użytkownika w systemie, ew. skorzystajcie z parametru „nullok”, który włączy podwójne uwierzytelnienie tylko dla użytkowników którzy mają taką autoryzację skonfigurowaną:
auth required pam_google_authenticator.so nullok
Ale jeśli nic się nie zmieniło w ostatnim czasie, to w wersji instalowanej z repozytoriów Debiana (przynajmniej Debian Wheezy, bo wtedy ostatni raz testowałem ten parametr) nie jest on obsługiwany, i jeśli ktoś z Was koniecznie musi z tego korzystać, to prawdopodobnie będzie potrzebna kompilacja wprost ze źródeł.
Na koniec jeszcze jedna, mała zmiana w kolejnym pliku:
sudo nano /etc/ssh/sshd_config
Gdzie zmieniamy:
ChallengeResponseAuthentication no
na:
ChallengeResponseAuthentication yes
PasswordAuthentication no
Gdy wszystko gotowe – wystarczy restart usługi SSH:
sudo /etc/init.d/ssh restart
Od tego momentu przy logowaniu oprócz nazwy użytkownika i hasła trzeba będzie podać kod jednorazowy, wygenerowany przez token.
Wykluczenia, czyli np. w sieci LAN bez 2FA
Możemy też utworzyć listę wyjątków, na której można umieścić adresy IP (lub całe zakresy), z których połączenie nie będzie wymagało podania kodów jednorazowych.
O ile w przypadków np. serwera VPS jest raczej mało prawdopodobne (choć możliwe) byśmy łączyli się z nim w ramach sieci LAN, to już np. w przypadku Raspberry Pi jest to dość prawdopodobne, i być może w takiej sytuacji zdecydujecie się właśnie na dodanie swojego adresu lokalnego do listy wyjątków (oczywiście w przypadku zdalnego serwera VPS również – jeśli chcecie – możecie dodać do wyjątków np. Wasz publiczny i stały adres IP).
W takim przypadku wracamy do edycji pliku „/etc/pam.d/sshd”:
sudo nano /etc/pam.d/sshd
i wcześniej dodany wpis:
auth required pam_google_authenticator.so
zmieniamy na:
auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf
W kolejnym kroku musimy jeszcze przygotować plik „access-local.conf”:
sudo nano /etc/security/access-local.conf
Np. o takiej treści/zawartości:
+ : ALL : LOCAL
+ : ALL : 123.124.125.126
+ : ALL : 192.168.1.0/24
+ : ALL : 192.168.0.0/255.255.0.0
- : ALL : ALL
W powyższym przykładzie mamy 3 wyjątki:
- Logowanie z adresu IP 123.124.125.126
- Logowanie w ramach sieci LAN, z urządzeń o adresie IP 192.168.1.1-192.168.1.254
- Logowanie w ramach sieci LAN, z urządzeń o adresie IP 192.168.0.1-192.168.255.254
Wyjątków można tworzyć wiele – od pojedynczych adresów IP, po całe zakresy…
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01