Wydanie OpenSSH 8.7

Po czterech miesiącach rozwoju zaprezentowano wydanie OpenSSH 8.7, otwartej implementacji klienta i serwera do pracy w protokołach SSH 2.0 i SFTP.

Główne zmiany:

• W scp dodano eksperymentalny tryb transferu danych z użyciem protokołu SFTP zamiast tradycyjnie wykorzystywanego protokołu SCP/RCP. W SFTP stosowane są bardziej przewidywalne metody obsługi nazw i nie wykorzystuje się przetwarzania wzorców glob przez powłokę na zdalnym hoście, co stwarza problemy z bezpieczeństwem. Aby włączyć SFTP w scp, zaproponowano flagę „-s”, jednak w przyszłości planuje się przejście na ten protokół jako domyślny.
• W sftp-server zaimplementowano rozszerzenia protokołu SFTP do rozpoznawania ścieżek ~/ i ~user/, co jest konieczne dla scp.
• W narzędziu scp zmieniono zachowanie przy kopiowaniu plików między dwoma zdalnymi hostami (na przykład, „scp host-a:/path host-b:”); teraz domyślnie odbywa się to przez pośredni lokalny host, tak jak przy wskazaniu flagi „-3”. Wskazane podejście pozwala uniknąć przesyłania zbędnych danych logowania do pierwszego hosta oraz potrójnej interpretacji nazw plików w powłoce (po stronie źródła, odbiorcy i systemu lokalnego), a także w przypadku używania SFTP umożliwia korzystanie ze wszystkich metod uwierzytelniania przy dostępie do zdalnych hostów, a nie tylko z metod nieinteraktywnych. Aby przywrócić stare zachowanie, dodano opcję „-R”.
• W ssh dodano ustawienie ForkAfterAuthentication, odpowiadające fladze „-f”.
• W ssh dodano ustawienie StdinNull, odpowiadające fladze „-n”.
• W ssh dodano ustawienie SessionType, za pomocą którego można ustawić tryby odpowiadające flagom „-N” (bez sesji) i „-s” (subsystem).
• W ssh-keygen w plikach z kluczami zezwolono na określenie okresu ważności klucza.
• W ssh-keygen dodano flagę „-Oprint-pubkey” do wyświetlania pełnego klucza publicznego w składzie podpisu sshsig.
• W ssh i sshd, zarówno klient, jak i serwer, przeszły na wykorzystanie bardziej rygorystycznego parsera pliku konfiguracyjnego, w którym stosowane są zasady podobne do powłoki do obróbki cudzysłowów, spacji i znaków ucieczki. Nowy parser nie pomija także wcześniej obowiązujących założeń, takich jak pomijanie argumentów w opcjach (na przykład, nie można już pozostawiać pustej dyrektywy DenyUsers), niezamknięte cudzysłowy oraz wskazywanie kilku symboli „=”.
• Podczas weryfikacji kluczy za pomocą rekordów DNS SSHFP, ssh teraz sprawdza wszystkie dopasowane rekordy, a nie tylko te zawierające określony typ podpisu cyfrowego.
• W ssh-keygen, przy generowaniu klucza FIDO z opcją -Ochallenge do haszowania, teraz używana jest wbudowana warstwa, a nie biblioteki libfido2, co pozwala na użycie sekwencji wyzwań o długości większej lub mniejszej niż 32 bajty.
• W sshd, podczas przetwarzania dyrektywy environment="…" w plikach authorized_keys, akceptowane jest pierwsze dopasowanie, a ograniczenie wynosi 1024 nazw zmiennych środowiskowych.

Deweloperzy OpenSSH również ostrzegli przed przechodzeniem na przestarzałe algorytmy, używające hashy SHA-1, w związku z rosnącą skutecznością ataków kolizyjnych z określonym prefiksem (koszt generowania kolizji szacuje się na około 50 tysięcy dolarów). W przyszłym wydaniu planowane jest domyślne wyłączenie możliwości używania algorytmu cyfrowych podpisów po otwartym kluczu „ssh-rsa”, który jest wymieniany w oryginalnym RFC dla protokołu SSH i pozostaje powszechnie stosowany w praktyce.

Aby sprawdzić zastosowanie ssh-rsa w swoich systemach, można spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”. Jednak wyłączenie domyślnie cyfrowych podpisów „ssh-rsa” nie oznacza całkowitego zaprzestania używania kluczy RSA, ponieważ poza SHA-1 protokół SSH dopuszcza użycie innych algorytmów obliczania hashy. W szczególności, oprócz „ssh-rsa”, pozostanie możliwość zastosowania zestawów „rsa-sha2-256” (RSA/SHA256) i „rsa-sha2-512” (RSA/SHA512).

Aby złagodzić przejście na nowe algorytmy, w OpenSSH wcześniej domyślnie włączona była opcja UpdateHostKeys, która umożliwia automatyczne przejście klientów na bardziej niezawodne algorytmy. Użycie tej opcji włącza specjalne rozszerzenie protokołu „hostkeys@openssh.com”, które pozwala serwera po przejściu procesu autoryzacji poinformować klienta o wszystkich dostępnych kluczach hosta. Klient może odzwierciedlić te klucze w swoim pliku ~/ .ssh/known_hosts, co pozwala na zorganizowanie aktualizacji kluczy hosta i ułatwia zmianę kluczy. serwerze.

Użycie UpdateHostKeys jest ograniczone kilkoma zastrzeżeniami, które mogą zostać w przyszłości uchylone: klucz musi być wymieniony w UserKnownHostsFile i nie może być używany w GlobalKnownHostsFile; klucz musi występować tylko pod jedną nazwą; nie może być używany certyfikat klucza hosta; w known_hosts nie mogą być stosowane maski po nazwie hosta; musi być wyłączona opcja VerifyHostKeyDNS; musi być aktywny parametr UserKnownHostsFile.

Wśród zalecanych do migracji algorytmów wymienione zostały rsa-sha2-256/512 na podstawie RFC8332 RSA SHA-2 (obsługiwany od OpenSSH 7.2 i używany domyślnie), ssh-ed25519 (obsługiwany od OpenSSH 6.5) oraz ecdsa-sha2-nistp256/384/521 na podstawie RFC5656 ECDSA (obsługiwany od OpenSSH 5.7).

Źródło: opennet.ru