AAA: Uwierzytelnianie w Praktyce – Linux i RouterOS

Witaj w kolejnej części naszej podróży po świecie cyberbezpieczeństwa! W poprzednim artykule omówiliśmy teorię uwierzytelniania, poznając trzy kluczowe faktory. Dzisiaj przechodzimy od teorii do twardej praktyki. Skupimy się na dwóch niezwykle popularnych systemach: Linux – sercu niezliczonych serwerów, oraz RouterOS – mózgu urządzeń sieciowych MikroTik. Zaczniemy od najprostszej metody, czyli loginu i hasła, by następnie przejść do znacznie potężniejszych i bezpieczniejszych mechanizmów: certyfikatów SSH oraz centralnego uwierzytelniania za pomocą serwera RADIUS.

Ten artykuł ma formę praktycznego tutorialu. Krok po kroku pokażę Ci, jak skonfigurować każdą z metod, wyjaśniając przy tym, co dzieje się „pod maską”. Przygotuj swoją konsolę – zaczynamy!

---

Część 1: Podstawowe uwierzytelnianie Login/Hasło

To najprostsza i najbardziej intuicyjna forma weryfikacji tożsamości. Użytkownik podaje swój identyfikator (login) oraz sekret (hasło). System porównuje hash podanego hasła z hashem zapisanym w swojej lokalnej bazie danych. Mimo że ma swoje wady, jest to fundament, od którego wszystko się zaczyna.

SSH w Linux: Klasyczne podejście

Gdy łączysz się z serwerem Linux przez SSH używając hasła, zachodzi prosty, lecz elegancki proces. Twój klient SSH inicjuje bezpieczne, szyfrowane połączenie, a następnie serwer (demon sshd) prosi o poświadczenia. Po ich otrzymaniu, system operacyjny weryfikuje je, porównując z danymi w plikach /etc/passwd i /etc/shadow.

+----------------+                            +-----------------+
|  Klient SSH    |                            |  Serwer Linux   |
| (Twój laptop)  |                            | (demon sshd)    |
+----------------+                            +-----------------+
        |                                             |
        |------------[1. Nawiązanie połączenia]------>|
        |                                             |
        |<-----------[2. Prośba o login/hasło]--------|
        |                                             |
        |----[3. Przesłanie poświadczeń (szyfrowane)]->|
        |                                             |
        |                                             |---[4. Weryfikacja]
        |                                             |   (z /etc/shadow)
        |                                             |
        |<-----------[5. Odpowiedź: OK/Błąd]----------|
        |                                             |

Logowanie z konsoli wygląda standardowo:

user@local:~$ ssh admin@192.168.1.10
admin@192.168.1.10's password: ********
Welcome to Ubuntu 22.04.1 LTS ...
admin@server:~$ 

RouterOS: Dostęp do serca sieci

W RouterOS tworzenie lokalnego użytkownika z hasłem to podstawowa czynność administracyjna. Taki użytkownik może logować się przez Winbox, WebFig czy SSH. Mechanizm jest podobny – RouterOS przechowuje listę użytkowników i hashy ich haseł w swojej konfiguracji.

Tworzenie nowego użytkownika „audytor” z prawami tylko do odczytu:

[admin@MikroTik] > user add name=audytor group=read password=BardzoSilneHasloAudytora!
# Użytkownik zostaje utworzony i może się zalogować.

+----------------+                            +-----------------+
|  Administrator |                            | Router MikroTik |
| (Winbox/SSH)   |                            |   (RouterOS)    |
+----------------+                            +-----------------+
        |                                             |
        |------------[1. Próba logowania]------------>|
        |         (login: 'audytor',                  |
        |          hasło: '*********')                |
        |                                             |
        |                                             |---[2. Weryfikacja]
        |                                             | (z lokalną bazą)
        |                                             |
        |<-----------[3. Zalogowano/Odmowa]-----------|
        |                                             |

---

Część 2: Uwierzytelnianie certyfikatami SSH w Linux

Dlaczego to lepsze niż klucze? W poprzednim artykule omówiliśmy uwierzytelnianie za pomocą pary kluczy SSH. To świetne rozwiązanie, ale w dużej infrastrukturze staje się problematyczne. Każdy administrator musi rozesłać swój klucz publiczny na wszystkie serwery, do których potrzebuje dostępu. Odwołanie dostępu wymaga usunięcia klucza z każdego serwera z osobna. Certyfikaty rozwiązują ten problem.

W modelu z certyfikatami tworzymy centralny Urząd Certyfikacji (Certificate Authority – CA). Serwery są konfigurowane tak, aby ufały tylko jednemu kluczowi – publicznemu kluczowi naszego CA. Następnie CA podpisuje klucze publiczne użytkowników, tworząc certyfikaty. Użytkownik loguje się, przedstawiając swój klucz prywatny i podpisany certyfikat. Serwer, widząc, że certyfikat jest podpisany przez zaufane CA, wpuszcza użytkownika.

+------------------------+      +---------------------+      +---------------------+
|      Klucz CA          |      | Klucz publiczny     |      |    Certyfikat SSH   |
| (prywatny + publiczny) |  +   |      Użytkownika    |  =   | (podpisany klucz pub) |
|   (strzeżony!)         |      |   (id_rsa.pub)      |      | (krótki czas życia) |
+------------------------+      +---------------------+      +---------------------+

Krok 1: Tworzenie kluczy dla Urzędu Certyfikacji (CA)

Na bezpiecznej, odizolowanej maszynie (może to być nawet Twój laptop) generujemy parę kluczy dla naszego CA. Ten klucz prywatny będzie służył do podpisywania kluczy użytkowników – chroń go jak oka w głowie!

user@ca-machine:~$ mkdir -p ~/.ssh/ca && cd ~/.ssh/ca
user@ca-machine:~/.ssh/ca$ ssh-keygen -t rsa -b 4096 -f user_ca -C "User Certificate Authority"
# Zostaną utworzone dwa pliki: user_ca (klucz prywatny) i user_ca.pub (klucz publiczny).

Krok 2: Konfiguracja serwera SSH, aby ufał naszemu CA

Teraz musimy poinformować nasze serwery docelowe, że mają ufać certyfikatom podpisanym przez nasze nowo utworzone CA. W tym celu kopiujemy publiczny klucz CA (user_ca.pub) na każdy serwer i dodajemy jedną linijkę do konfiguracji demona SSH.

1. Skopiuj user_ca.pub na serwer, np. do /etc/ssh/ca.pub.

user@ca-machine:~/.ssh/ca$ scp user_ca.pub admin@192.168.1.10:/tmp/ca.pub
admin@server:~$ sudo mv /tmp/ca.pub /etc/ssh/ca.pub

2. Edytuj plik /etc/ssh/sshd_config i dodaj na końcu:

# Ufaj certyfikatom podpisanym przez ten klucz CA
TrustedUserCAKeys /etc/ssh/ca.pub

3. Zrestartuj demona SSH, aby załadować nową konfigurację:

admin@server:~$ sudo systemctl restart sshd

Krok 3: Podpisywanie klucza publicznego użytkownika

Użytkownik, który chce uzyskać dostęp (np. deweloper Jan), musi najpierw wygenerować swoją własną parę kluczy SSH (jeśli jeszcze jej nie ma) i przesłać swój klucz publiczny do administratora CA.

jan@laptop:~$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "jan.kowalski@firma.com"
# Jan wysyła plik ~/.ssh/id_rsa.pub do administratora.

Administrator CA, mając klucz publiczny Jana, podpisuje go za pomocą klucza prywatnego CA. To jest serce całego procesu.

user@ca-machine:~/.ssh/ca$ ssh-keygen -s user_ca -I "certyfikat_jana" -n root,admin -V +1d jan_id_rsa.pub

Co oznaczają te flagi?

• -s user_ca: Podpisz używając tego klucza prywatnego CA.
• -I "certyfikat_jana": Unikalny identyfikator certyfikatu (ważny dla logów).
• -n root,admin: Najważniejsze! Określa, jako jacy użytkownicy (principals) Jan może logować się na serwerach. W tym przypadku jako ‚root’ i ‚admin’.
• -V +1d: Określa ważność certyfikatu. Tu: tylko jeden dzień. Świetne do tymczasowego dostępu!
• jan_id_rsa.pub: Klucz publiczny Jana, który podpisujemy.

W wyniku tej operacji powstaje plik jan_id_rsa-cert.pub. Administrator odsyła ten plik z powrotem do Jana. Jan musi umieścić go w tym samym katalogu, w którym ma swój klucz prywatny (~/.ssh/).

Krok 4: Logowanie za pomocą certyfikatu

Jan może teraz zalogować się na serwer. Jego klient SSH automatycznie znajdzie certyfikat (id_rsa-cert.pub) i przedstawi go razem ze swoim kluczem publicznym serwerowi.

+--------------+                                           +----------------+
|  Laptop Jana |                                           |  Serwer Docelowy |
+--------------+                                           +----------------+
       |                                                            |
       |---[1. SSH Login Request]---------------------------------->|
       |  (Klucz publiczny Jana + Certyfikat podpisany przez CA)    |
       |                                                            |
       |                                                            |---[2. Weryfikacja]
       |                                                            |  a) Czy certyfikat jest ważny? (czas)
       |                                                            |  b) Czy jest podpisany przez zaufane CA?
       |                                                            |     (porównanie z /etc/ssh/ca.pub)
       |                                                            |  c) Czy użytkownik ('admin') jest
       |                                                            |     dozwolony w certyfikacie?
       |                                                            |
       |<-------------------[3. DOSTĘP ZEZWOLONY]-------------------|
       |                                                            |

W praktyce logowanie wygląda tak samo jak zwykle:

jan@laptop:~$ ssh admin@192.168.1.10
Welcome to Ubuntu 22.04.1 LTS ...
admin@server:~$ 
# Logowanie bez hasła, bez potrzeby posiadania klucza Jana w pliku authorized_keys na serwerze!

Aby odwołać dostęp Janowi, wystarczy nie wydawać mu nowego certyfikatu po wygaśnięciu starego. Nie trzeba nic zmieniać na setkach serwerów!

---

Część 3: Centralne uwierzytelnianie z RADIUS

RADIUS (Remote Authentication Dial-In User Service) to protokół klient-serwer, który umożliwia centralizację uwierzytelniania, autoryzacji i rozliczania (AAA). Urządzenia sieciowe (routery, przełączniki, AP) nie przechowują już poświadczeń lokalnie, lecz odpytują o nie centralny serwer RADIUS. To idealne rozwiązanie do zarządzania dostępem w większych sieciach.

+---------------------+     1. Access-Request      +---------------------+
|   Router MikroTik   | -------------------------> | Serwer RADIUS (Linux) |
| (Klient RADIUS/NAS) | (Użytkownik: 'admin',      | (np. FreeRADIUS)      |
| Chce uwierzytelnić  | Hasło: '********')         |                       |
|      użytkownika    |                            | 2. Weryfikacja        |
+---------------------+     3. Access-Accept/Reject  | (z bazą użytkowników) |
| Otrzymuje odpowiedź |

Krok 1: Instalacja i konfiguracja serwera RADIUS w Linux (FreeRADIUS)

Użyjemy najpopularniejszego serwera RADIUS open-source: FreeRADIUS. Zainstalujemy go na serwerze z systemem Debian/Ubuntu.

1. Instalacja:

admin@radius-server:~$ sudo apt update && sudo apt install freeradius -y

2. Konfiguracja klienta (clients.conf): Musimy poinformować FreeRADIUS, które urządzenia mogą się do niego zwracać z zapytaniami. Edytujemy plik /etc/freeradius/3.0/clients.conf i dodajemy wpis dla naszego routera MikroTik.

# /etc/freeradius/3.0/clients.conf
client mikrotik_glowny {
    ipaddr = 192.168.88.1      # Adres IP naszego routera
    secret = ToJestNaszWspolnySekret  # Hasło (shared secret)
}

3. Konfiguracja użytkownika (users): Teraz dodajmy użytkownika, który będzie mógł się uwierzytelnić. Edytujemy plik /etc/freeradius/3.0/users i dodajemy na górze:

# /etc/freeradius/3.0/users
admin Cleartext-Password := "HasloDlaAdminaZRadusa"
    Service-Type = Login-User

Uwaga: Przechowywanie haseł czystym tekstem jest dobre tylko do testów. W środowisku produkcyjnym hasła powinny być hashowane lub, co lepsze, FreeRADIUS powinien być zintegrowany z bazą danych lub LDAP/Active Directory.

4. Uruchomienie serwera w trybie debugowania: To najlepszy sposób, aby zobaczyć, co się dzieje w czasie rzeczywistym.

admin@radius-server:~$ sudo freeradius -X
... mnóstwo logów startowych ...
Ready to process requests.

Nasz serwer RADIUS jest gotowy i nasłuchuje na przychodzące zapytania.

        Struktura plików FreeRADIUS
        .
        └── /etc/freeradius/3.0/
            ├── clients.conf  (Kto może pytać? [Routery, Switche])
            ├── users         (Kto może się logować? [Użytkownicy])
            ├── mods-available/ (Dostępne moduły: ldap, sql, etc.)
            └── mods-enabled/   (Włączone moduły)

Krok 2: Konfiguracja RouterOS jako klienta RADIUS

Teraz musimy skonfigurować nasz router MikroTik, aby wysyłał zapytania uwierzytelniające do naszego nowego serwera FreeRADIUS.

1. Dodaj serwer RADIUS w konfiguracji RouterOS:

[admin@MikroTik] > radius add service=login address=192.168.88.200 secret="ToJestNaszWspolnySekret"
# Adres IP to nasz serwer Linux z FreeRADIUS
# Sekret musi być identyczny jak w clients.conf!

2. Włącz uwierzytelnianie przez RADIUS dla usług systemowych (logowanie SSH/Winbox):

[admin@MikroTik] > user aaa set use-radius=yes

Krok 3: Testowanie całości

To moment prawdy. Spróbuj zalogować się na router MikroTik (np. przez SSH) używając poświadczeń zdefiniowanych na serwerze RADIUS (użytkownik: `admin`, hasło: `HasloDlaAdminaZRadusa`).

Jeśli wszystko jest skonfigurowane poprawnie, na konsoli serwera FreeRADIUS (działającego w trybie debug) powinieneś zobaczyć coś podobnego:

Received Access-Request Id 0 from 192.168.88.1:1812
    User-Name = "admin"
    NAS-IP-Address = 192.168.88.1
    ...
Found user 'admin' in file /etc/freeradius/3.0/users
...
Login OK: [admin] (from client mikrotik_glowny port 0)
...
Sending Access-Accept Id 0 to 192.168.88.1:1812

A Ty powinieneś zostać pomyślnie zalogowany na swój router. Gratulacje! Właśnie zdecentralizowałeś uwierzytelnianie, przenosząc je z pojedynczego urządzenia do centralnego, łatwego w zarządzaniu serwera.

---

Podsumowanie

Przeszliśmy dziś długą drogę – od prostego logowania hasłem, po zaawansowane, skalowalne i bezpieczne metody uwierzytelniania. Zobaczyliśmy, jak certyfikaty SSH mogą zrewolucjonizować zarządzanie dostępem w dużej flocie serwerów Linux, eliminując chaos związany z plikami authorized_keys. Następnie zbudowaliśmy od podstaw system centralnego uwierzytelniania z wykorzystaniem RADIUS, który pozwala na jednolite zarządzanie poświadczeniami dla urządzeń sieciowych.

Kluczowy wniosek jest jeden: odchodź od lokalnych, rozproszonych metod uwierzytelniania na rzecz rozwiązań centralnych i opartych na silnej kryptografii. To fundament dojrzałej i bezpiecznej infrastruktury IT. W następnym artykule zajmiemy się Autoryzacją – czyli co użytkownik może zrobić, gdy już skutecznie udowodni, kim jest.