Wydanie OpenSSH 8.4

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

Główne zmiany:

• Zmiany związane z bezpieczeństwem:
  • W ssh-agent podczas używania kluczy FIDO, które nie są stworzone do autoryzacji przez SSH (identyfikator klucza nie zaczyna się od ciągu „ssh:”), teraz odbywa się weryfikacja, że wiadomość zostanie podpisana z użyciem metod stosowanych w protokole SSH. Zmiana ta nie pozwoli na przekazywanie ssh-agent do zdalnych hostów z kluczami FIDO, aby zablokować możliwość używania tych kluczy do tworzenia podpisów zapytań webowych (przypadek odwrotny, kiedy przeglądarka może podpisać zapytanie SSH, pierwotnie został wykluczony, dzięki zastosowaniu prefiksu „ssh:” w identyfikatorze klucza).
  • W ssh-keygen przy generowaniu klucza rezydentnego włączone zostało wsparcie dla rozszerzenia credProtect, opisanego w specyfikacji FIDO 2.1, które zapewnia dodatkową ochronę dla kluczy poprzez obowiązkowe wprowadzenie kodu PIN przed wykonaniem jakiejkolwiek operacji, która może prowadzić do wydobycia klucza rezydentnego z tokena.
• Zmiany potencjalnie naruszające zgodność:
  • W celu wsparcia FIDO/U2F zaleca się użycie biblioteki libfido2 w wersji co najmniej 1.5.0. Częściowo wdrożono możliwość korzystania też ze starszych wersji, ale w takim przypadku niedostępne będą takie funkcje, jak klucze rezydentne, żądanie PIN-u i podłączenie wielu tokenów.
  • W ssh-keygen do formatu informacji potwierdzającej, opcjonalnie zapisywanej przy generowaniu klucza FIDO, dodano dane dla uwierzytelniającego, wymagane do weryfikacji potwierdzających podpisów cyfrowych.
  • Zmieniono API, stosowane przy interakcji OpenSSH z warstwą do obiegu tokenów FIDO.
  • Podczas budowy przenośnej wersji OpenSSH teraz wymagane jest automake do tworzenia skryptu configure i towarzyszących plików budowlanych (jeśli budowa jest przeprowadzana z opublikowanego pliku tar z kodem, regeneracja configure nie jest wymagana).
• W ssh i ssh-keygen dodano wsparcie dla kluczy FIDO, które wymagają potwierdzenia za pomocą kodu PIN. Do generowania kluczy z PIN w ssh-keygen dodano opcję „verify-required”. W przypadku używania takich kluczy, przed wykonaniem operacji tworzenia podpisu użytkownik otrzymuje zapytanie, wymagające potwierdzenia swoich działań poprzez wprowadzenie kodu PIN.
• W sshd w konfiguracji authorized_keys wprowadzono opcję „verify-required”, wymagającą zastosowania możliwości weryfikacji obecności użytkownika podczas operacji z tokenem. Standard FIDO przewiduje kilka wariantów takiej weryfikacji, ale obecnie w OpenSSH obsługiwana jest tylko weryfikacja oparta na kodzie PIN.
• W sshd i ssh-keygen dodano wsparcie dla weryfikacji podpisów cyfrowych, odpowiadających standardowi FIDO Webauthn, który pozwala na wykorzystanie kluczy FIDO w przeglądarkach internetowych.
• W ssh w ustawieniach CertificateFile,
  ControlPath, IdentityAgent, IdentityFile, LocalForward i
  RemoteForward zezwolono na podstawienie wartości z zmiennych środowiskowych, określonych w formacie „${ENV}”.
• W ssh i ssh-agent dodano wsparcie dla zmiennej środowiskowej $SSH_ASKPASS_REQUIRE, którą można wykorzystać do włączenia lub wyłączenia wywołania ssh-askpass.
• W ssh w ssh_config w dyrektywie AddKeysToAgent dodano możliwość ograniczenia czasu działania klucza. Po upływie określonego limitu klucze są automatycznie usuwane z ssh-agent.
• W scp i sftp przy pomocy flagi „-A” można teraz wyraźnie zezwolić na przekierowywanie w scp i sftp z wykorzystaniem ssh-agent (domyślnie przekierowywanie jest zabronione).
• W ustawieniach ssh dodano wsparcie dla podstawienia „%k”, które określa nazwę klucza hosta. Umożliwia to rozdzielanie kluczy na oddzielne pliki (na przykład „UserKnownHostsFile ~/.ssh/known_hosts.d/%k”).
• Zezwalano na użycie operacji „ssh-add -d -” do odczytu z stdin kluczy, które mają zostać usunięte.
• W sshd zapewniono rejestrowanie w logach rozpoczęcia i zakończenia procesu ograniczania połączeń, regulowanego za pomocą parametru MaxStartups.

Twórcy OpenSSH przypomnieli również o nadchodzącej klasyfikacji algorytmów wykorzystujących hashe SHA-1 jako przestarzałych w związku z podwyższeniem 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 następnym wydaniu 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 wymieniono rsa-sha2-256/512 na podstawie RFC8332 RSA SHA-2 (wspierane od OpenSSH 7.2 i używane domyślnie), ssh-ed25519 (wspierane od OpenSSH 6.5) oraz ecdsa-sha2-nistp256/384/521 na podstawie RFC5656 ECDSA (wspierane od OpenSSH 5.7).

Źródło: opennet.ru