Historia protokołu SSH: od telnetu do OpenSSH

Początki historii SSH

Historia SSH zaczyna się od kradzieży haseł. Przed rokiem 1995 logowanie do zdalnej maszyny Unix odbywało się za pomocą telnet lub rlogin, a oba te narzędzia przesyłały hasło przez sieć w postaci czytelnego tekstu. Każdy, kto mógł monitorować ruch sieciowy, był w stanie je odczytać, a na początku lat 90. proceder ten był powszechny i prowadzony na dużą skalę.

SSH było odpowiedzią jednej osoby na ten problem; zostało napisane w 1995 roku i udostępnione bezpłatnie. Od tego czasu protokół został przebudowany raz, a program, z którego korzysta dziś niemal każdy, jest forkiem forka. Poniższe daty są istotne, ponieważ każdy kolejny krok był reakcją na konkretną awarię lub lukę.

Co faktycznie przesyłały protokoły telnet i rlogin

Protokół Telnet został zdefiniowany w RFC 854, opublikowanym w maju 1983 roku przez Jona Postela i Joyce Reynolds. Opisuje on sesję terminalową realizowaną przez TCP i nie zawiera żadnego szyfrowania. Każdy wpisany bajt, włącznie z hasłem, jest przesyłany jako jawny tekst, który może odczytać każde urządzenie znajdujące się na ścieżce transmisji.

Protokół rlogin wywodzi się z Berkeley Unix i został opisany później w RFC 1282 (BSD Rlogin, B. Kantor, grudzień 1991). Wprowadził on rozwiązanie gorsze niż przesyłanie czytelnego hasła: zaufanie oparte na hoście. Serwer mógł zostać skonfigurowany tak, aby akceptować logowania z określonego hosta bez żadnego hasła. Dokument RFC zawiera sekcję zatytułowaną "A Cautionary Tale" (przestroga), która stwierdza: "Ominięcie uwierzytelniania hasłem z zaufanych hostów otwiera WSZYSTKIE tak skonfigurowane systemy w momencie, gdy choć jeden z nich zostanie przejęty". Zauważono również, że zaufanie opiera się na nazwach hostów, więc kompromitacja systemu DNS (domain name system) lub sfałszowanie adresu unieważnia to zabezpieczenie.

Oba projekty odpowiadały realiom sieci, w których powstały. Wczesny Ethernet był medium współdzielonym: każda maszyna w segmencie otrzymywała każdą ramkę i oczekiwano, że zignoruje te, które nie są do niej zaadresowane. Maszyna, która przestała je ignorować – co oznacza pracę w trybie promiscuous mode – widziała ruch wszystkich pozostałych urządzeń. Jeśli dodać do tego uniwersytet udostępniający konta powłoki tysiącom studentów, jedno przejęte konto stawało się narzędziem do zbierania haseł dla całego wydziału.

Komunikat z 1994 roku bez dostępnej poprawki

3 lutego 1994 roku zespół CERT opublikował komunikat CA-94:01 pod tytułem "Ongoing Network Monitoring Attacks". Poinformowano w nim, że intruzi przechwycili dane dostępowe do dziesiątek tysięcy systemów w Internecie. Użyte przez nich narzędzie przełączało interfejs sieciowy w tryb promiscuous i rejestrowało początek każdej nowej sesji telnet, rlogin oraz FTP, czyli fragment zawierający nazwę użytkownika i hasło.

CERT zalecił administratorom zmianę haseł dla wszystkich kont dostępnych przez sieć. W kontekście używanych wówczas protokołów pułapka jest oczywista: nowe hasło przy pierwszym użyciu przesyłane jest tym samym łączem w postaci otwartego tekstu. W protokołach telnet i rlogin nie istniała żadna poprawka, ponieważ żaden z nich nie przewidywał mechanizmu zabezpieczającego.

Dlaczego atak typu sniffing w Helsinkach doprowadził do powstania SSH

W 1995 roku sieć na Politechnice w Helsinkach padła ofiarą ataku typu password sniffing, opisanego wcześniej przez CERT. Tatu Ylönen, tamtejszy badacz, napisał zamiennik i udostępnił go jako freeware w lipcu 1995 roku. Nazwał go Secure Shell.

O sukcesie zdecydowały dwie decyzje projektowe. Sesja była szyfrowana, więc podsłuchujący w segmencie sieci nie uzyskiwał żadnych użytecznych danych. Ponadto serwer potwierdzał swoją tożsamość za pomocą klucza, dzięki czemu klient mógł zweryfikować, czy połączył się z właściwą maszyną. Była to luka, którą pozostawiało zaufanie do nazwy hosta w protokole rlogin.

Popularność wzrosła również dlatego, że polecenia odpowiadały tym, których użytkownicy już używali. ssh zastąpiło rsh oraz rlogin, a scp zastąpiło rcp. Przejście na nowe rozwiązanie wymagało jedynie zmiany nawyku, a nie całego procesu pracy. Pod koniec 1995 roku baza użytkowników osiągnęła około 20 000 osób w pięćdziesięciu krajach. W grudniu tego samego roku Ylönen założył firmę SSH Communications Security w celu dalszego rozwoju i sprzedaży oprogramowania.

Od darmowego wydania do produktu komercyjnego

W miarę jak SSH stało się przedsięwzięciem biznesowym, licencja kodu źródłowego uległa zmianie. Późniejsze wydania zawierały warunki ograniczające możliwości wykorzystania kodu przez inne podmioty, a ostatnią wersją, którą można było swobodnie wykorzystywać, była ssh 1.2.12. Nie ma w tym nic niewłaściwego. Oznaczało to po prostu, że rozwój wersji SSH, na której mogła opierać się reszta świata, został zatrzymany, podczas gdy prace rozwojowe kontynuowano w miejscu niedostępnym dla społeczności. Licencje decydują o tym, który kod przetrwa; jest to wzorzec, o którym warto przeczytać w jak licencjonowanie open source ukształtowało nowoczesną infrastrukturę.

Dlaczego projekt OpenBSD stworzył fork OpenSSH w 1999 roku

Na początku 1999 roku Björn Grönvall powrócił do ostatniego wolnego wydania i rozpoczął usuwanie błędów. Jego wersja nosiła nazwę OSSH i obsługiwała wyłącznie protokół SSH 1.3.

Projekt OpenBSD przejął OSSH i przebudował go. Według relacji samego projektu, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell oraz Dug Song wykonali pracę polegającą na oczyszczeniu, audycie i rozszerzeniu kodu. Rezultatem był OpenSSH 1.2.2, który został wydany wraz z OpenBSD 2.6 w dniu 1 grudnia 1999 roku.

Dlaczego fork stworzony przez niewielki projekt systemu operacyjnego trafił na niemal każdą maszynę? Powodem były wymagania OpenBSD. OpenBSD dostarcza audytowany system podstawowy, który ma być bezpieczny w domyślnej konfiguracji, więc szyfrowane zdalne logowanie musiało znaleźć się w tym systemie, na licencji pozbawionej ograniczeń. Audytowany kod na licencji bez restrykcji był dokładnie tym, czego potrzebowali wszyscy inni dostawcy systemów operacyjnych. Damien Miller, Philip Hands i inni niemal natychmiast rozpoczęli prace nad gałęzią przenośną (portable), z której pochodzi p w wersji takiej jak 10.5p1. OpenBSD rozwija czystą wersję, a gałąź przenośna dodaje warstwę integracyjną dla pozostałych systemów. Sposób, w jaki Unix podzielił się na systemy, których używamy dzisiaj wyjaśnia, dlaczego ta warstwa jest w ogóle potrzebna.

Wsparcie dla drugiej wersji protokołu pojawiło się później. OpenSSH 2.0 został wydany wraz z OpenBSD 2.7 w dniu 15 czerwca 2000 roku.

Dlaczego SSH-2 jest nowym protokołem, a nie tylko zmianą wersji

SSH-1 chronił integralność szyfrowanego strumienia za pomocą CRC-32, sumy kontrolnej zaprojektowanej do wykrywania błędów transmisji, a nie do odpierania ataków. W 1998 roku Ariel Futoransky i Emiliano Kargieman z CORE SDI wykazali, jakie są tego konsekwencje. Przy użyciu trybów szyfrowania CBC lub CFB oraz kontroli CRC-32, atakujący znający zaledwie 16 bajtów tekstu jawnego może wstrzyknąć wybrany tekst zaszyfrowany, który odbiorca zaakceptuje jako autentyczny, co pozwala na wykonywanie poleceń na serwerze.

Wada tkwiła w samym protokole, więc nie można było jej naprawić bez naruszenia kompatybilności. Implementacje zawierały zamiast tego detektor – kod w pliku o nazwie deattack.c, który próbował rozpoznawać atak w trakcie jego trwania. W lutym 2001 roku odkryto, że sam detektor zawiera błąd przepełnienia liczby całkowitej, CVE-2001-0144, umożliwiający zdalne wykonanie kodu na serwerach i klientach, które posiadały tę poprawkę. Projekt, którego nie da się naprawić, gromadzi poprawki, a poprawki te wprowadzają własne błędy.

Protokół SSH-2 został opracowany w grupie roboczej IETF o nazwie secsh i opublikowany jako RFC w styczniu 2006 roku: architektura w RFC 4251, warstwa transportowa w RFC 4253, uwierzytelnianie użytkownika w RFC 4252, a warstwa połączenia w RFC 4254. Podział na warstwy jest kluczowy, ponieważ każdą z nich można dzięki temu wymienić niezależnie. Większość dalszej historii tego protokołu to właśnie proces takiej wymiany.

Wyróżniają się dwie zmiany. Integralność przeniesiono z CRC-32 na HMAC (hash-based message authentication code) z kluczem opartym na wspólnym sekrecie, dzięki czemu atakujący, który nie potrafi obliczyć MAC, nie może sfałszować pakietu. Uzgadnianie klucza przeniesiono natomiast na Diffie-Hellman. W SSH-1 klient wybierał klucz sesji i wysyłał go zaszyfrowanego kluczami RSA serwera, więc każdy, kto później wszedł w posiadanie tych kluczy prywatnych, mógł odszyfrować zarejestrowaną sesję. Diffie-Hellman generuje dla każdej sesji nowy sekret, który nigdy nie jest przesyłany, więc rejestrowanie ruchu teraz i kradzież klucza hosta później nic nie daje. Ta właściwość nazywana jest utajnianiem z wyprzedzeniem (forward secrecy).

SSH-2 nie jest kompatybilny z SSH-1 na poziomie transmisji danych. Dlatego numer wersji zmienił się całkowicie, a nie tylko o ułamek dziesiętny.

Dlaczego protokół SSH-1 został usunięty, a nie naprawiony

Usunięcie protokołu trwało przez trzy wydania https://www.openssh.org/releasenotes.html OpenSSH. Wersja 7.0 z 11 sierpnia 2015 r. domyślnie wyłączyła protokół 1 na etapie kompilacji. Wersja 7.4 z 19 grudnia 2016 r. usunęła obsługę tego protokołu po stronie serwera. Wersja 7.6 z 3 października 2017 r. usunęła również stronę kliencką wraz z opcjami konfiguracji oraz dokumentacją.

Pozostawienie tej opcji dla starszego sprzętu byłoby rozwiązaniem bardziej przyjaznym dla użytkownika, jednak wykrycie podatności CRC-32 wyjaśnia, dlaczego odrzucono taką możliwość. Przepełnienie było możliwe do wykorzystania tylko dlatego, że kod protokołu 1 był skompilowany i znajdował się w ścieżce, którą większość administratorów uważała za nieaktywną w swoich systemach. Kod, który jest dostarczany w oprogramowaniu, może zostać wykorzystany. Kod, który został usunięty, nie może.

Dlaczego pierwsze połączenie SSH ostrzega o kluczu hosta

Szyfrowanie gwarantuje prywatność ruchu, ale nie potwierdza tożsamości odbiorcy. Jeśli atakujący przejmie połączenie i odpowie w imieniu serwera, nawiązana zostanie w pełni zaszyfrowana sesja z atakującym; jest to atak typu machine-in-the-middle. SSH przeciwdziała temu za pomocą klucza hosta: serwer udowadnia posiadanie prywatnej części pary kluczy, a klient porównuje ten klucz z wartością zapisaną podczas poprzedniego połączenia. Szczegółowy opis mechanizmu połączenia znajduje się w co dzieje się podczas otwierania połączenia SSH.

Przy pierwszym połączeniu brakuje danych historycznych, więc klient nie ma punktu odniesienia i wyświetla zapytanie:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Odpowiedź yes zapisuje klucz w ~/.ssh/known_hosts. Każde kolejne połączenie porównuje klucz z zapisaną wartością, a niezgodność skutkuje wyświetleniem najbardziej krytycznego komunikatu w programie:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Pierwszy komunikat oznacza, że protokół przyznaje się do swojego jedynego słabego punktu. Zasada "zaufania przy pierwszym użyciu" (Trust on first use) sprawia, że bezpieczeństwo pierwszego połączenia zależy wyłącznie od bezpieczeństwa sieci, w której się znajdujesz. Można wyeliminować to ryzyko. Przed nawiązaniem połączenia sprawdź odcisk klucza (fingerprint) w konsoli dostawcy lub w dzienniku budowy serwera. Możesz opublikować go w DNS jako rekord SSHFP (RFC 4255), co jest zalecane tylko w przypadku wdrożonego DNSSEC. Alternatywnie, podpisz klucze hostów własnym urzędem certyfikacji (CA), dzięki czemu klienci będą ufać urzędowi, a nie każdemu kluczowi z osobna. W praktyce większość użytkowników akceptuje monit bez weryfikacji, co warto otwarcie przyznać.

Jak klucze publiczne wyparły hasła

Uwierzytelnianie za pomocą klucza publicznego było dostępne od wczesnych wydań SSH, a mimo to upłynęły lata, zanim stało się standardem. Mechanizm ten jest asymetryczny: klient udowadnia posiadanie klucza prywatnego poprzez podpisanie wyzwania, a klucz prywatny nigdy nie opuszcza urządzenia klienta. Hasło działa odwrotnie. Mimo że SSH przesyła je wewnątrz zaszyfrowanego kanału, serwer otrzymuje właściwy sekret, więc przejęty lub wrogi serwer uzyskuje dane, które może wykorzystać przeciwko użytkownikowi w innym miejscu.

Drugi powód jest związany z arytmetyką. Każdy serwer z otwartym portem 22 na publicznym adresie otrzymuje przez całą dobę zautomatyzowane próby logowania, a hasło jest ciągiem znaków, który można odgadnąć. Klucza nie można odgadnąć w praktycznie użytecznym sensie. Ustawienie PasswordAuthentication no eliminuje całą tę kategorię ataków, dlatego znajduje się na każdej liście kontrolnej dotyczącej zabezpieczania systemu. Usuwa również mechanizm awaryjny, który wcześniej pozwalał odzyskać dostęp po problemie z kluczem. Dlatego przed utratą dostępu należy nauczyć się rozróżniać kilka usterek zgłaszanych tym samym komunikatem Permission denied (publickey). Praca bez haseł oznacza także gromadzenie kluczy. Agent przechowujący ich kilkanaście oferuje serwerowi każdy z nich po kolei, aż serwer osiągnie limit prób i zakończy połączenie. To powód, dla którego logowanie może zakończyć się błędem Too many authentication failures, nawet gdy właściwy klucz jest załadowany. Generowanie i rotacja kluczy zostały opisane w Podstawy zarządzania kluczami SSH, a ustawienia po stronie serwera w Zabezpieczanie SSH na VPS.

Dlaczego lista algorytmów SSH ulega ciągłym zmianom

Warstwowa architektura protokołu pozwala na wycofywanie algorytmów bez konieczności tworzenia nowego protokołu. OpenSSH konsekwentnie korzysta z tej swobody, a daty wydań odzwierciedlają tempo tych zmian.

Algorytm Ed25519 pojawił się w OpenSSH 6.5 w dniu 30 stycznia 2014 roku, wraz z szyfrem chacha20-poly1305 oraz formatem klucza prywatnego zabezpieczonym przez bcrypt. Podpisy Ed25519 wyznaczają wartość nonce dla każdego podpisu w sposób deterministyczny, dzięki czemu słaby generator liczb losowych w momencie podpisywania nie może doprowadzić do wycieku klucza prywatnego. Właśnie w ten sposób klucze prywatne DSA i ECDSA były odzyskiwane w rzeczywistych incydentach.

W przypadku DSA proces przebiegał odwrotnie. OpenSSH 7.0 wyłączyło obsługę kluczy hosta i użytkownika ssh-dss w czasie wykonywania w 2015 roku, ponieważ algorytm ten jest ograniczony do 160-bitowego klucza prywatnego oraz funkcji SHA-1. Wersja 9.8, wydana 1 lipca 2024 roku, wyłączyła DSA na etapie kompilacji. Wersja 10.0, z 9 kwietnia 2025 roku, usunęła go całkowicie, co według twórców projektu „zamyka proces wycofywania rozpoczęty w 2015 roku”. Dziesięć lat od wyłączenia do usunięcia.

RSA nie zniknęło, ale jego stary format podpisu tak. OpenSSH 8.8, wydane 26 września 2021 roku, przestało domyślnie akceptować podpisy RSA wykonane przy użyciu SHA-1. Informacje o wydaniu podają jasny powód: SHA-1 jest kryptograficznie złamane, a kolizje z wybranym prefiksem można było uzyskać za kwotę poniżej 50 000 USD. Jeśli podczas łączenia się ze starym serwerem wystąpił błąd sign_and_send_pubkey: no mutual signature supported, to właśnie z powodu tej zmiany. Klucz jest poprawny, ale algorytm podpisu wymagany przez drugą stronę nie jest.

Ten sam proces dotyczy obecnie wymiany kluczy, tym razem wyprzedzając zagrożenia. Ruch przechwycony dzisiaj może zostać zarchiwizowany i odszyfrowany po latach przez podmiot, który jako pierwszy będzie dysponował odpowiednio wydajnym komputerem kwantowym, dlatego uzgadnianie kluczy musiało zostać zmienione, zanim taka maszyna powstanie. OpenSSH 9.0, wydane 8 kwietnia 2022 roku, uczyniło hybrydową wymianę kluczy standardem: sntrup761x25519-sha512@openssh.com łączy algorytm postkwantowy z wymianą X25519, dzięki czemu wynik nie jest słabszy od części klasycznej, nawet jeśli nowy algorytm okaże się zawodny. OpenSSH 9.9, z 19 września 2024 roku, dodało mlkem768x25519-sha256, oparte na ML-KEM (module lattice key encapsulation mechanism), ustandaryzowanym przez NIST w 2024 roku. OpenSSH 10.0 uczyniło to rozwiązanie domyślnym dla uzgadniania kluczy, a strona projektu poświęcona kryptografii postkwantowej wyjaśnia powody tej decyzji. OpenSSH 10.1, wydane 6 października 2025 roku, zaczęło wyświetlać ostrzeżenia, gdy druga strona nie obsługuje tego mechanizmu:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

To ostrzeżenie jest domyślnie włączone i jest kontrolowane przez opcję WarnWeakCrypto w pliku ssh_config. Co oznacza to w praktyce i jak postępować w przypadku serwera, który wywołuje ten komunikat, opisano w sekcji domyślne ustawienia postkwantowej wymiany kluczy SSH.

Co ta historia oznacza dla serwera, z którym pracujesz

Wpisywane polecenie niemal nie zmieniło się od 1995 roku. Prawie wszystko, co znajduje się pod spodem, zostało wymienione: weryfikacja integralności, wymiana kluczy, algorytmy podpisu oraz sama baza kodu. Było to możliwe tylko dlatego, że każda wymiana kończyła się celowym usunięciem starego rozwiązania, a każde usunięcie powodowało problemy u części użytkowników.

Dlatego bezpieczeństwo SSH zależy głównie od używanej wersji. Domyślne ustawienia zawierają decyzje dotyczące tego, jakie algorytmy są oferowane, które odrzucane i jakie ostrzeżenia są wyświetlane. Stary serwer nadal oferuje to, na co pozwalała jego wersja w momencie wydania, i będzie obniżał standardy negocjacji, aby dopasować się do starego klienta. Według stanu na sierpień 2026 roku, aktualnym wydaniem jest OpenSSH 10.5, opublikowane 11 sierpnia 2026 roku. Różnica między tą wersją a oprogramowaniem na maszynie, której nikt nie aktualizował od trzech lat, wyznacza skalę problemu. Sprawdzenie tego należy do zadań wykonywanych w ramach pierwszych dziesięciu minut na nowym VPS.

FAQ

Kto stworzył SSH i dlaczego?

Tatu Ylönen, badacz z Helsinki University of Technology, napisał SSH w 1995 roku po ataku typu password sniffing w sieci uniwersyteckiej. Ówczesne narzędzia do zdalnego logowania, telnet i rlogin, przesyłały hasła w sieci jako czytelny tekst, więc każdy monitorujący współdzielony segment mógł przechwycić dane uwierzytelniające. Autor udostępnił program jako freeware w lipcu 1995 roku. Pod koniec tego samego roku narzędzie miało około 20 000 użytkowników w pięćdziesięciu krajach, a w grudniu 1995 roku założył on firmę SSH Communications Security.

Jaka jest różnica między SSH-1 a SSH-2?

Są to różne protokoły, które nie są ze sobą kompatybilne na poziomie transmisji. SSH-1 był monolitycznym protokołem, który używał CRC-32 do zapewnienia integralności i wymagał od klienta wysłania klucza sesji zaszyfrowanego kluczami RSA serwera. SSH-2 dzieli zadania na warstwę transportową, warstwę uwierzytelniania i warstwę połączenia (RFC 4251 do 4254, styczeń 2006), używa HMAC do integralności i wyprowadza klucze sesji za pomocą Diffie-Hellman, dzięki czemu zarejestrowany ruch pozostaje prywatny nawet w przypadku późniejszej kradzieży klucza hosta. SSH-1 był usuwany z OpenSSH etapami, co zakończyło się w wersji 7.6 w październiku 2017 roku.

Dlaczego OpenSSH zastąpiło oryginalną implementację SSH?

Rozwój oryginalnego oprogramowania przeszedł w stronę produktu komercyjnego z restrykcyjną licencją, a ostatnim swobodnie używalnym wydaniem było ssh 1.2.12. Na początku 1999 roku Björn Grönvall wznowił to wydanie jako OSSH, a zespół OpenBSD stworzył fork OSSH pod nazwą OpenSSH, który został wydany wraz z OpenBSD 2.6 w dniu 1 grudnia 1999 roku. OpenBSD potrzebowało audytowanego kodu na nieograniczonej licencji dla swojego systemu bazowego, a te dwie cechy pozwoliły każdemu innemu systemowi operacyjnemu na dystrybucję tej samej implementacji poprzez gałąź portable.

Dlaczego SSH pyta o klucz hosta przy pierwszym połączeniu?

Ponieważ klient nigdy wcześniej nie widział tego serwera i nie ma z czym porównać jego klucza. Samo szyfrowanie nie pozwala odróżnić uczciwego serwera od maszyny znajdującej się pośrodku ścieżki, dlatego SSH identyfikuje serwery za pomocą klucza i zapisuje to, co zobaczyło w ~/.ssh/known_hosts. Pierwsze połączenie to jedyny moment bez zapisanej wartości do sprawdzenia, dlatego klient pyta o to użytkownika. Należy porównać odcisk palca (fingerprint) z tym uzyskanym z konsoli dostawcy lub bezpośrednio z serwera, a każdy późniejszy komunikat REMOTE HOST IDENTIFICATION HAS CHANGED traktować jako realne zdarzenie, dopóki nie zostanie wyjaśnione.

Dlaczego starsze klucze SSH przestają działać po aktualizacji?

Ponieważ OpenSSH wycofuje algorytmy zgodnie z opublikowanym harmonogramem. Klucze DSA (ssh-dss) zostały domyślnie wyłączone w OpenSSH 7.0 w 2015 roku i całkowicie usunięte w OpenSSH 10.0 w dniu 9 kwietnia 2025 roku. Klucze RSA nadal działają, ale podpisy wykonane za pomocą SHA-1 zostały domyślnie wyłączone w OpenSSH 8.8 we wrześniu 2021 roku, co objawia się jako sign_and_send_pubkey: no mutual signature supported przy próbie połączenia ze starym serwerem. Klucz Ed25519, dostępny od OpenSSH 6.5 w styczniu 2014 roku, pozwala uniknąć obu tych problemów.