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 mają znaczenie, 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ą przesyłaną 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ł być 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 dostęp do WSZYSTKICH tak skonfigurowanych systemów 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 były dostosowane do 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 były do niej zaadresowane. Maszyna, która przestała je ignorować – co oznacza tryb 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.

Biuletyn z 1994 roku wydany bez poprawki

3 lutego 1994 roku CERT opublikował biuletyn CA-94:01, zatytułowany "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 mode 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 przesyłane jest tym samym łączem w formie otwartego tekstu przy pierwszym użyciu. W ramach protokołów telnet lub rlogin nie istniało żadne rozwiązanie tego problemu, 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 polegającego na podsłuchiwaniu haseł, o którym wcześniej ostrzegał CERT. Tatu Ylönen, tamtejszy badacz, napisał zamiennik i udostępnił go jako darmowe oprogramowanie w lipcu 1995 roku. Nazwał go Secure Shell.

O sukcesie zdecydowały dwie decyzje projektowe. Sesja była szyfrowana, więc osoba podsłuchująca segment sieci nie uzyskiwała żadnych użytecznych danych. 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, aby rozwijać i sprzedawać to oprogramowanie.

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 jedynie, że wersja SSH, na której mogła bazować reszta świata, przestała się rozwijać, 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 OpenBSD stworzyło 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ło OpenSSH 1.2.2, które zostało wydane 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ę? Z powodu wymagań, jakie OpenBSD stawiało przed tym oprogramowaniem. OpenBSD dostarcza audytowany system podstawowy, który ma być bezpieczny w domyślnej konfiguracji, więc szyfrowane zdalne logowanie musiało znajdować się w tym systemie, na licencji nieposiadającej żadnych 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ło wydane 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 oznacza możliwość wykonywania poleceń na serwerze.

Wada tkwiła w samym protokole, więc nie można było jej naprawić bez zerwania kompatybilności. Implementacje dostarczane były z detektorem, kodem 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.

Prace nad SSH-2 prowadzono w grupie roboczej IETF o nazwie secsh, a publikację w formie RFC sfinalizowano w styczniu 2006 roku: architekturę w RFC 4251, warstwę transportową w RFC 4253, uwierzytelnianie użytkownika w RFC 4252 oraz warstwę połączenia w RFC 4254. Podział na warstwy jest kluczowy, ponieważ każdą z nich można dzięki temu wymieniać 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 rejestracja ruchu teraz i kradzież klucza hosta później nie przynosi żadnych korzyści. Ta właściwość nazywana jest utajnianiem z wyprzedzeniem (forward secrecy).

SSH-2 nie posiada żadnej kompatybilności na poziomie transmisji z SSH-1. Dlatego zmieniono numer główny, a nie wersję dziesiętną.

Dlaczego usunięto SSH-1 zamiast go naprawiać

Usunięcie protokołu zajęło trzy wydania OpenSSH. Wersja 7.0 z 11 sierpnia 2015 roku domyślnie wyłączyła protokół 1 na etapie kompilacji. Wersja 7.4 z 19 grudnia 2016 roku usunęła jego obsługę po stronie serwera. Wersja 7.6 z 3 października 2017 roku usunęła również obsługę po stronie klienta, wraz z powiązanymi opcjami konfiguracji i dokumentacją.

Pozostawienie tej opcji dla starszego sprzętu byłoby rozwiązaniem bardziej przyjaznym dla użytkownika, jednak mechanizm wykrywania CRC-32 wyjaśnia, dlaczego odrzucono taką możliwość. Przepełnienie było możliwe do wywołania tylko dlatego, że kod protokołu 1 był kompilowany 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 generuje ostrzeżenie o kluczu hosta

Szyfrowanie gwarantuje prywatność ruchu, ale nie potwierdza tożsamości odbiorcy. Jeśli atakujący przechwyci 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 rozwiązuje ten problem 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 nawiązywania połączenia SSH.

Przy pierwszym połączeniu brak jest wcześniejszych danych, 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 powoduje zapisanie klucza w ~/.ssh/known_hosts. Każde kolejne połączenie jest porównywane 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 jest przyznaniem się protokołu do jedynego słabego punktu. Zasada trust on first use oznacza, ż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 korzystania z 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 komunikat bez weryfikacji, co warto otwarcie przyznać.

Jak klucze publiczne wyparły hasła

Uwierzytelnianie kluczem publicznym było dostępne od wczesnych wydań SSH, jednak upowszechnienie się tego standardu zajęło lata. Mechanizm ten jest asymetryczny: klient potwierdza 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 szyfrowanego 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 innych miejscach.

Drugim powodem jest arytmetyka. Każdy serwer z otwartym portem 22 na publicznym adresie otrzymuje całodobowo zautomatyzowane próby logowania, a hasło jest ciągiem znaków, który można odgadnąć. Klucza nie da się odgadnąć w żadnym praktycznym sensie. Ustawienie PasswordAuthentication no kończy tę kategorię ataków, dlatego znajduje się ono na każdej liście kontrolnej utwardzania systemu. Generowanie i rotacja kluczy zostały omówione w podstawy zarządzania kluczami SSH, a ustawienia po stronie serwera w utwardzanie 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 generują wartość nonce 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 odzyskiwano klucze prywatne DSA i ECDSA 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, całkowicie usunęła ten algorytm, co według twórców projektu „zamyka proces wycofywania rozpoczęty w 2015 roku”. Od wyłączenia do usunięcia minęło dziesięć lat.

RSA nie zniknęło, ale jego stary format podpisywania tak. OpenSSH 8.8, wydane 26 września 2021 roku, domyślnie przestało 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, wynika on właśnie z tej zmiany. Klucz użytkownika jest poprawny. Algorytm podpisywania, którego zażądała druga strona, nie jest.

Ten sam proces dotyczy obecnie wymiany kluczy, tym razem wyprzedzając zagrożenia. Ruch przechwycony dzisiaj może zostać zapisany i odszyfrowany po latach przez podmiot, który jako pierwszy będzie dysponował odpowiednim komputerem kwantowym, dlatego uzgadnianie kluczy musiało ulec zmianie, 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ę wadliwy. OpenSSH 9.9, z 19 września 2024 roku, dodało mlkem768x25519-sha256, oparte na ML-KEM (module lattice key encapsulation mechanism), wystandaryzowanym 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 standardu:

** 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.

Ostrzeżenie to jest włączone domyślnie 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 nim, 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 o bezpieczeństwie SSH decyduje przede wszystkim używana wersja. Ustawienia domyślne zawierają decyzje o tym, które algorytmy są oferowane, które odrzucane i jakie ostrzeżenia są wyświetlane. Stary serwer nadal oferuje to, na co pozwalało jego wydanie, i będzie negocjował parametry połączenia w dół, 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 dotykał 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 polegającym na przechwytywaniu haseł w sieci uniwersyteckiej. Ówczesne narzędzia do zdalnego logowania, telnet oraz rlogin, przesyłały hasła w sieci jako tekst jawny, więc każdy monitorujący współdzielony segment sieci mógł przejąć 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 Ylönen założył firmę SSH Communications Security.

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

Są to odrębne 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 oraz warstwę połączenia (RFC 4251 do 4254, styczeń 2006), wykorzystuje HMAC do zapewnienia integralności i wyprowadza klucze sesji za pomocą algorytmu 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ę wraz z wydaniem 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 wydaniem dostępnym na wolnej licencji było ssh 1.2.12. Na początku 1999 roku Björn Grönvall przywrócił to wydanie jako OSSH, a zespół OpenBSD stworzył fork OSSH pod nazwą OpenSSH, który został dołączony do OpenBSD 2.6 w dniu 1 grudnia 1999 roku. OpenBSD wymagało audytowanego kodu na nieograniczonej licencji dla swojego systemu podstawowego, 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ę w środku ścieżki transmisji, dlatego SSH identyfikuje serwery za pomocą klucza i zapisuje jego wartość w ~/.ssh/known_hosts. Pierwsze połączenie to jedyny moment, w którym brakuje zapisanej wartości do weryfikacji, dlatego klient prosi użytkownika o potwierdzenie. Należy porównać odcisk klucza (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śniona jego przyczyna.

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ę błędem sign_and_send_pubkey: no mutual signature supported przy próbie połączenia ze starym serwerem. Klucz Ed25519, dostępny od wersji OpenSSH 6.5 ze stycznia 2014 roku, pozwala uniknąć obu tych problemów.