Nowy OpenSSH: zmiany w szyfrach i co zrobić, by nie zablokować logowania na serwerze

Krótki kontekst: czym jest OpenSSH i dlaczego aktualizacje bywają bolesne

OpenSSH jako brama do serwera, a nie „kolejny pakiet do update’u”

OpenSSH to najczęściej jedyna bezpośrednia brama administracyjna do serwera. Bez działającego SSH nie ma dostępu do konsoli, nie ma możliwości poprawienia konfiguracji, zrestartowania usług ani szybkiej reakcji na awarię. W świecie serwerów linuksowych OpenSSH pełni rolę zamka w drzwiach – jeśli zmieni się sposób działania tego zamka, a klucz (klient, konfiguracja, algorytmy) przestanie pasować, drzwi po prostu się nie otworzą.

Aktualizacja OpenSSH to nie tylko podbicie numeru wersji w systemie. Nowe wydania agresywnie czyszczą stare i słabe algorytmy kryptograficzne, zmieniają domyślne listy szyfrów, a czasem wymuszają nowe typy kluczy. Bez przygotowania może to spowodować, że po restarcie usługi sshd nie da się już zalogować z dotychczas używanych klientów czy skryptów.

Szczególnie dotyczy to środowisk, w których serwer SSH obsługuje nie tylko nowoczesne laptopy administratorów, ale także stare systemy, urządzenia sieciowe, automatyczne skrypty backupu, pipeline’y CI/CD czy różne integracje produkcyjne. Każda z tych rzeczy używa określonych algorytmów i oczekuje, że serwer je nadal zaakceptuje.

Różnica między klientem SSH a serwerem sshd przy aktualizacjach

W pakiecie OpenSSH są dwa główne elementy: program kliencki ssh oraz demon serwera sshd. Oba mogą być aktualizowane, ale skutki są inne.

Gdy aktualizujesz klienta (ssh na swoim laptopie), ryzyko jest mniejsze: zwykle wciąż możesz połączyć się z większością serwerów, chyba że są ekstremalnie stare i obsługują jedynie wycofane algorytmy. Problemem bywa raczej to, że nowy klient odmawia używania przestarzałych kluczy (np. DSA) lub skrótów (SHA1).

Gdy aktualizujesz serwer (sshd na maszynie produkcyjnej), ryzyko jest znacznie większe. Nowy sshd może przestać akceptować algorytmy, z których korzystają stare klienty. Jeśli to jedyny kanał dostępu administracyjnego, a konfiguracja zostanie zbyt agresywnie „odchudzona”, po restarcie usługi możesz zobaczyć tylko lakoniczny komunikat „no matching key exchange method found” lub „no matching host key type found” – i koniec logowania.

Dlaczego bezpieczeństwo wymusza wyłączanie starych algorytmów

Powodem zmian w OpenSSH nie jest złośliwość autorów, ale rozwój kryptografii i rosnąca moc obliczeniowa. Algorytmy, które kiedyś były bezpieczne, dziś można atakować w praktycznym czasie lub mają poważne słabości konstrukcyjne. DSA, krótkie klucze RSA (np. 1024 bity), tryby szyfrowania CBC, czy MAC oparty na samym SHA1 to przykłady mechanizmów, które w nowych wersjach OpenSSH są albo domyślnie wyłączane, albo całkowicie usuwane.

Aktualizacja wymusza więc przejście na nowocześniejsze techniki: Curve25519, Ed25519, szyfry AEAD (np. chacha20-poly1305, aes-gcm). Z punktu widzenia bezpieczeństwa to plus, z punktu widzenia kompatybilności – potencjalny ból. Dlatego do aktualizacji OpenSSH trzeba podchodzić jak do zmiany zamków w drzwiach biura: zanim wymienisz wkładkę, upewnij się, że wszyscy kluczowi pracownicy mają nowe klucze.

Co zmienił nowy OpenSSH w szyfrach i algorytmach

Usuwanie słabych szyfrów, DSA i SHA1 z domyślnych ustawień

W nowszych wersjach OpenSSH widać wyraźny trend: lista domyślnie dostępnych szyfrów i algorytmów zamiast rosnąć, maleje. Znikają lub są wyłączane m.in.:

• szyfry w trybie CBC (np. aes128-cbc, 3des-cbc) – podatne na różne ataki na padding,
• klucze DSA (ssh-dss) – zbyt słabe, opierające się na SHA1,
• stare protokoły wymiany klucza oparte na grupach DH z małymi parametrami,
• podpisy i MAC-y oparte na samym SHA1, a nie na mocniejszych konstrukcjach (SHA2, AEAD).

Często te algorytmy są usuwane z domyślnego zestawu, ale możesz je jeszcze ręcznie włączyć. Jednak w kolejnych wersjach bywa, że znikają całkowicie, więc konfiguracja, która „na siłę” trzyma stare algorytmy, przestaje być nawet poprawna składniowo i sshd nie wystartuje.

Zmiany w listach Ciphers, KexAlgorithms, MACs, HostKeyAlgorithms

OpenSSH przechowuje informacje o dostępnych algorytmach w kilku listach konfiguracyjnych. Najważniejsze z nich to:

• Ciphers – szyfry symetryczne używane po zestawieniu sesji,
• KexAlgorithms – algorytmy wymiany kluczy (key exchange),
• MACs – mechanizmy zapewniające integralność (Message Authentication Code),
• HostKeyAlgorithms – typy kluczy, którymi serwer potwierdza swoją tożsamość.

W starszych wersjach większość z tych list była bardzo szeroka: zawierała zarówno nowoczesne, jak i stare algorytmy. Nowe wydania zmieniają domyślne listy tak, by były krótsze i składały się głównie z nowoczesnych mechanizmów. Przykładowo, z listy Ciphers znikają tryby CBC, a zastępują je szyfry AEAD oraz lepsze implementacje AES w trybie CTR i GCM.

Te zmiany oznaczają, że serwer po aktualizacji może przestać negocjować wspólny zestaw algorytmów ze starym klientem, który nie zna nowych szyfrów, a nadal próbuje używać tych wyłączonych. W efekcie pojawi się błąd „no matching cipher found” lub podobny komunikat powiązany z inną kategorią algorytmu.

Nowe preferencje kluczy: Ed25519 i ECDSA zamiast samego RSA

Przez lata dominującym typem klucza w SSH był RSA. Nowe wersje OpenSSH przesuwają akcent na klucze krzywych eliptycznych (ECC), szczególnie:

• Ed25519 – bardzo szybki, krótki klucz, polecany jako domyślny,
• ECDSA (np. ecdsa-sha2-nistp256) – również oparty na krzywych eliptycznych.

RSA nadal działa, ale jego bezpieczeństwo zależy mocno od długości klucza i użytego algorytmu skrótu. Krótkie klucze RSA (np. 1024 bity) są już dziś zbyt słabe. Dodatkowo OpenSSH zaczyna wymagać podpisów RSA z SHA2 zamiast z SHA1, więc stare klucze generowane lata temu w domyślnej konfiguracji mogą pracować tylko w trybie „legacy”, a z czasem przestaną być akceptowane.

Konsekwencją jest konieczność:

• generowania nowych kluczy użytkowników (autorized_keys) w formie Ed25519 lub RSA z SHA2,
• dodawania nowych kluczy hosta (HostKey) na serwerach, żeby klienci mogli się z nimi dogadać przy nowych ustawieniach.

Wpływ zmian na stare systemy i klientów „legacy”

Zmiany w OpenSSH szczególnie boleśnie odczuwają:

• stare dystrybucje Linuksa (np. bardzo stare CentOS, Debian, Ubuntu LTS),
• urządzenia sieciowe (switch’e, routery, firewalle) z wbudowanym, przestarzałym klientem SSH,
• aplikacje i skrypty z wbudowanymi binarkami lub bibliotekami SSH, których nie da się łatwo zaktualizować,
• systemy backupowe i monitoringowe, które łączą się ze starych hostów tylko z kilkoma przestarzałymi algorytmami.

Jeśli nowy serwer OpenSSH nie będzie akceptował używanych przez te systemy szyfrów i algorytmów, wszystkie te integracje przestaną działać. Czasem jedynym rozwiązaniem jest utrzymanie oddzielnego, bardziej pobłażliwego serwera pośredniczącego, który akceptuje starsze protokoły, podczas gdy główne serwery mają „wyśrubowaną” konfigurację bezpieczeństwa.

Jak sprawdzić, jaką wersję OpenSSH i jakie szyfry masz teraz

Sprawdzenie wersji klienta i serwera

Podstawą jest wiedza, co właściwie działa w danym momencie. Na maszynie, z której się łączysz, sprawdź wersję klienta SSH:

ssh -V

Na serwerze, jeśli masz dostęp, spójrz na pakiet i wersję sshd. W zależności od systemu mogą to być komendy:

sshd -V        # nie zawsze dostępne, w wielu distro wypisuje tylko błędy
sudo sshd -T  | head  # pokazuje efektywną konfigurację i pośrednio wersję

# lub z poziomu systemu pakietów
dpkg -l | grep -i openssh      # Debian/Ubuntu
rpm -qa | grep -i openssh      # RHEL/CentOS/Rocky
apk info openssh               # Alpine

Znając wersję OpenSSH, możesz w dokumentacji (man 5 sshd_config, CHANGELOG) sprawdzić, które algorytmy zostały domyślnie wyłączone lub usunięte w tej wersji.

Wylistowanie obsługiwanych algorytmów po stronie klienta

Klient OpenSSH ma wygodną opcję -Q, która pozwala zobaczyć, jakie algorytmy zna i może zaproponować przy połączeniu:

# Lista obsługiwanych szyfrów
ssh -Q cipher

# Lista algorytmów wymiany kluczy
ssh -Q kex

# Lista obsługiwanych typów kluczy hosta
ssh -Q key

# Lista MAC (integrity)
ssh -Q mac

Te komendy działają lokalnie, bez łączenia się z serwerem. Pokazują, z jakiego „magazynu narzędzi” korzysta twój klient. Aby połączenie się udało, serwer musi mieć przynajmniej jeden wspólny algorytm w każdej kategorii.

Odczyt efektywnej konfiguracji serwera: sshd -T

Konieczna jest również znajomość tego, jak serwer jest skonfigurowany. Konfiguracja jest w pliku /etc/ssh/sshd_config, ale nie wszystkie opcje są tam jawnie zdefiniowane. Część pochodzi z ustawień domyślnych danego wydania.

Efektywną konfigurację wyświetla polecenie:

sudo sshd -T

Wyjście jest długie, ale możesz przefiltrować interesujące cię linie:

sudo sshd -T | egrep 'ciphers|kexalgorithms|macs|hostkey'

W ten sposób widzisz, jakie dokładnie listy algorytmów obowiązują po uwzględnieniu pliku sshd_config i ustawień domyślnych wersji. To ważne, bo niekiedy admin próbuje ręcznie wymusić stare algorytmy, a nowa wersja OpenSSH po prostu je ignoruje lub zgłasza błąd przy starcie.

Przykład różnicy list algorytmów przed i po aktualizacji

Żeby uchwycić różnicę, dobrym nawykiem jest zapisanie listy algorytmów przed aktualizacją i porównanie jej po update. Można to zrobić prostym sposobem:

# PRZED aktualizacją, na serwerze
sudo sshd -T | egrep 'ciphers|kexalgorithms|macs|hostkey' > /root/sshd-algos-before.txt

# PO aktualizacji
sudo sshd -T | egrep 'ciphers|kexalgorithms|macs|hostkey' > /root/sshd-algos-after.txt

diff -u /root/sshd-algos-before.txt /root/sshd-algos-after.txt

Różnice w pliku pokażą, które algorytmy wypadły, a które doszły, a także czy np. zmieniła się preferencja rodzaju HostKey. Dzięki temu łatwiej ocenić, które skrypty i systemy mogą mieć problem z nowymi ustawieniami.

Najważniejsze typy algorytmów w SSH i jak na nie patrzeć praktycznie

Cztery kategorie algorytmów w SSH

Protokół SSH składa się z kilku „warstw kryptograficznych”, każda odpowiedzialna za coś innego. Z praktycznego punktu widzenia liczą się cztery kategorie:

• Kex (Key Exchange Algorithms) – algorytmy wymiany klucza. Pozwalają obydwu stronom ustalić wspólny sekretny klucz bez jego przesyłania wprost.
• HostKey (HostKeyAlgorithms) – typ klucza serwera, używany do potwierdzenia tożsamości hosta (porównywany z known_hosts po stronie klienta).
• Ciphers – szyfry symetryczne używane do kodowania danych w trakcie sesji.
• MACs (Message Authentication Code) – mechanizmy zapewniające, że dane w trakcie transmisji nie zostały zmodyfikowane.

Podczas nawiązywania połączenia klient i serwer negocjują zestaw algorytmów z każdej kategorii. Jeśli chociaż dla jednej nie znajdą wspólnego mianownika, połączenie nie dojdzie do skutku.

Jak brak jednego typu algorytmu blokuje logowanie

Negocjacja w SSH jest następująca: klient wysyła listę algorytmów, które zna i akceptuje, serwer robi to samo, a następnie wybierane są pierwsze wspólne z list (według priorytetu). Jeśli np.:

• serwer nie akceptuje żadnego z kluczy hosta, które klient jest w stanie zweryfikować (HostKeyAlgorithms),

Praktyczne spojrzenie na każdy z typów algorytmów

Z perspektywy admina kluczowe pytanie brzmi nie „który algorytm jest teoretycznie najładniejszy kryptograficznie”, tylko „co mogę bezpiecznie zostawić, a co muszę wyciąć, żeby nic nie wybuchło”.

Najprostsza praktyczna klasyfikacja wygląda mniej więcej tak:

• Kex: stawiaj na algorytmy z dopiskiem curve25519 i ecdh-sha2-nistp*. Klasyczne diffie-hellman-group1-sha1 i inne z krótkimi grupami – tylko w trybie „izolowane getto” dla muzealnych urządzeń.
• HostKey: preferuj ssh-ed25519; trzymaj rsa-sha2-256 / rsa-sha2-512 na potrzeby starszych klientów. Stare ssh-rsa (z SHA1) traktuj jako tymczasowe zło konieczne.
• Ciphers: ustaw domyślnie chacha20-poly1305@openssh.com oraz AES w trybie gcm@openssh.com lub ctr. Tryby cbc – tylko jeśli naprawdę musisz i na osobnym serwerze.
• MACs: szukaj hmac-sha2-* oraz etm@openssh.com (Encrypt-then-MAC). Stare hmac-sha1 i MD5 to już wyłącznie wsparcie awaryjne.

Z takim „mentalnym katalogiem” łatwiej podjąć decyzję: jeśli widzisz w logach, że stary serwer UPS próbuje się dogadać tylko po diffie-hellman-group1-sha1 i 3des-cbc, od razu wiadomo, że problem leży po jego stronie, a nie w „zepsutym nowym OpenSSH”.

Jak zdiagnozować, który algorytm blokuje połączenie

Gdy po aktualizacji połączenia przestają działać, pierwsze odruchy bywa różne: jedni cofają pakiety, inni włączają „wszystko, co się da” w sshd_config. Dużo rozsądniej jest najpierw zobaczyć, która kategoria algorytmów faktycznie nie znajduje wspólnego mianownika.

Pomaga w tym tryb debug klienta SSH:

ssh -vvv user@twoj-serwer

Przy błędach negocjacji zobaczysz komunikaty typu:

• no matching key exchange method found,
• no matching cipher found,
• no matching host key type found,
• no matching mac found.

Dodatkowo klient wyświetli listy algorytmów, które proponuje każda strona. To działa jak „podgląd protokołu”: jednym rzutem oka widzisz, czy problem dotyczy szyfrów, Kex, czy kluczy hosta.

Dlaczego nie każda „zgodność w dół” jest dobrym pomysłem

Pokusa jest jasna: skoro coś przestało działać, najłatwiej dopisać stary algorytm do sshd_config i po sprawie. Problem w tym, że wiele z tych mechanizmów nie jest już tylko „niezalecanych”, ale po prostu niebezpiecznych. Przykład: archaiczny diffie-hellman-group1-sha1 bazuje na zbyt krótkich parametrach i słabym skrócie, więc atakujący ma o wiele łatwiejsze zadanie.

Dlatego sensowna strategia jest dwuetapowa:

1. minimalne, tymczasowe otwarcie – przywrócenie tylko tego, co absolutnie niezbędne, najlepiej z dodatkowymi ograniczeniami (np. tylko z konkretnych IP),
2. plan wyprowadzenia „legacy” z produkcji – wymiana urządzeń/klientów albo przeniesienie ich na osobny serwer pośredniczący.

Co konkretnie może przestać działać po aktualizacji OpenSSH

Typowe objawy z punktu widzenia użytkownika i skryptów

Z zewnątrz wszystko wygląda bardzo zwyczajnie: ktoś próbuje się zalogować i… coś jest nie tak. Najczęstsze scenariusze:

• Interaktywne logowanie użytkownika kończy się komunikatem błędu od razu po podaniu komendy ssh, zanim pojawi się pytanie o hasło czy klucz.
• Skrypty CRON/CI, które wcześniej bezgłośnie wykonywały kopie zapasowe albo wysyłały logi, nagle zaczynają generować błędy „connection failed”, a dane przestają spływać.
• Monitoring przestaje widzieć serwery, bo jego agent SSH jest zbyt stary, by uzyskać połączenie z odświeżonym serwerem.

Grunt, żeby nie zrzucać od razu winy na sieć czy firewalla – często jedyną zmianą jest nowe OpenSSH z zaostrzonym zestawem algorytmów.

Wycofanie SHA1 dla RSA: kiedy „ssh-rsa” nagle dorzuca kłody pod nogi

Nowsze wydania OpenSSH zaczynają wyłączać podpisy ssh-rsa, czyli kombinację RSA + SHA1, zarówno dla kluczy użytkowników, jak i kluczy hosta. W praktyce oznacza to, że:

• stare klucze w ~/.ssh/authorized_keys, wygenerowane lata temu jako domyślne ssh-rsa, mogą być ignorowane,
• stare wpisy w known_hosts (typu ssh-rsa) przestaną pasować do serwera, który preferuje rsa-sha2-256 lub ssh-ed25519.

Skutkiem są błędy znane z codzienności:

no matching host key type found. Their offer: ssh-rsa

lub odmowy logowania kluczem, mimo że klucz wygląda na poprawnie skonfigurowany.

Wyłączone szyfry CBC i słabe MAC: starzy klienci zostają za burtą

Gdy z domyślnej listy znikają *cbc i słabe MAC-y (np. hmac-sha1 bez dodatków), niektóre stare implementacje SSH nie mają już z czym negocjować. Typowa sytuacja:

• stary skrypt wbudowany w aplikację Java używa BouncyCastle z bardzo ograniczonym zestawem szyfrów – tylko aes128-cbc i 3des-cbc,
• nowy serwer SSH akceptuje głównie chacha20-poly1305@openssh.com oraz aes*-gcm@openssh.com, żadnego CBC,
• negocjacja kończy się błędem „no matching cipher found”.

Z zewnątrz widać tylko to, że skrypt nagle „przestał działać po aktualizacji systemu”. Dopiero dokładny log z ssh -vvv albo logi z /var/log/auth.log / journalctl -u ssh pokazują właściwą przyczynę.

Zmiany w Kex: „no matching key exchange method found”

Wymiana klucza (Kex) to pierwszy etap budowania szyfrowanego kanału. Usunięcie starych metod, takich jak diffie-hellman-group1-sha1 czy słabych grup group14 z SHA1, sprawia, że bardzo stare implementacje nie są w stanie zaproponować niczego, co serwer by zaakceptował.

Objaw w logach klienta:

no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

Jeśli po stronie serwera widać tylko krótkie próby połączenia i natychmiastowe rozłączenia, warto uważnie przejrzeć logi klienta lub, w przypadku urządzeń sieciowych, sięgnąć do ich diagnostyki (często w GUI lub przez konsolę szeregową).

Słabe klucze hosta i brak zgodności z nowymi klientami

Po aktualizacji serwera często generowane są nowe klucze hosta, na przykład ssh-ed25519 oraz nowe RSA. Jeżeli jednak pozostawiono wyłącznie stary, słaby typ (np. jedynie ssh-rsa 1024 bity), nowsi klienci mogą odmówić użycia takiego klucza w domyślnej konfiguracji.

Może to mieć postać ostrzeżeń lub nawet twardych błędów, w zależności od wersji klienta i ustawień bezpieczeństwa. W praktyce rozwiązuje się to przez:

• wygenerowanie nowych kluczy hosta w rekomendowanych formatach (np. /etc/ssh/ssh_host_ed25519_key),
• zaktualizowanie wpisów known_hosts po stronie klientów.

Bezpieczna ścieżka aktualizacji: jak się przygotować, zanim klikniesz „update”

Inwentaryzacja: kto łączy się z twoim serwerem i skąd

Zanim systemy dostaną nową wersję OpenSSH z repozytorium, dobrze wiedzieć, z jakimi klientami serwer ma codziennie do czynienia. Osobna kategoria to użytkownicy interaktywni, a osobna – automaty.

Pomocne zestaw kroków:

• Przejrzyj logi SSH z ostatnich dni/tygodni (/var/log/auth.log, /var/log/secure, journalctl -u ssh) i wypisz IP oraz nazwy hostów, z których następują połączenia.
• Oszacuj, które z nich to:
  • normalni użytkownicy (administracja, devy),
  • systemy backupu, CI/CD, monitoringu, skrypty synchronizujące pliki,
  • urządzenia (routery, switch’e, macierze, UPS-y itp.).

Następnie, tam gdzie się da, sprawdź wersję ich klienta SSH (lub choćby rocznik firmware’u w urządzeniach). Już sama informacja, że coś działa na „bardzo starym Debianie” albo „firmware sprzed dekady”, sygnalizuje potencjalny problem.

Testowe środowisko lub serwer „kanarek”

Dużo bezpieczniej jest najpierw zaktualizować jeden serwer testowy lub mniej krytyczny host zamiast całej farmy. Ten „kanarek” pomoże wyłapać niekompatybilne systemy zanim usługa produkcyjna stanie.

Prosty plan działania:

1. Wybierz serwer testowy z podobną konfiguracją SSH jak produkcja.
2. Zaktualizuj na nim OpenSSH z zachowaniem logów i kopii sshd_config.
3. Poproś użytkowników i automaty (tam, gdzie to możliwe) o przetestowanie połączeń na serwerze testowym – najlepiej odzwierciedlając realne scenariusze (skrypty, backupy, scp/rsync).

Jeśli coś nie zadziała, zyskujesz szansę, by poprawić konfigurację albo zaktualizować klienta, zanim dotknie to głównego serwera.

Kopie zapasowe konfiguracji i kluczy

Przed każdą większą zmianą w OpenSSH warto odłożyć na bok kilka plików:

• /etc/ssh/sshd_config – konfiguracja serwera,
• klucze hosta /etc/ssh/ssh_host_*,
• opcjonalnie: ~/.ssh/known_hosts i ~/.ssh/config użytkowników serwisowych (jeśli są używane w automatach).

Zrobienie prostego tarballa lub skopiowanie tych plików na inny host potrafi uratować sporo nerwów, gdyby coś poszło nie tak i trzeba było szybko wrócić do znanego stanu.

Plan awaryjny: jak wrócić do starej wersji albo poprzedniej konfiguracji

Każda aktualizacja krytycznego komponentu powinna mieć spisany scenariusz „co robię, jeśli się nie uda”. Możliwości jest kilka:

• przywrócenie poprzedniego pakietu OpenSSH (downgrade z cache menedżera pakietów lub z backupu repozytorium),
• przywrócenie starego sshd_config i restart usługi SSH,
• tymczasowe uruchomienie dodatkowego demona SSH na innym porcie z „łagodniejszą” konfiguracją.

Ten ostatni wariant jest często najbardziej pragmatyczny: aktualizujesz właściwy serwer, ale na porcie np. 2222 uruchamiasz osobny proces sshd z własnym plikiem konfiguracyjnym, który przez jakiś czas utrzymuje kompatybilność ze starymi klientami.

Modyfikacja konfiguracji sshd_config krok po kroku, z myślą o kompatybilności

Ścieżka kompromisu: nowoczesne domyślne + odrobina „legacy”

Celem jest konfiguracja, która:

• dla większości współczesnych klientów będzie oferować silne, nowoczesne algorytmy,
• dla kilku znanych starych systemów utrzyma minimalne, świadomie zaakceptowane ustępstwa.

Dobry punkt wyjścia to sprawdzenie, co oferuje sama wersja OpenSSH bez ręcznego „grzebania”:

sudo sshd -T | egrep 'ciphers|kexalgorithms|macs|hostkey'

Na tej bazie można dodać kilka linijek do /etc/ssh/sshd_config, zamiast przepisywać wszystko od zera.

Ustawienie listy HostKey i algorytmów kluczy hosta

Najpierw warto zadbać o to, jakich kluczy hosta serwer używa i reklamuje:

Przykładowa konfiguracja HostKey dla serwera „pomiędzy epokami”

Na wielu serwerach dobrym ustawieniem startowym jest zestaw: nowoczesny ed25519, mocny RSA z SHA-2 oraz – tylko jeśli naprawdę jest potrzebny – jeden klucz ECDSA. W /etc/ssh/sshd_config może to wyglądać tak:

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key

Kolejność ma znaczenie: serwer w pierwszej kolejności proponuje pierwszy klucz z listy. Ed25519 jest szybki i dobrze wspierany przez nowe klienty, więc zwykle warto, by szedł na początek.

Jeśli klucze jeszcze nie istnieją, można je dogenerować:

sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''
sudo ssh-keygen -t rsa -b 4096 -o -a 100 
  -f /etc/ssh/ssh_host_rsa_key -N ''

Po zmianach konieczny jest restart lub przynajmniej przeładowanie konfiguracji:

sudo systemctl reload sshd   # lub ssh na niektórych dystrybucjach
# jeśli reload się nie powiedzie, użyj:
sudo systemctl restart sshd

Świadome włączanie „legacy” dla kluczy hosta

Czasem nowy serwer musi dogadać się z czymś naprawdę starym, co rozumie wyłącznie ssh-rsa z SHA1. Zamiast rozluźniać cały serwer, lepiej przygotować tymczasowy kanał awaryjny:

1. Skopiuj /etc/ssh/sshd_config do np. /etc/ssh/sshd_legacy.conf.
2. W pliku „legacy” dopisz osobny port i łagodniejsze ustawienia.

Przykładowy kawałek takiej konfiguracji:

Port 2222
HostKey /etc/ssh/ssh_host_rsa_key

# Pozwól na ssh-rsa wyłącznie na tym porcie
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

Takiego dodatkowego demona uruchamia się ręcznie:

sudo /usr/sbin/sshd -f /etc/ssh/sshd_legacy.conf -D

Można go też odpalić w screen/tmux lub jako oddzielną jednostkę systemd. Dzięki temu stary sprzęt dalej łączy się na porcie 2222, a główny port 22 pozostaje „czysty”.

Dopasowanie listy szyfrów (Ciphers)

Nowe OpenSSH domyślnie proponuje bardzo sensowną listę szyfrów. Czasem jednak potrzebne jest drobne rozszerzenie, gdy w inwentaryzacji wyszły staruszki wymagające CBC.

Najpierw warto zobaczyć aktualne ustawienia efektywne:

sudo sshd -T | grep ciphers

Jeżeli nic nie zmieniano ręcznie, wynik będzie czymś w stylu:

ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,...

Jeżeli trzeba dodać AES-CBC tylko dla kilku maszyn, lepiej nie pisać nowej listy od zera, ale użyć dopisku z plusem:

Ciphers $(sshd -T | sed -n 's/^ciphers //p'),aes128-cbc

To wariant „dla cierpliwych”, bo wymaga jednorazowego wklejenia listy. Częściej stosuje się po prostu jawnie ustawioną, nowoczesną listę z jednym dodatkiem:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,
aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,
aes128-cbc

Ostatni element – aes128-cbc – powinien być na końcu, żeby był używany tylko wtedy, gdy klient naprawdę nie obsługuje nic lepszego.

MAC-y i integralność danych: utrzymać balans

MAC to „podpis” każdego pakietu, który chroni przed cichym podmianieniem danych. Stare kombinacje z samym SHA1 są dziś uważane za słabe, ale niektóre urządzenia nadal je wykorzystują.

Dobry kompromis w konfiguracji serwera może wyglądać tak:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
hmac-sha2-512,hmac-sha2-256,hmac-sha1

Element hmac-sha1 to już ukłon w stronę „legacy”. Jeśli po inwentaryzacji wiesz, że nie masz żadnego takiego klienta, usuń go i zostaw tylko wersje z SHA-2.

KexAlgorithms: przywracanie pojedynczych metod dla wyjątków

Wymiana klucza (Kex) jest szczególnie newralgiczna. Najstarszy i najbardziej problematyczny algorytm, diffie-hellman-group1-sha1, bywa potrzebny jedynie do kilku egzemplarzy bardzo starego sprzętu sieciowego.

Jeżeli taki sprzęt nadal jest w użyciu i nie ma dostępnego firmware’u, który poprawia SSH, można lokalnie dopisać wymianę klucza w konfiguracji:

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,
ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,
diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,
diffie-hellman-group1-sha1

Podobnie jak w przypadku CBC, słaby algorytm ląduje na końcu listy. Jeśli ma z niego korzystać dosłownie jeden router, rozsądniej jest jednak:

• wyłączyć go w globalnej konfiguracji,
• w razie potrzeby uruchamiać osobny sshd z dedykowanym plikiem konfiguracyjnym i portem, jak w przykładzie „legacy”.

Granice po stronie klienta: ForcedCommand, Match i selektywne ustępstwa

Gdy kilka starszych klientów musi korzystać z ustępstw bezpieczeństwa, dobrze jest mieć nad nimi większą kontrolę niż tylko „wpuszczamy wszystkich”. Jednym z narzędzi jest sekcja Match w sshd_config, która działa jak prosty firewall na poziomie konfiguracji.

Przykładowo, dla konkretnego adresu IP można zezwolić na słabszy zestaw algorytmów, ale od razu ograniczyć, co taki klient może robić:

Match Address 192.0.2.10
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc
  MACs +hmac-sha1
  PermitTunnel no
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand /usr/local/sbin/legacy-backup-wrapper.sh

Dzięki temu stary system backupowy dostaje to, czego potrzebuje do połączenia, ale nie ma możliwości tunelowania, forwardowania ani interaktywnego logowania. Z punktu widzenia ryzyka jest to zupełnie inna sytuacja niż globalne otwarcie starych szyfrów dla całego świata.

Delikatne przejście z „ssh-rsa” na „rsa-sha2-*” w kluczach użytkowników

Gdy nowy OpenSSH zaczyna ignorować ssh-rsa jako metodę podpisu, stare klucze użytkowników przestają działać, mimo że sam materiał klucza RSA jest nadal bezpieczny. Sercem problemu nie jest długość klucza, tylko to, że podpis jest liczony z użyciem SHA1.

Jeśli masz klucze RSA użytkowników w ~/.ssh/authorized_keys, nie trzeba ich od razu wyrzucać. Można na pewien czas dopuścić nowe metody podpisu dla starych kluczy:

PubkeyAcceptedAlgorithms +rsa-sha2-256,rsa-sha2-512

Klient po swojej stronie również musi umieć użyć SHA-2 do podpisu. Nowe wersje OpenSSH robią to same, ale bardzo stare (sprzed kilku lat) będą upierać się przy ssh-rsa. Na takich maszynach często prościej jest wygenerować całkowicie nowy klucz, np. Ed25519:

ssh-keygen -t ed25519 -C "user@host"

Świeży klucz wklejasz na serwer do authorized_keys, a stary zostawiasz przez jakiś czas jako zapas. Po okresie przejściowym możesz stopniowo usuwać wpisy ssh-rsa i w końcu odciąć SHA1 całkowicie.

Kontrola po aktualizacji: jak weryfikować, czy wszystko działa

Po zmianach w konfiguracji i aktualizacji OpenSSH warto przez kilka godzin lub dni uważniej patrzeć na logi. Dwa miejsca są szczególnie przydatne:

• logi serwera: /var/log/auth.log, /var/log/secure lub journalctl -u sshd,
• logi po stronie klientów, zwłaszcza te włączone przełącznikiem -vvv.

Dla systemów automatycznych, które łączą się regularnie, można na pewien czas dołożyć prosty monitoring typu „czy w ostatniej godzinie wykonano backup/rsync/CI na serwerze X”. Często to właśnie brak takiej aktywności jako pierwszy sygnalizuje, że któryś skrypt nie przeżył zaostrzenia algorytmów.

Jak nie zablokować sobie logowania: praktyczne scenariusze i procedury

Klasyczny błąd: edycja sshd_config przez SSH bez planu B

Najbardziej typowy scenariusz awarii to edycja sshd_config zdalnie, zapis, szybki systemctl restart sshd i… cisza. Jeżeli nowa konfiguracja ma błąd składni lub wycina algorytmy potrzebne do twojego połączenia, sesja znika, a kolejne połączenia odbijają się od serwera.

Aby tego uniknąć, dobrze jest trzymać się trzech prostych zasad:

1. Nie restartuj od razu – użyj najpierw sprawdzenia konfiguracji:

   sudo sshd -t

   Jeżeli nic nie wypisze, składnia jest poprawna. Jeśli pojawi się komunikat o błędzie, popraw go przed restartem.

2. Najpierw spróbuj przeładowania zamiast twardego restartu:

   sudo systemctl reload sshd

   Przy przeładowaniu istniejące sesje zwykle pozostają żywe, więc masz „link ratunkowy”.

3. Otwórz równolegle drugą sesję SSH i nie zamykaj jej, dopóki nie sprawdzisz, że nowe połączenia działają poprawnie.

Awaryjna konsola: dostęp przez IPMI, hypervisor, chmurę

Jeśli serwer jest fizyczny, warto od razu sprawdzić, czy istnieje zdalna konsola (IPMI, iLO, DRAC). W maszynach wirtualnych podobną rolę pełni konsola hypervisora lub panelu w chmurze. Dzięki temu nawet całkowita utrata SSH nie oznacza wyjazdu do serwerowni.

Przykładowa procedura „twardego” ratunku:

1. Logujesz się na konsolę przez IPMI/hypervisor.
2. Sprawdzasz, czy sshd w ogóle działa:

   sudo systemctl status sshd

3. Jeżeli problemem jest jedynie zła konfiguracja, przywracasz poprzedni plik z kopii:

   sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
   sudo systemctl restart sshd

Gdy taką ścieżkę ratunkową ma się przygotowaną zawczasu (hasła do IPMI, dostęp do panelu chmury), ryzyko „zamurowania się” spada dramatycznie.

Testy przedprodukcyjne „na żywym organizmie”, ale bez ryzyka

Nawet jeśli masz serwer testowy, wiele subtelnych problemów wychodzi dopiero na produkcji. Da się jednak zrobić mini-test na tym samym hostcie, bez ryzyka utraty dostępu.

Przykład podejścia krok po kroku:

1. Skopiuj aktualny plik konfiguracyjny:

   sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.new

2. W pliku sshd_config.new wprowadź nowe ustawienia portu i algorytmów, np.:

   Port 2222
   ListenAddress 0.0.0.0

3. Uruchom dodatkowego demona SSH ręcznie:

   sudo /usr/sbin/sshd -f /etc/ssh/sshd_config.new -p 2222 -D

4. Z innego terminala spróbuj się połączyć:

   ssh -p 2222 user@twoj-serwer

Jeśli wszystko działa, przenosisz sprawdzone ustawienia do głównego sshd_config i dopiero wtedy robisz reload na standardowym porcie 22.

Klienci z ograniczonymi algorytmami: jak ratować pojedyncze połączenia

Zdarza się, że po aktualizacji serwera nagle przestaje działać tylko jedno krytyczne połączenie – na przykład stary skrypt scp uruchamiany z innego serwera. Nie zawsze trzeba od razu modyfikować konfigurację całego serwera.

W prostszych przypadkach wystarcza dostosowanie klienta. W ~/.ssh/config na maszynie-kliencie można dla konkretnego hosta wymusić inne algorytmy:

Host backup-serwer
  HostName 203.0.113.5
  User backup
  KexAlgorithms +diffie-hellman-group14-sha1
  Ciphers +aes128-cbc
  MACs +hmac-sha1

Dzięki temu jedynie to połączenie użyje starszych metod, a reszta komunikacji z serwerami pozostanie nowoczesna. Jest to bezpieczniejsze niż globalne poluzowanie sshd_config po stronie serwera.

Zmiana kluczy hosta bez paniki użytkowników

Najważniejsze wnioski

• OpenSSH to krytyczna „zamek w drzwiach” do serwera – błędna lub nieprzemyślana aktualizacja może całkowicie odciąć dostęp administracyjny.
• Aktualizacja klienta ssh jest zwykle mniej ryzykowna niż aktualizacja serwera sshd; to serwer decyduje, jakie algorytmy są akceptowane, więc jego zmiana może nagle zablokować logowanie ze starych klientów i skryptów.
• Nowe wersje OpenSSH agresywnie usuwają lub domyślnie wyłączają słabe mechanizmy (DSA, krótkie RSA, szyfry CBC, MAC-y oparte na czystym SHA1), co poprawia bezpieczeństwo, ale psuje kompatybilność z przestarzałymi systemami.
• Domyślne listy Ciphers, KexAlgorithms, MACs i HostKeyAlgorithms są dziś krótsze i „nowocześniejsze”; jeśli klient zna tylko stare algorytmy, negocjacja połączenia kończy się błędami typu „no matching cipher/key exchange/host key found”.
• RSA przestaje być jedynym „domyślnym” kluczem – OpenSSH preferuje nowoczesne klucze eliptyczne (Ed25519, ECDSA), a stare klucze RSA (zwłaszcza 1024-bitowe i ze starymi podpisami SHA1) mogą przestać być akceptowane.
• Sztuczne „trzymanie przy życiu” starych algorytmów w konfiguracji ma krótkie nogi: w kolejnych wersjach bywają one usuwane całkowicie, co potrafi uniemożliwić start sshd po aktualizacji.
• Przed podniesieniem wersji OpenSSH na serwerze trzeba sprawdzić, jakie algorytmy i typy kluczy wykorzystują wszystkie podłączające się systemy (laptopy adminów, routery, backupy, CI/CD) i zawczasu zaplanować ich modernizację.