Po czterech miesiącach prac zaprezentowano wydanie OpenSSH 8.7, otwartej implementacji klienta i serwera do pracy poprzez protokoły SSH 2.0 i SFTP.
Główne zmiany:
- Do scp dodano eksperymentalny tryb przesyłania danych przy użyciu protokołu SFTP zamiast tradycyjnego protokołu SCP/RCP. Protokół SFTP wykorzystuje bardziej przewidywalne metody obsługi nazw i nie wykorzystuje przetwarzania powłoki wzorców glob po stronie drugiego hosta, co stwarza problemy związane z bezpieczeństwem. Aby włączyć SFTP w scp, zaproponowano flagę „-s”, ale w przyszłości planowane jest domyślne przejście na ten protokół.
- sftp-server implementuje rozszerzenia protokołu SFTP w celu rozszerzenia ścieżek ~/ i ~user/, które są niezbędne dla scp.
- Narzędzie scp zmieniło zachowanie podczas kopiowania plików pomiędzy dwoma zdalnymi hostami (na przykład „scp host-a:/path host-b:”), co jest teraz domyślnie wykonywane za pośrednictwem pośredniego hosta lokalnego, tak jak przy określaniu „ Flaga -3”. Takie podejście pozwala uniknąć przekazywania niepotrzebnych danych uwierzytelniających do pierwszego hosta i potrójnej interpretacji nazw plików w powłoce (po stronie źródłowej, docelowej i systemu lokalnego), a podczas korzystania z protokołu SFTP pozwala na korzystanie ze wszystkich metod uwierzytelniania podczas dostępu zdalnego hosty, a nie tylko metody nieinteraktywne. Dodano opcję „-R”, aby przywrócić stare zachowanie.
- Dodano ustawienie ForkAfterAuthentication do ssh odpowiadające flagi „-f”.
- Dodano ustawienie StdinNull do ssh, odpowiadające flagi „-n”.
- Do ssh dodano ustawienie SessionType, za pomocą którego można ustawić tryby odpowiadające flagom „-N” (brak sesji) i „-s” (podsystem).
- ssh-keygen pozwala określić okres ważności klucza w plikach kluczy.
- Dodano flagę „-Oprint-pubkey” do ssh-keygen, aby wydrukować pełny klucz publiczny jako część podpisu sshsig.
- W ssh i sshd zarówno klient, jak i serwer zostały przeniesione tak, aby korzystały z bardziej restrykcyjnego parsera plików konfiguracyjnych, który wykorzystuje reguły podobne do powłoki do obsługi cudzysłowów, spacji i znaków ucieczki. Nowy parser nie ignoruje również wcześniej przyjętych założeń, takich jak pomijanie argumentów w opcjach (na przykład dyrektywa DenyUsers nie może już pozostać pusta), niezamknięte cudzysłowy i określanie wielu znaków =.
- Podczas korzystania z rekordów DNS SSHFP podczas weryfikacji kluczy, ssh sprawdza teraz wszystkie pasujące rekordy, a nie tylko te zawierające określony typ podpisu cyfrowego.
- W ssh-keygen, podczas generowania klucza FIDO z opcją -Ochallenge, do mieszania używana jest teraz wbudowana warstwa, a nie libfido2, która pozwala na użycie sekwencji wyzwań większych lub mniejszych niż 32 bajty.
- W sshd, podczas przetwarzania dyrektyw Environment="..." w plikach autoryzowanych_kluczy, pierwsze dopasowanie jest teraz akceptowane i obowiązuje limit 1024 nazw zmiennych środowiskowych.
Twórcy OpenSSH ostrzegali także przed dekompozycją algorytmów wykorzystujących skróty SHA-1 ze względu na zwiększoną skuteczność ataków kolizyjnych z danym prefiksem (koszt wybrania kolizji szacowany jest na około 50 tysięcy dolarów). W następnej wersji planujemy domyślnie wyłączyć możliwość korzystania z algorytmu podpisu cyfrowego klucza publicznego „ssh-rsa”, który został wspomniany w oryginalnym dokumencie RFC dla protokołu SSH i pozostaje szeroko stosowany w praktyce.
Aby przetestować użycie ssh-rsa w swoich systemach, możesz spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”. Jednocześnie domyślne wyłączenie podpisów cyfrowych „ssh-rsa” nie oznacza całkowitej rezygnacji z używania kluczy RSA, ponieważ oprócz SHA-1 protokół SSH umożliwia stosowanie innych algorytmów obliczania skrótu. W szczególności oprócz „ssh-rsa” nadal możliwe będzie korzystanie z pakietów „rsa-sha2-256” (RSA/SHA256) i „rsa-sha2-512” (RSA/SHA512).
Aby ułatwić przejście na nowe algorytmy, w OpenSSH domyślnie włączono ustawienie UpdateHostKeys, które umożliwiało klientom automatyczne przełączanie na bardziej niezawodne algorytmy. Za pomocą tego ustawienia włączane jest specjalne rozszerzenie protokołu „[email chroniony]", pozwalając serwerowi po uwierzytelnieniu poinformować klienta o wszystkich dostępnych kluczach hosta. Klient może odzwierciedlić te klucze w swoim pliku ~/.ssh/known_hosts, co umożliwia aktualizację kluczy hosta i ułatwia zmianę kluczy na serwerze.
Korzystanie z UpdateHostKeys jest ograniczone kilkoma zastrzeżeniami, które mogą zostać usunięte w przyszłości: klucz musi być wymieniony w pliku UserKnownHostsFile, a nie używany w pliku GlobalKnownHostsFile; klucz musi występować tylko pod jedną nazwą; nie należy używać certyfikatu klucza hosta; w znanych_hostach nie należy używać masek według nazwy hosta; ustawienie VerifyHostKeyDNS musi być wyłączone; Parametr UserKnownHostsFile musi być aktywny.
Zalecane algorytmy migracji obejmują rsa-sha2-256/512 oparty na RFC8332 RSA SHA-2 (obsługiwany od OpenSSH 7.2 i używany domyślnie), ssh-ed25519 (obsługiwany od OpenSSH 6.5) i ecdsa-sha2-nistp256/384/521 na RFC5656 ECDSA (obsługiwane od OpenSSH 5.7).
Źródło: opennet.ru