Kromě označení verze, OpenSSH 10.1 konsoliduje cestu započatou řadou 10migrace na postkvantovou kryptografii, modernizace QoS s DSCP a posílení historicky citlivých oblastí (agenty, klíče, registry a parsování parametrů). Níže naleznete důkladná recenze všech nových funkcí (s kontextem, kde to přináší přidanou hodnotu), jakož i praktické pokyny pro jejich přijetí bez překvapení.
Následuje seznam s Co je nového v této verzi, k dispozici také v oficiální poznámky.
Hlavní body a kontext vydání
Oficiální vydání OpenSSH 10.1 (2025-10-06) zdůrazňuje tři osy: Preventivní zabezpečení proti kvantové kryptografii, sítím DSCP a sanitizaci vstupůTaké propojuje specifické změny s vysokým provozním dopadem: od tras socketů agentů až po nové diagnostické příznaky.
Důležitá připomínka projektu: Budoucí verze bude ignorovat protokoly SSHFP založené na SHA-1.Zatímco ssh-keygen -r nyní ve výchozím nastavení generuje otisky prstů SSHFP pouze s SHA-256, zavírání dveří slabým hashům pro DNSSEC a ověření klíče hostitele.
Varování před ne-postkvantovou kryptografií a nová možnost WarnWeakCrypto
OpenSSH 10.1 zavádí varování, které se zobrazuje, když připojení vyjednává výměnu klíčů, která... není odolný vůči postkvantovým útokůmCílem je zaměřit se na riziko „uložení nyní, dešifrování později“ a urychlit přechod v citlivých prostředích.
Toto chování je kontrolováno pomocí VarováníSlabéCrypto (v ssh_config), což je ve výchozím nastavení povoleno. Pokud provádíte postupnou migraci nebo udržujete starší hostitele, Varování můžete selektivně deaktivovat s bloky Match. Například:
Hostitel shoduje se s unsafe.example.com WarnWeakCrypto ne
Kryptografie a současný stav techniky: PQC, hybridy a SSHFP
Ve verzi 10.0 klient přepnul na používání ve výchozím nastavení mlkem768x25519‑sha256, hybridní postkvantový algoritmus, který kombinuje ML-KEM (KEM NIST FIPS 203) s X25519. Tato hybridní strategie zajišťuje, že i kdyby došlo k kryptoanalytickému průlomu na straně PQ, Nebyli byste na tom hůř než s klasickým ECDH protože kanál si zachovává sílu X25519.
S verzí 10.1 je kromě výše vysvětleného varování ještě posílen přechod: OpenSSH bude i v budoucnu ignorovat SSHFP s SHA-1.nástroj ssh-keygen již vydává SSHFP výhradně s SHA-256. Z provozního hlediska je doporučeným postupem regenerovat a publikovat otisky prstů SSHFP v SHA-256 pro vaše hostitele.
Často kladené otázky: Proč na tom teď trvat, když kvantové počítače zatím neumí prolomit SSH? Protože útočníci mohou zachytit dnes a dešifrovat zítra. Použití postkvantového KEXu již tento vektor zmírňuje. A pokud se obáváte o mládí algoritmů PQ, pamatujte, že hybridní modalita zachovává klasickou úroveň zabezpečení jako základ.
Modernizace sítě: DSCP/IPQoS a prioritizace provozu
Tato verze konsoliduje důkladnou revizi QoS. Na straně klienta i serveru... Interaktivní provoz je standardně nastaven na třídu EF (Expedited Forwarding)., což pomáhá snižovat latenci na Wi-Fi a přetížená média. Neinteraktivní provoz se přepíná na použití systémová výchozí značka DSCP, bez zvýšení priority.
V praxi obojí ssh(1) a sshd(8) se dynamicky mění použitá značka podle typu přítomných kanálů: pokud stejné spojení kombinuje skořepinu a sftp, fáze neinteraktivního přenosu během operace použije neinteraktivní hodnotu a v případě potřeby se vrátí do EF. Toto je řízeno klíčem IPQoS en ssh_config y sshd_config.
Navíc, Podpora starších podmínek služby IPv4 se ruší. v možnosti IPQoS (lowdelay, throughput, reliability přestaly mít účinek). Pokud jste je stále užívali, migruje na nomenklaturu DSCP (např., ef, cs0, af11, Atd.).
Zpevnění vstupu: uživatelé, URI a rozšíření
V sekci zabezpečení opravuje verze 10.1 drobný případ, kdy jste vytvořili příkazové řádky s externími daty a zároveň použili ProxyCommand s rozšířeními %r/%u, útočník by mohl vplížit výrazy shellu. Aby se to zmírnilo, ssh(1) nyní zakazuje řídicí znaky v uživatelích passed přes CLI nebo expanded.a také blokuje znak null v URI ssh://.
Poznámka ke kompatibilitě: Ověřovací bod byl uvolněn, aby se zabránilo narušení legitimních případů. Doslovná uživatelská jména definovaná v konfiguračních souborech Rozšíření (bez %) jsou vyňata, protože lokální konfigurace je považována za důvěryhodnou.
Živé signály a informace: SIGINFO a viditelnost
Další praktický tip pro ladění: ssh(1) a sshd(8) získávají obslužné rutiny SIGINFO které zaznamenávají stav aktivních kanálů a relací. V produkčním prostředí to usnadňuje diagnostiku toku, multiplexování, přeposílání a X11 bez nutnosti připojovat debugger nebo invazivně zvyšovat výřečnost.
V souladu s principy transparentnosti, když selže ověření certifikátu, sshd nyní zaznamenává dostatek informací k identifikaci certifikátu. (a také důvod, proč bylo zamítnuto). Pokud pracujete s PKI a certifikáty uživatelů/hostitelů, toto vylepšení výrazně zkracuje dobu řešení.
ssh-agent a klíče: sockety, sanitizace a PKCS#11
Aby se zabránilo křížovému přístupu v prostředí s omezenou montáží /tmp, sokety agentů (a ty, které přeposílá sshd) Vím přesunout z /tmp do ~/.ssh/agentProces s omezenými oprávněními tedy /tmp již omylem nedědí možnost podepisovat se pomocí vašich klíčů od agenta.
Tato změna má ještě jeden derivát: dříve OS dokázal čistit zastaralé sockety, nyní ssh-agent má vlastní funkci čištění ze starých socketů. Agent navíc přidává nové příznaky: -U y -u pro kontrolu čistoty při spuštění, -uu ignorovat název hostitele při čištění a -T vnutit historické místo /tmp pokud to opravdu potřebujete.
V klíčové rovině klient a agent ED25519 hostované na tokenech PKCS#11 jsou nyní podporovány.Pokud se spoléháte na HSM nebo kryptografické klíče, získáte flexibilitu bez obětování síly.
ssh-add a certifikáty: samočisticí expirace
Když přidáte certifikáty k agentovi, Jeho platnost je nyní nastavena na 5minutovou odkladnou lhůtu.Myšlenka je jednoduchá: umožnit dokončení transakcí ve frontě a poté, automaticky smazat certifikát agentaPokud váš tok vyžaduje naprostou kontrolu, ssh‑add -N toto chování zakázat.
RefuseConnection: odpojení řízená klientem
Existují scénáře, kdy máte zájem o ukončení spojení ze strany samotného klienta jasnou zprávou (například provozní přesměrování nebo oznámení o ukončení podpory). OpenSSH 10.1 přidává RefuseConnection a ssh_config: pokud se na to při zpracování aktivní sekce narazí, klient ukončí práci s chybou a zobrazí text, který jste definovali.
Kvalita kódu a zabezpečení v reálném čase
Tým pokračuje v čištění kódové základny. Seznamy verze 10.1 opraveny úniky paměti, vylepšení Atomie při psaní known_hosts s vysokou účastí a několika podmínky rasy vyřešeny v procesech, jako je MaxStartups nebo relace X11.
Poznámka k čištění kryptoměn: podpora pro XMSS byla odstraněna (experimentální a nikdy nestandardní). Příprava půdy pro postkvantové schémata podpisů zralejší, které se objeví v budoucích verzích.
Přenositelnost a ekosystém: PAM, FreeBSD, macOS, Android…
Změny v přenositelnosti ovlivňují mnoho oblastí: dodatečné kontroly v prostředí PAM (například zajištění toho, aby se uživatel během procesu nezměnil), vylepšení integrace s FreeBSD (přeposílání tun a kompatibilita), macOS (robustní detekce funkcí a hlaviček) a Android (struktura passwd s nenulovými poli).
Pro platformy bez určitých standardních knihoven jsou také přidány hlavičky kompatibility, čímž se snižuje počet #ifdef rozptýlené. Nakonec jsou rafinovány Zásady sandboxu Seccomp v Linuxu pro pokrytí systémových volání jako futex_time64 ve 32bitové verzi a je přidána podpora pro AWS-LC jako alternativa k OpenSSL/LibreSSL.
QoS v praxi: Praktické příklady a migrace IPQoS
Pokud jste použili staré aliasy Podmínek služby (lowdelay, throughput...), teď budou ignorováni a zobrazí se ladicí zpráva s návrhem DSCP. Typická migrace by byla přechod z IPQoS lowdelay a IPQoS ef pro interaktivní relace; pokud také používáte intenzivní SFTP, mohli byste definovat profily podle shody en ssh_config/sshd_config k oddělení provozu.
Nezapomeňte, že motor automaticky vybírá a aktualizuje Značí v reálném čase na základě otevřených kanálů, takže většinu práce za vás již udělá OpenSSH.
Instalace OpenSSH 10.1 na Linux (zdroj)
Zatímco distribuce integrují verzi, můžete kompilovat z oficiálního zdrojeStáhněte si tarball z mirrorů projektu, rozbalte ho a zkompilujte:
tar -xvf openssh -10.1.tar.gz
Vstupte do adresáře a konfigurovat prefixy a konfigurační trasy pokud to potřebujete. Například:
cd openssh-10.1 ./configure --prefix=/opt --sysconfdir=/etc/ssh
Zkompilujte a nainstalujte jako obvykle (v závislosti na oprávněních, možná se superuživatelem):
činit
make install
Povolení OpenSSH ve Windows pomocí PowerShellu
V moderních prostředích Windows (Server 2019/Windows 10 1809+) Klienta a server OpenSSH můžete nainstalovat jako systémové funkce.Zkontrolujte kapacity a stav:
Get-WindowsCapability-Online | Název objektu Where - například 'OpenSSH*'
Nainstalujte komponenty jak potřebujete:
Add-WindowsCapability -Online -Název OpenSSH.Client~~~~0.0.1.0 Add-WindowsCapability -Online -Název OpenSSH.Server~~~~0.0.1.0
Spuštění a povolení služby SSH serverua zkontrolujte pravidlo firewallu pro příchozí poštu:
Start-Service sshd Set-Service -Název sshd -StartupType 'Automatic' Get-NetFirewallRule -Název 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
Pro připojení z jiného hostitele se systémem Windows nebo Linux použijte standardního klienta: ssh dominio\usuario@servidorPři prvním přístupu přijímá otisk prstu hostitele a ověřte se pomocí svého hesla.
Provozní příručka: diagnostika a osvědčené postupy
Pro prostředí s certifikáty uživatele/hostitele, využít vylepšeného protokolování popření v sshd ladění certifikačních autorit a rozšíření. Pokud se relace zasekne nebo máte podezření na multiplexování, spouští SIGINFO k procesu výpisu aktivních kanálů bez zvýšení globální úrovně protokolu.
Pokud jste závislí na agentech, zkontrolujte, kde se nyní nacházejí zásuvky (~/.ssh/agent) A aktivovat automatické čištění ve vašem modelu nasazení. Na sdílených pracovních stanicích nebo pracovních stanicích NFS zvažte v případě potřeby použití příznaku agenta k nastavení hashů názvů hostitelů v cestě.
Nejrelevantnější opravy chyb
V 10.1 jsou vyřešeny drobné regrese v X11 v kombinaci se zmírněním tepové frekvence (ObscureKeystrokeTiming), případ Špatné účetnictví MaxStartups které by mohly zaplavit sloty a psaní known_hosts teď je to hotové v atomových operacích aby se zabránilo prokládaným řádkům s vysokou souběžností.
Další opravy se vylepšují diagnostika při načítání klíčů, zpracování limitů velikosti konfigurace (od 256 KB do 4 MB), výstup auditu a exotické případy v lokálních přeposílacích a řídicích sekvencích. Kromě toho zprávy a výstup z ssh -G y sshd -T.
Doporučený kontrolní seznam pro migraci
Tento rychlý seznam Zahrnuje úkoly, které samotný projekt navrhuje, a to, co z provedených změn vyplývá:
- Cripto: zkontrolujte, zda vaše
KexAlgorithmsumožňuje hybridní PQ a generuje nový SSHFP v SHA-256 sssh-keygen -r. - QoS: Překontrolovat
IPQoSna platformě klient/server; migrace starších podmínek služby (Tos) na DSCP; využití EF pro interaktivní relace. - Agenti: přizpůsobuje skripty a proměnné socketům pod
~/.ssh/agentcení si automatického čištění samotným prostředkem. - Velké konfiguracePokud generujete hromadné konfigurace, limit se zvýší až na 4 MB; aplikujte to moudře a řídí validaci.
- Parsery: vyhněte se vytváření příkazových řádků z nedůvěryhodného vstupu; použijte
configlokální proměnné s literály, když máte zvláštní případy v uživatelských jménech.
Ti, kteří spravují smíšené vozové parky, ocení, že 10.1 zatlačte na jistotu tam, kde to nejméně bolí (parsery, agenti, varování) a zároveň zlepšit každodenní zážitek (Dynamická QoS, SIGINFO, protokolování certifikátů). Pokud jste již používali verzi 10.0, přechod je jednoduchý; pokud přecházíte z verze 9.x, věnujte čas vyladění DSCP, regeneraci SSHFP na SHA-256 a povolení hybridních KEX, abyste se ochránili před kvantovou hrozbou bez obětování výkonu.
