A verziócímkén túl, Az OpenSSH 10.1 egyesíti a 10-es sorozattal megkezdett utat: migráció posztkvantum kriptográfiára, QoS modernizáció DSCP-vel, valamint a történelmileg érzékeny területek (ügynökök, kulcsok, regisztrátorok és paraméterelemzés) megerősítése. Az alábbiakban megtalálja az összes új funkció alapos áttekintése (azzal a kontextussal, ahol értéket ad), valamint gyakorlati irányelveket ad a meglepetések nélküli alkalmazásukhoz.
A következő a lista, amelyen a Újdonságok ebben a verzióban, szintén elérhető a hivatalos feljegyzések.
Kiadás főbb jellemzői és kontextus
Az OpenSSH 10.1 hivatalos kiadása (2025-10-06) három tengelyt emel ki: Megelőző védelem a kvantumkriptográfia, a DSCP hálózatok és a bemeneti fertőtlenítés ellenEmellett összekapcsolja a specifikus változtatásokat a nagy működési hatással: az ügynöksocket útvonalaktól a új diagnosztikai jelek.
Egy fontos emlékeztető a projektről: A jövőbeli kiadások figyelmen kívül fogják hagyni az SHA-1 alapú SSHFP naplókatMíg ssh-keygen -r mostantól alapértelmezés szerint csak SHA‑256-tal generál SSHFP ujjlenyomatokat, bezárva az ajtót a gyenge hash-ek előtt a DNSSEC és a host kulcs ellenőrzéséhez.
Nem posztkvantum kriptográfiai figyelmeztetés és új WarnWeakCrypto opció
Az OpenSSH 10.1 figyelmeztetést jelenít meg, amikor a kapcsolat kulcscserét tárgyal, amely nem ellenáll a posztkvantum támadásoknakA cél a „tárolás most, visszafejtés később” kockázatára összpontosítani, és felgyorsítani az átmenetet az érzékeny környezetekben.
Ezt a viselkedést a következővel szabályozzák: WarnWeakCrypto (A ssh_config), amely alapértelmezés szerint engedélyezve van. Ha fokozatos migrációt végez, vagy régi hosztokat tart fenn, Szelektíven letilthatja a figyelmeztetést Match blokkokkal. Például:
Egyezés a következő gazdagéppel: unsafe.example.com WarnWeakCrypto nem
Kriptográfia és a legmodernebb technológiák: PQC, hibridek és SSHFP
A 10.0-s verzióban az ügyfél alapértelmezés szerint a következő használatára váltott át: mlkem768x25519‑sha256, egy hibrid posztkvantum algoritmus, amely egyesíti ML-KEM (KEM NIST FIPS 203) X25519-cel. Ez a hibrid stratégia biztosítja, hogy még ha kriptoanalitikus áttörés történne is a PQ oldalon, Nem járnál rosszabbul, mint a klasszikus ECDH-val mivel a csatorna megőrzi az X25519 erősségét.
A 10.1-es verzióban a fent ismertetett figyelmeztetésen túl az átmenet megerősítésre került: Az OpenSSH a jövőben továbbra is figyelmen kívül fogja hagyni az SHA‑1-gyel ellátott SSHFP-t.; az eszköz ssh-keygen már kizárólag SHA‑256 titkosítással bocsát ki SSHFP-t. Működési szempontból a javasolt intézkedés a következő: SSHFP ujjlenyomatok generálása és közzététele SHA‑256-ban a házigazdáid számára.
Gyakran Ismételt Kérdések: Miért ragaszkodik most hozzá, ha a kvantumszámítógépek még nem tudják feltörni az SSH-t? Mert a támadók elfoghatják a mai adatot, és visszafejthetik a holnapot. A poszt-kvantum KEX használata már enyhíti ezt a vektort. És ha aggódsz a PQ algoritmusok fiatalsága miatt, ne feledd, hogy a hibrid modalitás a klasszikus biztonsági szintet tartja fenn alapként.
Hálózatmodernizáció: DSCP/IPQoS és forgalompriorizálás
Ez a kiadás egy mélyreható QoS-átalakítást foglal magában. Mind a kliens, mind a szerver oldalon... Az interaktív forgalom alapértelmezés szerint EF osztályú (gyorsított továbbítás)., ami segít csökkenteni a késleltetést Wi-Fi-n és túlterhelt média esetén. A nem interaktív forgalom a következő használatára vált át: rendszer alapértelmezett DSCP jelzés, prioritás emelése nélkül.
A gyakorlatban mindkettő Az ssh(1) és az sshd(8) dinamikusan változik a használt márka a jelenlévő csatornák típusa szerint: ha ugyanaz a csatlakozás egy héjat és egy sftp, a nem interaktív átviteli fázis a művelet során a nem interaktív értéket fogja használni, és szükség esetén EF-be tér vissza. Ezt a kulcs vezérli. IPQoS en ssh_config y sshd_config.
Ezen túlmenően, A régebbi IPv4 ToS támogatását visszavonják az IPQoS opcióban (lowdelay, throughput, reliability (Már nem hatott). Ha még mindig használta őket, átáll a DSCP nómenklatúrára (például., ef, cs0, af11, Stb.)
Beviteli korlátozás: felhasználók, URI-k és bővítések
A biztonság részben a 10.1-es verzió kijavít egy apró hibát, amikor külső adatokkal létrehozott parancssorok esetén egyidejűleg a következőt használta: ProxyCommand %r/%u kiterjesztésekkel, egy támadó becsempészhet shell kifejezéseket. Ennek enyhítésére, Az ssh(1) mostantól tiltja a vezérlőkaraktereket a CLI-t átadó vagy kibővített felhasználókban., és blokkolja a null karaktert az URI-kban ssh://.
Kompatibilitási megjegyzés: Egy érvényesítési pontot enyhítettek a jogos esetek megszakításának elkerülése érdekében. Konfigurációs fájlokban definiált szó szerinti felhasználónevek A (%) nélküli bővítmények mentesülnek ez alól, azon az alapon, hogy a helyi konfiguráció megbízhatónak tekinthető.
Élő jelek és információk: SIGINFO és láthatóság
Egy másik praktikus hibakeresési tipp: Az ssh(1) és az sshd(8) SIGINFO kezelőket kapnak amelyek rögzítik az aktív csatornák és munkamenetek állapotát. Éles környezetben ez megkönnyíti az áramlásdiagnosztikát, a multiplexelést, a továbbítást és az X11-et anélkül, hogy hibakeresőt kellene csatlakoztatni, vagy invazív módon növelni a részletességet.
Az átláthatóság ugyanazon elvei szerint, amikor egy tanúsítványhitelesítés sikertelen, Az sshd mostantól elegendő információt naplóz a tanúsítvány azonosításához. (valamint az elutasítás okát is). Ha PKI-val és felhasználói/gazdagép-tanúsítványokkal dolgozik, ez a fejlesztés jelentősen lerövidíti a megoldási időt.
ssh-ügynök és kulcsok: socketek, fertőtlenítés és PKCS#11
A keresztbe tett hozzáférés megakadályozása érdekében olyan környezetben, ahol korlátozott a felszerelés /tmp, az ügynök socketek (és a által továbbítottak) sshd) Tudom áthelyezés a /tmp fájlból a ~/.ssh/agent fájlbaÍgy egy korlátozott jogosultságokkal rendelkező folyamat /tmp többé nem örökli véletlenül az ügynöktől a kulcsokkal való aláírás képességét.
Ennek a változásnak van egy másik származéka is: mielőtt az operációs rendszer képes volt az elavult socketek tisztítására, most Az ssh-agent saját takarítást tartalmaz régi socketekből. Ezenkívül az ügynök új jelzőket is hozzáad: -U y -u a tisztaság ellenőrzése indításkor, -uu a hostname figyelmen kívül hagyása a takarítás során, és -T a történelmi helyszínt belekényszeríteni /tmp ha tényleg szükséged van rá.
A kulcssíkban az ügyfél és az ügynök A PKCS#11 tokeneken tárolt ED25519 mostantól támogatott.Ha HSM-ekre vagy kriptográfiai kulcsokra támaszkodik, rugalmasságot érhet el az erősség feláldozása nélkül.
ssh-add és tanúsítványok: öntisztító lejárat
Amikor tanúsítványokat ad hozzá az ügynökhöz, A lejárata mostantól 5 perces türelmi idővel van beállítva.Az ötlet egyszerű: hagyjuk, hogy a tranzakciók a sorban befejeződjenek, majd ügynöki tanúsítvány automatikus törléseHa az áramlás teljes kontrollt igényel, ssh‑add -N tiltsa le ezt a viselkedést.
RefuseConnection: kliensoldalon vezérelt leválasztások
Vannak olyan esetek, amikor egy kliens általi kapcsolat megszakítására van szükség egyértelmű üzenettel (például, működési átirányítások vagy elavulási értesítések). Az OpenSSH 10.1 hozzáadja a következőt: Kapcsolódás elutasítása a ssh_config: ha egy aktív szakasz feldolgozása közben találkozik ezzel a problémával, a kliens hibával leáll, és megjeleníti a megadott szöveget.
Kódminőség és élő biztonság
A csapat folytatja a kódbázis tisztítását. 10.1 listák memóriaszivárgások javítva, Atomiának írás közbeni fejlesztései known_hosts magas részvételi aránnyal és számos a verseny feltételei megoldódtak olyan folyamatokban, mint MaxStartups vagy X11 munkamenetek.
Kriptovaluta-tisztítási megjegyzés: Az XMSS támogatása megszűnt (kísérleti jellegű és soha nem alapértelmezett). Előkészítés a terepre posztkvantum aláírási sémák érettebbek, amelyek a jövőbeli verziókban jelennek meg.
Hordozhatóság és ökoszisztéma: PAM, FreeBSD, macOS, Android…
A hordozhatóság változásai számos területet érintenek: extra ellenőrzések PAM környezetekben (például annak biztosítása, hogy a felhasználó ne változzon a folyamat során), integrációs fejlesztések a FreeBSD (tunning továbbítása és kompatibilitás), MacOS (függvények és fejlécek robusztus felismerése) és Android (passwd struktúra nem null mezőkkel).
Kompatibilitási fejléceket is hozzáadtunk bizonyos szabványos könyvtárakkal nem rendelkező platformokhoz, csökkentve a számukat. #ifdef szétszórva. Végül finomítják őket seccomp sandbox szabályzatok Linuxon a rendszerhívások, például a futex_time64 32 bites, és a támogatás hozzáadódik a következőhöz: AWS-LC az OpenSSL/LibreSSL alternatívájaként.
QoS a gyakorlatban: Gyakorlati példák és IPQoS migráció
Ha a régi ToS aliasokat használtad (lowdelay, throughput...), most figyelmen kívül fogják hagyni őket és megjelenik egy hibakeresési üzenet, amely a DSCP-t javasolja. A tipikus migráció a következő lenne: IPQoS lowdelay a IPQoS ef interaktív munkamenetekhez; ha emellett intenzív SFTP-t is használsz, akkor profilok meghatározása Match alapján en ssh_config/sshd_config a forgalom szétválasztására.
Ne feledd, hogy a motor automatikusan kiválasztja és frissíti Valós időben jelöl a nyitott csatornák alapján, így a munka nagy részét az OpenSSH már elvégzi helyetted.
OpenSSH 10.1 telepítése Linuxra (forráskód)
Míg a disztribúciók integrálják a verziót, hivatalos forrásból fordíthatod leTöltsd le a tarballt a projekt tüköroldalairól, csomagold ki és fordítsd le:
tar -xvf openssh -10.1.tar.gz
Lépjen be a címtárba, és előtagok és konfigurációs útvonalak konfigurálása ha szükséged van rá. Például:
cd openssh-10.1 ./configure --prefix=/opt --sysconfdir=/etc/ssh
Fordítsa le és telepítse a szokásos módon (jogosultságoktól függően, esetleg superuserrel):
csinál
make install
OpenSSH engedélyezése Windows rendszeren PowerShell segítségével
Modern Windows környezetekben (Server 2019/Windows 10 1809+), Az OpenSSH klienst és szervert rendszerfunkcióként telepítheti.Kapacitások és állapot ellenőrzése:
Get-WindowsCapability-Online | Where-Object Name -szerű 'OpenSSH*'
Az alkatrészek telepítése amire szükséged van:
Add-WindowsCapability -Online -Név OpenSSH.Client~~~~0.0.1.0 Add-WindowsCapability -Online -Név OpenSSH.Server~~~~0.0.1.0
Indítsa el és engedélyezze az SSH szerver szolgáltatást, és ellenőrizze a bejövő tűzfalszabályt:
Start-Service sshd Set-Service -Name sshd -StartupType 'Automatic' Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
Egy másik Windows vagy Linux gazdagépről való csatlakozáshoz használja a standard klienst: ssh dominio\usuario@servidorElső belépéskor elfogadja a gazda ujjlenyomatát és hitelesítsd magad a jelszavaddal.
Működési útmutató: diagnosztika és bevált gyakorlatok
Felhasználói/gazdagép-tanúsítványokkal rendelkező környezetek esetén kihasználni a továbbfejlesztett naplózás előnyeit az elutasításokról sshd a hitelesítésszolgáltatók és kiterjesztések hibakereséséhez. Ha egy munkamenet elakad, vagy multiplexelésre gyanakszik, elindítja a SIGINFO-t az aktív csatornák listázásának folyamatához a globális naplózási szint emelése nélkül.
Ha ügynökökre támaszkodik, ellenőrizze, hogy hol találhatók most a socketek (~/.ssh/agent) És aktiválja az automatikus tisztítást a telepítési modellben. Megosztott vagy NFS munkaállomásokon érdemes lehet az ügynökjelzőt használni a hosztnév-hashek beállításához az elérési úton, ha szükséges.
Legfontosabb hibajavítások
A 10.1-es verzióban megoldódnak kisebb regressziók az X11-ben pulzusszám-csökkentéssel kombinálva (ObscureKeystrokeTiming), egy eset A MaxStartups gyenge könyvelése ami eláraszthatja a slotokat, és a known_hosts most már kész atomi műveletekben hogy elkerüljük a nagy párhuzamossággal járó összefonódó sorokat.
Egyéb javítások javítják a diagnosztika kulcsok betöltésekor, a konfigurációs méretkorlátok kezelése (256 KB-tól 4 MB-ig), audit kimenet és egzotikus sarokesetek a helyi továbbításokban és vezérlőszekvenciákban. Ezenkívül az üzenetek és a kimenet a következőből: ssh -G y sshd -T.
Ajánlott migrációs ellenőrzőlista
Ez a gyors lista Magában foglalja azokat a feladatokat, amelyeket maga a projekt javasol, és ami a változásokból adódik:
- Crypto: ellenőrizze, hogy a
KexAlgorithmshibrid PQ-t tesz lehetővé, és új SSHFP-t generál SHA-256-banssh-keygen -r. - QoS: nézd meg
IPQoSkliens/szerver rendszeren; a régi ToS migrálása DSCP-re; EF használata interaktív munkamenetekhez. - szerek: szkripteket és változókat illeszt a socketekhez a következő alatt:
~/.ssh/agent; értékeli az automatikus tisztítást maga a szer által. - Nagy konfigurációkTömeges konfigurációk generálása esetén a korlát 4 MB-ra nőhet; alkalmazd bölcsen és szabályozza az érvényesítést.
- Parserek: kerülje a parancssorok nem megbízható bemenetből történő létrehozását; használja
confighelyiek literálokkal, ha furcsa esetek vannak a felhasználónevekben.
A vegyes flottákat kezelők értékelni fogják a 10.1-et. szorítsd meg a biztonsági övet ott, ahol a legkevésbé fáj (elemzők, ügynökök, figyelmeztetések) és egyidejűleg javítsa a mindennapi élményt (Dinamikus QoS, SIGINFO, tanúsítványnaplózás). Ha már a 10.0-s verziót használtad, az átállás egyszerű; ha a 9.x-es verzióról érkezel, szánj időt a DSCP hangolására, az SSHFP SHA-256-ra való regenerálására, és a hibrid KEX-ek engedélyezésére, hogy a teljesítmény feláldozása nélkül védd meg magad a kvantumfenyegetéstől.
