P
odczas pierwszego łączenia się z wybranym serwerem klient SSH poprosi użytkownika o weryfikację autentyczności tego serwera. Jest to zasada zwana TOFU – Trust On First Use – przy pierwszym połączeniu zakładamy lub weryfikujemy, iż jest ono prawidłowe, a jeżeli później coś się zmieni w łączności, będzie to podejrzane i wygeneruje ostrzeżenia. Z obserwacji zachowań użytkowników systemów *nix wynika, iż wielu z nich po prostu na ślepo odpowiada: "Yes / Tak", nie biorąc pod uwagę potencjalnych zagrożeń bezpieczeństwa. Osoba, która jest w stanie przejąć sieciowo komunikację może przeprowadzić atak man-in-the-middle (MITM) prowadzący do wycieku danych uwierzytelniających lub przejęcia sesji użytkownika. Zgodnie z RFC 4251 istnieje kilka sposobów na weryfikację “odcisku palca” (ang. fingerprint) klucza serwera.
Pierwszym sposobem jest ręczna weryfikacja.
Użytkownik musi porównać odcisk palca klucza serwera (taki jak: SHA256:CHFioX...) z odciskiem jaki przekazał mu administrator serwera. Podejście to niesie ze sobą nakład komunikacyjny innym kanałem oraz ryzyko ludzkiego błędu przy porównywaniu odcisków ze sobą lub choćby na poziomie ich przekazywania. Drugim sposobem jest automatyczne wykorzystanie urzędu certyfikacji do weryfikacji odcisków klucza. Jednak to podejście wymaga wdrożenia klucza głównego urzędu certyfikacji na wszystkich urządzeniach użytkowników (lub tzw. jump serwerze|hoście|boksie) i podpisania nimi wszystkich kluczy serwerów. Podejście to może nie być osiągalne lub odpowiednie w niektórych środowiskach – dlatego na razie pominiemy je w tej publikacji. Innym podejściem, które opiszę bardziej szczegółowo jest dystrybucja odcisków kluczy za pośrednictwem specjalnego rekordu DNS. Eliminuje to wszelkie interakcje użytkownika, potencjalne błędy ludzkie lub domniemaną konfigurację serwera, ponieważ klient OpenSSH sam może zapytać serwer DNS i dokonać porównania posiadanych danych. Metoda ta wymaga jedynie od administratora opublikowania odcisków kluczy serwera jako zestawu rekordów SSHFP, które można bezpiecznie uzyskać dzięki DNSSEC. jeżeli wszystkie te warunki zostaną poprawnie zachowane to można w prosty sposób zmniejszyć ryzyko ataku MITM.
RFC 4255 opisuje schemat rekordu SSHFP. Wygląda on następująco:
SSHFP [NUMER-ALGORYTMU> [TYP-ODCISKU] [ODCISK]Numer algorytmu – jest liczbą reprezentującą algorytm klucza:
0 Zarezerwowany 1 RSA 2 DSA 3 ECDSA 4 ED25519 5 Nieprzypisany 6 ED448Typ odcisku – definiuje użyty algorytm funkcji skrótu:
0 Zarezerwowany 1 SHA1 2 SHA256Odcisk – to szesnastkowa deklaracja skrótu np.:
f9d58b3ec174492ffde19b5156307faa4416af6cGenerowanie rekordów SSHFP:
W celu utworzenia rekordów SSHFP dla serwera, którego jesteśmy administratorem należy zalogować się na konsolę i uruchomić następujące polecenie (zastępując przykładową nazwę darkstar na w pełni kwalifikowaną nazwę domenową (FQDN) swojego serwera):
ssh-keygen -r darkstar
-r hostname
Print the SSHFP fingerprint resource record named hostname for the specified public key file.
FQDN powinien być taki sam jak rekord “A” w domenie, który wskazuje na adres IP serwera. Polecenie należy uruchomić z poziomu serwera dla którego chcemy dodać rekordy SSHFP, ponieważ są one generowane z klucza publicznego serwera SSH.
darkstar IN SSHFP 1 1 f9d58b3ec174492ffde19b5156307faa4416af6c darkstar IN SSHFP 1 2 f0ce10d4f4ce810ff6ff969157dca554d3d4dcd33a3bdf6fefa683f300f59191 darkstar IN SSHFP 2 1 19dc498cd7aa0b55cbbf06c0b9c55acecd9c49dc darkstar IN SSHFP 2 2 ac9c770edcc285b0398f77aa8b1d0006b14c06a0563a59d75ff9654f20d8de39 darkstar IN SSHFP 3 1 2a267b58b877ddc5ed3810b389d3ed6cf160c8a4 darkstar IN SSHFP 3 2 cdc681c1eebeb88349362a13c90d46a4e707eb7bc9e570ef8cae7af5332245a3 darkstar IN SSHFP 4 1 af9601f0c1a50edc06954c685e22dded738d6d76 darkstar IN SSHFP 4 2 087162a17261aa7d94d18e685211ce7a69943343db0641fd12497864821d3437Istnieje również polecenie, które wykona tę samą czynność “zdalnie” bez konieczności logowania się na serwer – jedynym warunkiem jest łączność między klientem, a serwerem SSH:
ssh-keyscan -D darkstar
-D Print keys found as SSHFP DNS records.
The default is to print keys in a format usable as a ssh(1) known_hosts file.
Jak możemy się przekonać metoda ta pominęła klucze DSA, które począwszy od wydania 7.0 OpenSSH zostały domyślnie wyłączone z powodu ich słabości. Używanie odcisków wygenerowanych dzięki SHA-1 również możemy pominąć przy dodawaniu rekordów DNS, ponieważ są one mniej bezpieczne.
Dodawanie i weryfikacja rekordów SSHFP:
Wygenerowane rekordy SSHFP dzięki polecenia ssh-keygen|ssh-keyscan powinniśmy dodać do rekordów DNS swojej domeny, która jest przypisana do danego serwera. Dla każdej linii należy utworzyć nowy rekord SSHFP. Pamiętajmy, iż rekordy SSHFP są godne zaufania tylko wtedy, gdy nasz serwer DNS obsługuje DNSSEC. Rozpowszechnienie rekordów DNS w internecie może zająć trochę czasu, ale czy nowe rekordy SSHFP są już aktywne możemy sprawdzić dzięki polecenia dig (pakiet: dnsutils):
dig SSHFP darkstar +shortlub
dig SSHFP darkstar +noall +answer darkstar. 30 IN SSHFP 1 2 F0CE10D4F4CE810FF6FF969157DCA554D3D4DCD33A3BDF6FEFA683F3 00F59191 darkstar. 30 IN SSHFP 2 1 19DC498CD7AA0B55CBBF06C0B9C55ACECD9C49DC darkstar. 30 IN SSHFP 2 2 AC9C770EDCC285B0398F77AA8B1D0006B14C06A0563A59D75FF9654F 20D8DE39 darkstar. 30 IN SSHFP 3 1 2A267B58B877DDC5ED3810B389D3ED6CF160C8A4 darkstar. 30 IN SSHFP 3 2 CDC681C1EEBEB88349362A13C90D46A4E707EB7BC9E570EF8CAE7AF5 332245A3 darkstar. 30 IN SSHFP 4 1 AF9601F0C1A50EDC06954C685E22DDED738D6D76 darkstar. 30 IN SSHFP 4 2 087162A17261AA7D94D18E685211CE7A69943343DB0641FD12497864 821D3437 darkstar. 30 IN SSHFP 1 1 F9D58B3EC174492FFDE19B5156307FAA4416AF6CSprawdzenie łączności do serwera SSH:
Klient OpenSSH domyślnie nie weryfikuje rekordów SSHFP chociaż funkcja ta jest wdrożona od wielu lat. Możemy to zmienić poprzez plik konfiguracyjny ~/.ssh/config i opcję:
Host * VerifyHostKeyDNS yeslub aktywować ją z linii poleceń:
$ ssh -o VerifyHostKeyDNS=yes -l agresor -v [...] debug1: Connecting to someserver.tld [10.10.0.1] port 22. debug1: Connection established. [...] debug1: Server host key: ssh-ed25519 SHA256:xCHFioXJhqn2U0Y5oUhHOemmUM0PbBkH9Ekl4ZIIdNDc debug1: found 8 secure fingerprints in DNS debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1 debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2 debug1: matching host key fingerprint found in DNS [...] agresor@darkstar's password:Jak widać OpenSSH nawiązuje połączenie z serwerem, uzyskuje odcisk klucza serwera i następnie wysyła zapytanie do domeny o rekordy SSHFP, aby je porównać. jeżeli odciski zostały przekazane bezpiecznym kanałem i pasują do siebie połączenie jest kontynuowane. jeżeli podczas próby połączenia otrzymamy następujący komunikat:
[...] debug1: Server host key: ssh-ed25519 SHA256:CHFioXJhqn2U0Y5oUhHOemmUM0PbBkH9Ekl4ZIIdNDc debug3: verify_host_key_dns debug1: found 8 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS [...] The authenticity of host 'darkstar (10.0.0.1)' can't be established. ED25519 key fingerprint is SHA256:CHFioXJhqn2U0Y5oUhHOemmUM0PbBkH9Ekl4ZIIdNDc. Matching host key fingerprint found in DNS. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])?Oznacza to, iż rekordy zostały dodane do strefy DNS i klient OpenSSH je odnalazł, ale występuje problem z weryfikacją ich dzięki DNSSEC. W takim wypadku należy sprawdzić czy DNSSEC jest poprawnie skonfigurowany np. dzięki takich narzędzi jak DNSViz, DNSSEC Debugger lub po prostu poleceniem delv:
delv +yaml darkstarPolecenie powinno zwrócić:
type: DELV_RESULT query_name: darkstar status: success records: - fully_validated: - darkstar. 2643 IN A 10.0.0.1 - darkstar. 2643 IN RRSIG A 8 2 3600 20240328203421 20240227203421 18138 darkstar. AksdfwwFfLebLSIHozYUDW1sRBqgxSZa7LKkSCNNzpGOHp8lj4ZlSb7/ 236py2aBX85aG7QMkzLdH+qZgu5YDC8G9rZxrm5qe90pZdsyeRFRJrG9 nOhZpGqz15pwODg/0DBKTHd/Yt3/Q9B1502pVDkKBrDy9Q5U6ockdJs+ TTQ=Inne komunikaty ujęte w komentarz “;;” np. ;; unsigned answer lub ;; broken trust chain mogą świadczyć o złej konfiguracji serwera lub klienta, który odpytuje domenę o rekordy SSHFP. Jest to równie ważne, aby serwer, jak i klient były w stanie poprawnie obsługiwać odpowiedzi i zapytania przy użyciu DNSSEC.
Podsumowanie:
Rekordy SSHFP mogą współistnieć z kluczami SSH przechowywanymi w plikach known_hosts. Kiedy klient łączy się z serwerem SSH, sprawdza zarówno rekord SSHFP w DNS (jeśli jest dostępny), jak i plik known_hosts, aby zweryfikować odcisk klucza serwera. jeżeli odcisk klucza pasuje w którymkolwiek źródle, połączenie jest kontynuowane; w przeciwnym razie klient powiadomi użytkownika odpowiednim ostrzeżeniem z pytaniem czy ma zezwolić lub odmówić połączenia. Przy większej liczbie serwerów, z którymi komunikujemy się poprzez protokół SSH znacznie łatwiej jest zarządzać rekordami DNS niż ręczną weryfikacją poprawności odcisków kluczy. W dodatku zmiana klucza danego serwera może być automatycznie wdrożona i rozpropagowana używając odpowiednio niskiego TTL (ang. Time to Live).
Więcej informacji: Improving SSH’s security with SSHFP DNS records, Use SSHFP Records to Verify SSH Host Keys
