Po czterech miesiącach rozwoju wydanie , otwarta implementacja klienta i serwera do pracy poprzez protokoły SSH 2.0 i SFTP.
Kluczowym ulepszeniem w wydaniu OpenSSH 8.2 była możliwość korzystania z uwierzytelniania dwuskładnikowego przy użyciu urządzeń obsługujących protokół , opracowany przez sojusz . U2F umożliwia tworzenie tanich tokenów sprzętowych w celu weryfikacji fizycznej obecności użytkownika, wchodząc z nim w interakcję za pośrednictwem USB, Bluetooth lub NFC. Urządzenia tego typu są promowane na stronach internetowych jako sposób uwierzytelniania dwuskładnikowego, są już obsługiwane przez główne przeglądarki i są produkowane przez różnych producentów, w tym Yubico, Feitian, Thetis i Kensington.
Aby umożliwić interakcję z urządzeniami potwierdzającymi obecność użytkownika, do OpenSSH dodano nowe typy kluczy „ecdsa-sk” i „ed25519-sk”, które wykorzystują algorytmy podpisu cyfrowego ECDSA i Ed25519 w połączeniu z hashem SHA-256. Procedury interakcji z tokenami umieszczone są w bibliotece pośredniej, która ładowana jest w podobny sposób jak biblioteka obsługująca PKCS#11 i stanowi opakowanie na bibliotekę , który udostępnia narzędzia do komunikacji z tokenami przez USB (obsługiwane są protokoły FIDO U2F/CTAP 1 i FIDO 2.0/CTAP 2). Biblioteka pośrednia libsk-libfido2 przygotowana przez programistów OpenSSH do rdzenia libfido2, a także dla OpenBSD.
Aby uwierzytelnić i wygenerować klucz, należy w ustawieniach określić parametr „SecurityKeyProvider” lub ustawić zmienną środowiskową SSH_SK_PROVIDER, wskazującą ścieżkę do zewnętrznej biblioteki libsk-libfido2.so (eksport SSH_SK_PROVIDER=/path/to/libsk-libfido2. Więc). Możliwe jest zbudowanie openssh z wbudowaną obsługą biblioteki warstw (--with-security-key-builtin), w tym przypadku należy ustawić parametr „SecurityKeyProvider=internal”.
Następnie musisz uruchomić „ssh-keygen -t ecdsa-sk” lub, jeśli klucze zostały już utworzone i skonfigurowane, połączyć się z serwerem za pomocą „ssh”. Po uruchomieniu ssh-keygen wygenerowana para kluczy zostanie zapisana w „~/.ssh/id_ecdsa_sk” i będzie można jej używać podobnie jak innych kluczy.
Klucz publiczny (id_ecdsa_sk.pub) należy skopiować na serwer w pliku autoryzowane_klucze. Po stronie serwera weryfikowany jest tylko podpis cyfrowy, a po stronie klienta odbywa się interakcja z tokenami (nie musisz instalować na serwerze libsk-libfido2, ale serwer musi obsługiwać typ klucza „ecdsa-sk”) . Wygenerowany klucz prywatny (id_ecdsa_sk) jest w istocie uchwytem klucza, tworzącym prawdziwy klucz tylko w połączeniu z tajną sekwencją przechowywaną po stronie tokena U2F. Jeżeli klucz id_ecdsa_sk wpadnie w ręce atakującego, aby przejść uwierzytelnienie będzie on musiał uzyskać dostęp także do tokena sprzętowego, bez którego klucz prywatny zapisany w pliku id_ecdsa_sk będzie bezużyteczny.
Ponadto domyślnie przy wykonywaniu jakichkolwiek operacji na kluczach (zarówno podczas generowania, jak i podczas uwierzytelniania) wymagane jest lokalne potwierdzenie fizycznej obecności użytkownika, np. proponowane jest dotknięcie czujnika na tokenie, co utrudnia przeprowadzać zdalne ataki na systemy z podłączonym tokenem. Jako kolejną linię obrony można również określić hasło podczas fazy uruchamiania ssh-keygen, aby uzyskać dostęp do pliku klucza.
Nowa wersja OpenSSH ogłosiła również nadchodzące wycofanie algorytmów korzystających z skrótów SHA-1 z powodu skuteczność ataków kolizyjnych z danym prefiksem (koszt wybrania kolizji szacuje się na około 45 tysięcy dolarów). W jednej z nadchodzących wydań planują domyślnie wyłączyć możliwość korzystania z algorytmu podpisu cyfrowego klucza publicznego „ssh-rsa”, który jest wspomniany w oryginalnym dokumencie RFC dla protokołu SSH i pozostaje szeroko rozpowszechniony w praktyce (w celu przetestowania użycia ssh-rsa w swoich systemach, możesz spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”).
Aby płynnie przejść na nowe algorytmy w OpenSSH, w przyszłej wersji ustawienie UpdateHostKeys zostanie domyślnie włączone, co automatycznie przeniesie klientów do bardziej niezawodnych algorytmów. Zalecane algorytmy migracji obejmują rsa-sha2-256/512 w oparciu o RFC8332 RSA SHA-2 (obsługiwane od OpenSSH 7.2 i używane domyślnie), ssh-ed25519 (obsługiwane od OpenSSH 6.5) i ecdsa-sha2-nistp256/384/521 na RFC5656 ECDSA (obsługiwane od OpenSSH 5.7).
W OpenSSH 8.2 możliwość łączenia się za pomocą „ssh-rsa” jest nadal dostępna, ale algorytm ten został usunięty z listy CASignatureAlgorithms, która definiuje algorytmy dozwolone do cyfrowego podpisywania nowych certyfikatów. Podobnie algorytm diffie-hellman-group14-sha1 został usunięty z domyślnych obsługiwanych algorytmów wymiany kluczy. Należy zauważyć, że użycie SHA-1 w certyfikatach wiąże się z dodatkowym ryzykiem, gdyż atakujący ma nieograniczony czas na poszukiwanie kolizji dla istniejącego certyfikatu, natomiast czas ataku na klucze hosta jest ograniczony limitem czasu połączenia (LoginGraceTime ).
Uruchamianie ssh-keygen domyślnie korzysta z algorytmu rsa-sha2-512, który jest obsługiwany od wersji OpenSSH 7.2, co może powodować problemy ze zgodnością podczas prób przetwarzania certyfikatów podpisanych w OpenSSH 8.2 w systemach ze starszymi wersjami OpenSSH (aby obejść ten problem, gdy Kiedy generując podpis, możesz jawnie określić „ssh-keygen -t ssh-rsa” lub użyć algorytmów ecdsa-sha2-nistp256/384/521, obsługiwanych od OpenSSH 5.7).
Inne zmiany:
- Do sshd_config dodano dyrektywę Include, która pozwala na dołączenie zawartości innych plików w bieżącej pozycji pliku konfiguracyjnego (przy określaniu nazwy pliku można użyć masek globalnych);
- do ssh-keygen dodano opcję „no-touch-required”, która wyłącza konieczność fizycznego potwierdzania dostępu do tokena podczas generowania klucza;
- Do sshd_config dodano dyrektywę PubkeyAuthOptions, która łączy różne opcje związane z uwierzytelnianiem klucza publicznego. Obecnie obsługiwana jest tylko flaga „nie wymaga dotyku”, która umożliwia pominięcie kontroli obecności fizycznej w celu uwierzytelnienia za pomocą tokena. Analogicznie do plikuauthorized_keys dodano opcję „no-touch-required”;
- Dodano opcję „-O write-attestation=/path” do ssh-keygen, aby umożliwić zapisywanie dodatkowych certyfikatów atestacyjnych FIDO podczas generowania kluczy. OpenSSH nie korzysta jeszcze z tych certyfikatów, ale można je później wykorzystać do sprawdzenia, czy klucz znajduje się w zaufanym sklepie ze sprzętem;
- W ustawieniach ssh i sshd można teraz ustawić tryb priorytetyzacji ruchu za pomocą dyrektywy IPQoS (Zachowanie przy przeskoku wymagające mniejszego wysiłku);
- W ssh, ustawiając wartość „AddKeysToAgent=yes”, jeśli klucz nie zawiera pola komentarza, zostanie dodany do ssh-agent wskazując ścieżkę do klucza jako komentarz. W
ssh-keygen i ssh-agent również używają teraz etykiet PKCS#11 i nazwy podmiotu X.509 zamiast ścieżki biblioteki jako komentarzy w kluczu; - Dodano możliwość eksportu PEM dla kluczy DSA i ECDSA do ssh-keygen;
- Dodano nowy plik wykonywalny ssh-sk-helper, używany do izolowania biblioteki dostępu do tokenów FIDO/U2F;
- Dodano opcję kompilacji „--with-zlib” do ssh i sshd w celu kompilacji z obsługą biblioteki zlib;
- Zgodnie z wymaganiami RFC4253, w banerze wyświetlanym podczas połączenia pojawia się ostrzeżenie o zablokowaniu dostępu w związku z przekroczeniem limitów MaxStartups. Aby uprościć diagnostykę, nagłówek procesu sshd, widoczny podczas korzystania z narzędzia ps, wyświetla teraz liczbę aktualnie uwierzytelnionych połączeń i stan limitu MaxStartups;
- W ssh i ssh-agent, podczas wywoływania programu wyświetlającego na ekranie zaproszenie określone poprzez $SSH_ASKPASS, teraz dodatkowo przesyłana jest flaga z typem zaproszenia: „confirm” - okno dialogowe potwierdzenia (tak/nie), „brak ” - komunikat informacyjny, „puste” — żądanie hasła;
- Dodano nową operację podpisów cyfrowych „find-principals” do ssh-keygen, aby przeszukać plik dozwolonych podpisujących dla użytkownika powiązanego z określonym podpisem cyfrowym;
- Ulepszona obsługa izolacji procesów sshd w systemie Linux przy użyciu mechanizmu seccomp: wyłączenie wywołań systemowych IPC, zezwolenie na clock_gettime64(), clock_nanosleep_time64 i clock_nanosleep().
Źródło: opennet.ru