Po czterech miesiącach pracy wydanie , otwartą implementację klienta i serwera do pracy z protokołami SSH 2.0 i SFTP.
Kluczowym ulepszeniem w wydaniu OpenSSH 8.2 była możliwość wykorzystania uwierzytelniania dwuetapowego z użyciem urządzeń obsługujących protokół , rozwijanym przez alianse . U2F umożliwia tworzenie niedrogich tokenów sprzętowych do potwierdzania fizycznej obecności użytkownika, z którymi interakcja odbywa się przez USB, Bluetooth lub NFC. Takie urządzenia są promowane jako środek dwuetapowego uwierzytelniania na stronach internetowych, są już obsługiwane przez główne przeglądarki i produkowane przez różnych producentów, w tym Yubico, Feitian, Thetis i Kensington.
Aby wchodzić w interakcje z urządzeniami potwierdzającymi obecność użytkownika, w OpenSSH dodano nowe typy kluczy „ecdsa-sk” i „ed25519-sk”, wykorzystujące algorytmy podpisu cyfrowego ECDSA i Ed25519, w połączeniu z haszowaniem SHA-256. Procedury interakcji z tokenami zostały przeniesione do pośredniej biblioteki, ścigającej się jak biblioteka do obsługi PKCS#11 i będącej nakładką na bibliotekę , która zapewnia środki komunikacji z tokenami przez USB (obsługiwane są protokoły FIDO U2F/CTAP 1 i FIDO 2.0/CTAP 2). Opracowana przez deweloperów OpenSSH pośrednia biblioteka libsk-libfido2 jest częścią libfido2, tak jak dla OpenBSD.
Aby uwierzytelnić się i wygenerować klucz, należy w ustawieniach wskazać parametr „SecurityKeyProvider” lub ustawić zmienną środowiskową SSH_SK_PROVIDER, podając ścieżkę do zewnętrznej biblioteki libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Możliwa jest kompilacja openssh z wbudowaną obsługą biblioteki pośredniej (—with-security-key-builtin), w takim przypadku należy ustawić parametr „SecurityKeyProvider=internal”.
Następnie trzeba uruchomić „ssh-keygen -t ecdsa-sk” lub, jeśli klucze zostały już utworzone i skonfigurowane, połączyć się z serwerem za pomocą „ssh”. Przy uruchamianiu ssh-keygen stworzona para kluczy zostanie zapisana w „~/.ssh/id_ecdsa_sk” i może być używana jak inne klucze.
Klucz publiczny (id_ecdsa_sk.pub) należy skopiować na serwer do pliku authorized_keys. Po stronie serwera weryfikowany jest jedynie podpis cyfrowy, a interakcja z tokenami odbywa się po stronie klienta (nie ma potrzeby instalowania libsk-libfido2 na serwerze, ale serwer musi wspierać typ kluczy „ecdsa-sk”). Wygenerowany klucz prywatny (id_ecdsa_sk) jest w zasadzie uchwytem klucza, tworzącym rzeczywisty klucz tylko w połączeniu z sekretną sekwencją przechowywaną na tokenie U2F. W przypadku, gdy klucz id_ecdsa_sk trafi w ręce atakującego, aby przejść uwierzytelnienie, potrzebny będzie również dostęp do sprzętowego tokena, bez którego zapisany w pliku id_ecdsa_sk klucz prywatny jest bezużyteczny.
Ponadto, domyślnie podczas wykonywania jakichkolwiek operacji z kluczami (zarówno przy generowaniu, jak i przy uwierzytelnianiu) wymagane jest lokalne potwierdzenie fizycznej obecności użytkownika, na przykład poprzez dotknięcie czujnika na tokenie, co utrudnia przeprowadzanie zdalnych ataków na systemy z podłączonym tokenem. Jako dodatkowa warstwa ochrony na etapie uruchamiania ssh-keygen można również ustawić hasło do pliku z kluczem.
W nowej wersji OpenSSH ogłoszono również przyszłe przeniesienie algorytmów korzystających z haszy SHA-1 do kategorii przestarzałych, w związku z efektywności ataków kolizyjnych z określonym prefiksem (koszt wytrychania kolizji szacowany jest na około 45 tysięcy dolarów). W jednym z nadchodzących wydań planowane jest domyślne wyłączenie możliwości korzystania z algorytmu cyfrowych podpisów opartego na publicznym kluczu „ssh-rsa”, który jest wspomniany w oryginalnym RFC dla protokołu SSH i pozostaje szeroko stosowany w praktyce (aby sprawdzić użycie ssh-rsa w swoich systemach, można spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”).
Aby ułatwić przejście na nowe algorytmy w OpenSSH, w jednym z następnych wydań domyślnie włączona zostanie opcja UpdateHostKeys, która automatycznie przeniesie klientów na bardziej niezawodne algorytmy. Wśród zalecanych algorytmów do migracji wymienione są rsa-sha2-256/512 na podstawie RFC8332 RSA SHA-2 (wsparcie od OpenSSH 7.2 i używane domyślnie), ssh-ed25519 (wsparcie od OpenSSH 6.5) oraz ecdsa-sha2-nistp256/384/521 na podstawie RFC5656 ECDSA (wsparcie od OpenSSH 5.7).
W wersji OpenSSH 8.2 możliwość połączenia z użyciem „ssh-rsa” zostaje na razie, jednak ten algorytm został usunięty z listy CASignatureAlgorithms, określającej algorytmy dozwolone dla podpisów cyfrowych nowych certyfikatów. Również z domyślnie obsługiwanych algorytmów wymiany kluczy usunięto algorytm diffie-hellman-group14-sha1. Zauważono, że użycie SHA-1 w certyfikatach wiąże się z dodatkowym ryzykiem, ponieważ atakujący ma nieograniczony czas na wyszukiwanie kolizji dla istniejącego certyfikatu, podczas gdy czas ataku na klucze hosta jest ograniczony czasem przełączenia (LoginGraceTime).
Podczas generowania ssh-keygen domyślnie używany jest teraz algorytm rsa-sha2-512, obsługiwany od OpenSSH 7.2, co może powodować problemy z kompatybilnością przy próbie przetwarzania certyfikatów podpisanych w OpenSSH 8.2 na systemach z wcześniejszymi wersjami OpenSSH (aby obejść problem przy tworzeniu podpisu, można jawnie podać „ssh-keygen -t ssh-rsa” lub użyć algorytmów ecdsa-sha2-nistp256/384/521, obsługiwanych od OpenSSH 5.7).
Inne zmiany:
- W sshd_config dodano dyrektywę Include, która umożliwia dołączanie zawartości innych plików w bieżącym miejscu pliku konfiguracyjnego (przy podawaniu nazwy pliku można stosować maski glob);
- W ssh-keygen dodano opcję „no-touch-required”, która wyłącza konieczność fizycznego potwierdzenia dostępu do tokena przy generowaniu klucza;
- W sshd_config dodano dyrektywę PubkeyAuthOptions, która łączy różne opcje związane z uwierzytelnianiem za pomocą kluczy publicznych. Obecnie obsługiwany jest tylko znacznik „no-touch-required” umożliwiający pominięcie weryfikacji fizycznej obecności przy autoryzacji za pomocą tokena. Na podobnej zasadzie w pliku authorized_keys dodano opcję „no-touch-required”;
- W ssh-keygen dodano opcję „-O write-attestation=/path”, która umożliwia zapisanie dodatkowych certyfikatów atestacyjnych FIDO przy generowaniu kluczy. OpenSSH na razie nie wykorzystuje tych certyfikatów, ale mogą być one później użyte do weryfikacji umiejscowienia klucza w zaufanym sprzętowym magazynie;
- W ustawieniach ssh i sshd za pomocą dyrektywy IPQoS teraz możliwe jest ustawienie trybu priorytetyzacji ruchu. (Lower-Effort Per-Hop Behavior);
- W ssh, przy ustawieniu wartości „AddKeysToAgent=yes”, jeśli klucz nie zawiera pola z komentarzem, zostanie dodany do ssh-agent z wskazaniem jako komentarz ścieżki do klucza. W
ssh-keygen i ssh-agent jako komentarze do kluczy są teraz również używane etykiety PKCS#11 oraz nazwa podmiotu X.509 zamiast ścieżki do biblioteki; - W ssh-keygen dodano możliwość eksportu PEM dla kluczy DSA i ECDSA;
- Dodano nowy plik wykonywalny ssh-sk-helper, używany do izolacji biblioteki dostępu do tokenów FIDO/U2F;
- W ssh i sshd dodano opcję kompilacji „—with-zlib” dla kompilacji z obsługą biblioteki zlib;
- Zgodnie z wymogiem RFC4253 w wyświetlanym bannerze podczas połączenia zapewniono wyświetlenie ostrzeżenia o zablokowaniu dostępu z powodu przekroczenia limitu MaxStartups. Aby ułatwić diagnozowanie, w nagłówku procesu sshd, widocznym przy użyciu narzędzia ps, wyświetlana jest liczba aktualnie uwierzytelnionych połączeń oraz stan limitu MaxStartups;
- W ssh i ssh-agent, podczas wywołania programu do wyświetlania komunikatu, określanego przez $SSH_ASKPASS, teraz dodatkowo przekazywana jest flaga typu komunikatu: „confirm” – dialog potwierdzenia (tak/nie), „none” – informacyjny komunikat, „blank” – prośba o hasło;
- W ssh-keygen dodano nową operację z podpisami cyfrowymi „find-principals” do wyszukiwania w pliku allowed-signers użytkownika, powiązanego z podanym podpisem cyfrowym;
- Udoskonalono wsparcie dla izolacji procesu sshd w Linux przy użyciu mechanizmu seccomp: zabronione zostały wywołania systemowe IPC, a zezwolono na clock_gettime64(), clock_nanosleep_time64 oraz clock_nanosleep().
Źródło: opennet.ru
