Opublikowane w przez Tomasz

OpenSSH 10 na Ubuntu 26.04 LTS – co sprawdzić przed aktualizacją

Aktualizacja OpenSSH zwykle nie budzi emocji do momentu, w którym po restarcie serwera nie można się zalogować. Przy Ubuntu 26.04 LTS warto poświęcić SSH kilka minut więcej, bo przeskok z OpenSSH 9.6p1 z Ubuntu 24.04 LTS do OpenSSH 10.2p1 wnosi zmiany, które mogą dotknąć stare klucze, stare urządzenia i ręcznie dopisywane algorytmy w konfiguracji.

Nie chodzi o to, żeby bać się aktualizacji. Chodzi o to, żeby przed oknem serwisowym wiedzieć, czy w środowisku nadal działa coś opartego o stare DSA, stare rekordy SSHFP, nietypowe PubkeyAcceptedAlgorithms albo skrypty, które łączą się po SSH z urządzeniami pamiętającymi poprzednie epoki.

Dlaczego temat jest aktualny

Ubuntu 26.04 LTS w release notes podaje, że aktualizacja z Ubuntu 24.04 LTS oznacza zmianę OpenSSH z 9.6p1 do 10.2p1. Wśród istotnych zmian są:

  • usunięcie obsługi słabego algorytmu DSA,
  • ostrzeżenia przy negocjacji algorytmu wymiany kluczy, który nie jest post-quantum,
  • domyślnie dostępny hybrydowy algorytm mlkem768x25519-sha256,
  • nowa opcja PerSourcePenalties,
  • alias sshd.service do ssh.service,
  • brak generowania host key DSA.

OpenSSH upstream opisuje też, że w OpenSSH 10.0 algorytm DSA został usunięty po długim procesie wygaszania, a mlkem768x25519-sha256 jest domyślnie używany do key agreement. W praktyce administrator powinien sprawdzić, czy nie ma w firmie starych klientów, starych przełączników, skanerów, NAS-ów albo skryptów, które opierają się na przestarzałej konfiguracji.

1. Sprawdź wersję i aktualną konfigurację

Na serwerze przed aktualizacją:

ssh -V
sudo sshd -t
sudo sshd -T | less

sshd -t sprawdza składnię konfiguracji. sshd -T pokazuje efektywną konfigurację po uwzględnieniu domyślnych wartości i części opcji. To dobry punkt startowy, bo wiele problemów z SSH wynika z wpisów dodanych kilka lat temu „na chwilę”.

Warto od razu zapisać konfigurację:

sudo cp -a /etc/ssh /root/ssh-config-before-upgrade
sudo sshd -T > /root/sshd-effective-before-upgrade.txt

Jeżeli masz zarządzanie konfiguracją, zapisz też wersję w Git albo w systemie dokumentacji.

2. Poszukaj starych algorytmów w konfiguracji

Najczęściej problemem nie jest domyślna konfiguracja OpenSSH, tylko ręczne dopiski w /etc/ssh/sshd_config, /etc/ssh/ssh_config, plikach w /etc/ssh/sshd_config.d/ albo konfiguracji użytkownika w ~/.ssh/config.

Sprawdź:

sudo grep -RniE "dss|dsa|ssh-rsa|HostKeyAlgorithms|PubkeyAcceptedAlgorithms|KexAlgorithms|CASignatureAlgorithms" /etc/ssh
grep -RniE "dss|dsa|ssh-rsa|HostKeyAlgorithms|PubkeyAcceptedAlgorithms|KexAlgorithms" ~/.ssh 2>/dev/null

Samo wystąpienie ssh-rsa nie zawsze oznacza awarię. Często jest to stary wpis dodany po błędzie typu no matching host key type found. Problem zaczyna się wtedy, gdy serwer albo klient działa tylko dlatego, że wymuszasz stare algorytmy.

3. DSA trzeba traktować jako temat zamknięty

DSA w SSH było wyłączane i ostrzegane od lat. W OpenSSH 10 obsługa słabego DSA została usunięta. Jeżeli gdzieś masz jeszcze klucze ssh-dss, nie planuj ich „ratować” kolejną opcją w konfiguracji.

Sprawdzenie host keys:

ls -l /etc/ssh/ssh_host_*key*
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Szukanie kluczy DSA:

find /etc/ssh ~/.ssh -type f -name "*.pub" -exec grep -H "ssh-dss" {} \; 2>/dev/null

Jeżeli znajdziesz ssh-dss, wymień klucz. Dla zwykłego dostępu użytkownika najczęściej wybierzesz Ed25519:

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

Potem trzeba dodać nowy klucz publiczny do authorized_keys na serwerze i sprawdzić logowanie w osobnej sesji, zanim usuniesz stary dostęp.

4. Uważaj na stare urządzenia sieciowe

Najwięcej problemów z algorytmami SSH zwykle wychodzi nie na nowych serwerach, tylko na starszych urządzeniach:

  • stare switche,
  • routery,
  • urządzenia CCTV,
  • starsze NAS-y,
  • stare kontrolery,
  • sprzęt, który nie dostaje już aktualizacji firmware.

Jeżeli z serwera wykonujesz backup konfiguracji po SSH albo SCP, sprawdź te połączenia przed aktualizacją:

ssh -vvv user@adres-urzadzenia

W wyjściu debug zobaczysz negocjowane algorytmy. Jeżeli połączenie działa tylko po dopisaniu starych KexAlgorithms, HostKeyAlgorithms albo PubkeyAcceptedAlgorithms, zapisz to w dokumentacji i zaplanuj wymianę albo aktualizację firmware. Takie wyjątki nie powinny żyć w konfiguracji bezterminowo.

5. Sprawdź dostęp awaryjny przed restartem SSH

Przed aktualizacją OpenSSH albo zmianą sshd_config musisz mieć drugi kanał dostępu. To może być:

  • konsola w panelu VPS,
  • konsola VM w Proxmox/VMware/Hyper-V,
  • IPMI/iDRAC/iLO,
  • fizyczny dostęp,
  • drugi aktywny terminal SSH, którego nie zamykasz podczas testów.

Po zmianie konfiguracji:

sudo sshd -t
sudo systemctl reload ssh

Nie restartuj bezmyślnie usługi na zdalnym serwerze, jeżeli nie masz dostępu awaryjnego. Reload zwykle wystarczy po zmianie konfiguracji i jest mniej ryzykowny niż twardy restart usługi.

6. PerSourcePenalties – mniej hałasu od kiepskich klientów

OpenSSH 9.8 wprowadził PerSourcePenalties, a Ubuntu 26.04 LTS wymienia tę opcję w release notes. Mechanizm pozwala karać adresy klientów, które nie kończą poprawnie uwierzytelniania albo zachowują się podejrzanie.

To nie zastępuje firewalla ani Fail2ban, ale może pomóc ograniczać skutki masowych prób logowania. Przed grzebaniem w tej opcji sprawdź najpierw, co naprawdę widzisz w logach:

journalctl -u ssh -S "24 hours ago" --no-pager
journalctl -u ssh | grep -Ei "Failed|Invalid|Accepted|Disconnected"

Jeżeli serwer stoi publicznie w internecie i stale widzisz próby logowania na root, admin, test, oracle, to problemem nie jest tylko OpenSSH. Sprawdź firewall, MFA tam gdzie ma sens, brak logowania hasłem i brak logowania bezpośrednio na roota.

7. SSHFP i DNSSEC

OpenSSH 10.2 ostrzega, że przyszła wersja zdeprecjonuje SHA1 dla rekordów SSHFP. Jeżeli używasz SSHFP w DNS, generuj i publikuj rekordy SHA256.

Generowanie:

ssh-keygen -r nazwa-serwera.example.com -f /etc/ssh/ssh_host_ed25519_key.pub

Sprawdzenie w DNS:

dig SSHFP nazwa-serwera.example.com

To temat niszowy w małych firmach, ale jeżeli używasz DNSSEC i SSHFP, warto posprzątać rekordy przy okazji aktualizacji.

8. Klucze użytkowników i authorized_keys

Po stronie użytkowników sprawdź szczególnie:

  • stare klucze bez właściciela,
  • klucze byłych pracowników,
  • klucze bez komentarza,
  • wpisy z nietypowymi opcjami,
  • konta techniczne używane przez backup albo monitoring.

Przykładowe sprawdzenie:

sudo find /home /root -path "*/.ssh/authorized_keys" -type f -print
sudo find /home /root -path "*/.ssh/authorized_keys" -type f -exec grep -H "ssh-dss" {} \;

Dobrą praktyką jest dopisywanie komentarza do klucza, np. imię, nazwisko, urządzenie albo system:

ssh-ed25519 AAAA... jan.kowalski-laptop-2026

Bez tego po roku nikt nie wie, czy dany klucz można usunąć.

9. Co sprawdzić po aktualizacji

Po aktualizacji Ubuntu albo samego OpenSSH:

ssh -V
sudo sshd -t
systemctl status ssh --no-pager
journalctl -u ssh -b --no-pager

Sprawdź logowanie:

  • z nowego terminala,
  • z konta administratora,
  • z konta technicznego,
  • ze skryptu backupu,
  • z monitoringu,
  • do urządzeń sieciowych, jeżeli serwer łączy się z nimi po SSH.

Jeżeli coś nie działa, uruchom klienta z debugiem:

ssh -vvv user@host

Najważniejsze komunikaty to zwykle:

  • no matching host key type found,
  • no matching key exchange method found,
  • Permission denied (publickey),
  • Bad configuration option,
  • Unable to negotiate.

Nie dodawaj odruchowo starych algorytmów globalnie dla wszystkich hostów. Jeżeli musisz zrobić wyjątek, ogranicz go do konkretnego hosta w ~/.ssh/config i opisz, dlaczego istnieje.

10. Przykład wyjątku tylko dla jednego starego urządzenia

Jeżeli naprawdę musisz połączyć się ze starym urządzeniem, nie rób tego globalnie w /etc/ssh/ssh_config. Lepiej zawęzić wyjątek:

Host stary-switch
    HostName 192.168.10.10
    User admin
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

To tylko przykład. Nie dopisuj go bez sprawdzenia, czego faktycznie wymaga urządzenie. Jeżeli potrzebne jest DSA, potraktuj to jako sygnał, że sprzęt albo firmware jest poza sensownym poziomem bezpieczeństwa.

Podsumowanie

OpenSSH 10 w Ubuntu 26.04 LTS jest dobrym momentem na porządek w SSH. DSA znika, pojawia się domyślny hybrydowy algorytm post-quantum, a stare ręczne obejścia w konfiguracji mogą zacząć przeszkadzać.

Przed aktualizacją sprawdź sshd_config, klucze hosta, authorized_keys, stare urządzenia sieciowe i skrypty techniczne. Zrób kopię /etc/ssh, miej dostęp awaryjny i testuj logowanie w nowej sesji, zanim zamkniesz starą.

Najgorsze podejście to dopisywanie starych algorytmów globalnie, żeby „na szybko działało”. Lepsze podejście to wymienić klucze, zaktualizować firmware albo zrobić wąski, opisany wyjątek dla konkretnego hosta.

Źródła

  • Ubuntu 26.04 LTS summary for LTS users: https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/
  • OpenSSH release notes: https://www.openssh.org/releasenotes.html
☕ Postaw mi kawę