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

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

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

auth required pam_google_authenticator.so nullok

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…