Отвъд етикета на версията, OpenSSH 10.1 консолидира пътя, започнат със серията 10миграция към постквантова криптография, модернизация на QoS с DSCP и засилване на исторически чувствителни области (агенти, ключове, регистри и парсиране на параметри). По-долу ще намерите подробен преглед на всички нови функции (с контекст, където това добавя стойност), както и практически насоки за приемането им без изненади.
Следва списъкът с Какво е новото в тази версия, също налично в официални бележки.
Акценти и контекст на изданието
Официалното издание на OpenSSH 10.1 (2025-10-06) подчертава три основни направления: Превантивна защита срещу квантова криптография, DSCP мрежи и дезинфекция на входни данниТой също така свързва специфични промени с голямо оперативно въздействие: от маршрути на сокетите на агентите до нови диагностични признаци.
Ключово напомняне за проекта: Бъдеща версия ще игнорира SSHFP регистрационни файлове, базирани на SHA-1.Докато ssh-keygen -r вече генерира SSHFP пръстови отпечатъци само с SHA‑256 по подразбиране, затваряне на вратата за слаби хешове за DNSSEC и проверка на хост ключ.
Предупреждение за не-пост-квантова криптография и нова опция WarnWeakCrypto
OpenSSH 10.1 въвежда предупреждение, когато връзката договаря обмен на ключове, който не е устойчив на постквантови атакиЦелта е да се съсредоточим върху риска от „съхранявай сега, декриптирай по-късно“ и да ускорим прехода в чувствителни среди.
Това поведение се контролира с ПредупреждениеСлабКрипто (В ssh_config), което е активирано по подразбиране. Ако извършвате постепенна миграция или поддържате наследени хостове, Можете избирателно да деактивирате предупреждението с блокове Match. Например:
Съвпадение на хоста unsafe.example.com WarnWeakCrypto не
Криптография и най-съвременни технологии: PQC, хибриди и SSHFP
В 10.0 клиентът премина към използване по подразбиране mlkem768x25519‑sha256, хибриден постквантов алгоритъм, който комбинира ML-KEM (KEM NIST FIPS 203) с X25519. Тази хибридна стратегия гарантира, че дори ако се появи криптоаналитичен пробив от страна на PQ, Няма да е по-зле, отколкото с класическия ECDH. защото каналът запазва силата на X25519.
С версия 10.1, в допълнение към предупреждението, обяснено по-горе, преходът е подсилен: OpenSSH ще продължи да игнорира SSHFP с SHA‑1 в бъдеще.инструментът ssh-keygen вече издава SSHFP изключително с SHA‑256. От оперативна гледна точка, препоръчителното действие е генериране и публикуване на SSHFP пръстови отпечатъци в SHA‑256 за вашите домакини.
Често задавани въпроси: Защо да настоявате сега, ако квантовите компютри все още не могат да разбият SSH? Защото нападателите могат да уловят днес и да декриптират утре. Използването на пост-квантов KEX вече смекчава този вектор. И ако се притеснявате за младостта на PQ алгоритмите, не забравяйте, че хибридната модалност поддържа класическото ниво на сигурност като основа.
Модернизация на мрежата: DSCP/IPQoS и приоритизиране на трафика
Тази версия консолидира дълбока ревизия на QoS. Както на клиента, така и на сървъра, Интерактивният трафик по подразбиране е от клас EF (Expedited Forwarding), което помага за намаляване на латентността в Wi-Fi и претоварените медийни файлове. Неинтерактивният трафик превключва към използване на маркировка DSCP по подразбиране на системата, без да се повишава приоритетът.
На практика и двете ssh(1) и sshd(8) се променят динамично използваната марка според вида на наличните канали: ако една и съща връзка комбинира черупка и sftp, фазата на неинтерактивно прехвърляне ще използва неинтерактивната стойност по време на операцията и ще се върне към EF, когато е уместно. Това се контролира от ключа IPQoS en ssh_config y sshd_config.
Освен това, Поддръжката за по-стари IPv4 ToS се оттегля в опцията IPQoS (lowdelay, throughput, reliability престанат да имат ефект). Ако все още сте ги използвали, мигрира към номенклатурата на DSCP (Например, ef, cs0, af11И т.н.).
Втвърдяване на входа: потребители, URI и разширения
В раздела за сигурност, версия 10.1 коригира фин случай, при който, ако сте създали командни редове с външни данни и едновременно с това сте използвали ProxyCommand с разширения %r/%u, атакуващ може да промъкне изрази на shell. За да се смекчи това, ssh(1) вече забранява контролните символи в потребители, подадени от CLI или разширени, а също така блокира нулевия символ в URI адресите ssh://.
Забележка за съвместимост: Точката за валидиране е облекчена, за да се избегне нарушаване на легитимни случаи. Литерални потребителски имена, дефинирани в конфигурационните файлове Разширенията (без %) са изключени, тъй като локалната конфигурация се счита за надеждна.
Сигнали и информация на живо: SIGINFO и видимост
Друг практичен съвет за отстраняване на грешки: ssh(1) и sshd(8) получават SIGINFO манипулатори които записват състоянието на активните канали и сесии. В производствения процес това улеснява диагностиката на потока, мултиплексирането, пренасочването и X11 без необходимост от прикачване на дебъгер или инвазивно увеличаване на подробностите.
По същия начин, за да се гарантира прозрачността, когато удостоверяването на сертификата е неуспешно, sshd вече регистрира достатъчно информация, за да идентифицира сертификата (както и защо е било отказано). Ако работите с PKI и потребителски/хост сертификати, това подобрение значително съкращава времето за разрешаване.
ssh-агент и ключове: сокети, дезинфекция и PKCS#11
За предотвратяване на кръстосан достъп в среди с ограничен монтаж на /tmp, сокетите на агента (и тези, препратени от sshd) се преместване от /tmp в ~/.ssh/agentПо този начин, процес с ограничени разрешения за /tmp вече не наследява случайно възможността за подписване с вашите ключове от агента.
Тази промяна има и друг производен: преди операционната система можеше да почиства остарели сокети, сега... ssh-agent включва собствено почистване от стари сокети. Освен това, агентът добавя нови флагове: -U y -u за контрол на чистотата при стартиране, -uu да игнорира името на хоста при почистване и -T да наложи историческото местоположение /tmp ако наистина ти е нужно.
В ключовата равнина, клиентът и агентът ED25519, хостван на PKCS#11 токени, вече се поддържатАко разчитате на HSM или криптографски ключове, ще получите гъвкавост, без да жертвате здравината.
ssh-add и сертификати: самопочистващо се изтичане
Когато добавяте сертификати към агента, Изтичането му вече е определено с гратисен период от 5 минути.Идеята е проста: да се позволи завършването на транзакциите в опашката и след това, автоматично изтриване на сертификата на агентаАко вашият поток изисква пълен контрол, ssh‑add -N деактивирайте това поведение.
RefuseConnection: контролирани от страна на клиента прекъсвания
Има сценарии, в които се интересувате от прекратяване на връзка от самия клиент с ясно съобщение (например, оперативни пренасочвания или известия за отписване). OpenSSH 10.1 добавя ОтказВръзка a ssh_config: ако се срещне при обработка на гореща секция, клиентът прекратява работата си с грешка и показва текста, който сте дефинирали.
Качество на кода и сигурност на живо
Екипът продължава да почиства кодовата база. 10.1 списъци течовете на паметта са отстранени, подобрения в Atomia при писане known_hosts с висока посещаемост и няколко условията на състезание са разрешени в процеси като MaxStartups или X11 сесии.
Бележка за почистване на криптовалути: поддръжката за XMSS е премахната (експериментално и никога по подразбиране). Подготовка на почвата за постквантови схеми за подписване по-зрели, които ще се появят в бъдещи версии.
Преносимост и екосистема: PAM, FreeBSD, macOS, Android…
Промените в преносимостта засягат много аспекти: допълнителни проверки в PAM среди (като например гарантиране, че потребителят не се променя по време на процеса), подобрения в интеграцията с FreeBSD (пренасочване на тун и съвместимост), macOS (надеждно откриване на функции и заглавки) и Android (структура passwd с ненулеви полета).
За платформи без определени стандартни библиотеки се добавят и заглавки за съвместимост, което намалява броя на #ifdef разпръснати. Накрая те се рафинират правила за пясъчник на seccomp в Linux, за да се покрият системни извиквания като futex_time64 в 32-битова версия и е добавена поддръжка за AWS‑LC като алтернатива на OpenSSL/LibreSSL.
QoS в действие: Практически примери и IPQoS миграция
Ако сте използвали старите псевдоними на ToS (lowdelay, throughput...), сега ще бъдат игнорирани и ще видите съобщение за отстраняване на грешки, предлагащо DSCP. Типичната миграция би била да се премине от IPQoS lowdelay a IPQoS ef за интерактивни сесии; ако използвате и интензивен SFTP, бихте могли дефиниране на профили по съвпадение en ssh_config/sshd_config за разделяне на движението.
Не забравяйте, че двигателят автоматично избира и актуализира Маркира в реално време въз основа на отворени канали, така че по-голямата част от работата вече е свършена вместо вас от OpenSSH.
Инсталиране на OpenSSH 10.1 на Linux (източник)
Докато дистрибуциите интегрират версията, Можете да компилирате от официалния източникИзтеглете tarball-а от огледалните папки на проекта, разархивирайте и компилирайте:
tar -xvf openssh -10.1.tar.gz
Влезте в директорията и конфигуриране на префикси и конфигурационни маршрути ако имате нужда от това. Например:
cd openssh-10.1 ./configure --prefix=/opt --sysconfdir=/etc/ssh
Компилирайте и инсталирайте както обикновено (в зависимост от разрешенията, може би със суперпотребител):
правя
make install
Активирайте OpenSSH на Windows с PowerShell
В съвременните Windows среди (Server 2019/Windows 10 1809+), Можете да инсталирате клиента и сървъра на OpenSSH като системни функции.Проверете капацитета и състоянието:
Get-WindowsCapability-Online | Име на обекта, подобно на „OpenSSH*“
Инсталирайте компонентите както ви е необходимо:
Add-WindowsCapability -Online -Име OpenSSH.Client~~~~0.0.1.0 Add-WindowsCapability -Online -Име OpenSSH.Server~~~~0.0.1.0
Стартирайте и активирайте услугата SSH сървъри проверете правилото за входяща защитна стена:
Старт-Service sshd Set-Service -Име sshd -StartupType 'Automatic' Get-NetFirewallRule -Име 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
За да се свържете от друг хост с Windows или Linux, използвайте стандартния клиент: ssh dominio\usuario@servidorПри първи достъп, приема пръстовия отпечатък на хоста и се удостоверете с паролата си.
Оперативно ръководство: диагностика и добри практики
За среди със сертификати за потребители/хостове, възползвайте се от подобреното регистриране на откази в sshd за отстраняване на грешки в CA и разширения. Ако сесията заседне или подозирате мултиплексиране, стартира SIGINFO към процеса на изброяване на активни канали без повишаване на нивото на глобалния лог.
Ако разчитате на агенти, проверете къде се намират контактите в момента (~/.ssh/agent) Y активирайте автоматично почистване във вашия модел на внедряване. На споделени или NFS работни станции, помислете за използване на флага на агента, за да зададете хешове на имената на хостовете в пътя, когато е необходимо.
Най-подходящите корекции на грешки
В 10.1 те са решени малки регресии в X11 когато се комбинира с намаляване на сърдечната честота (ObscureKeystrokeTiming), случай на Лошото счетоводство на MaxStartups което би могло да залее слотовете, и писането на known_hosts сега е готово в атомни операции за да се избегнат преплетени линии с висока едновременност.
Други корекции се подобряват диагностика при зареждане на ключове, обработка на ограниченията за размер на конфигурацията (от 256KB до 4MB), изход от одит и екзотични ъглови случаи в локални препращания и контролни последователности. В допълнение, съобщенията и изходът от ssh -G y sshd -T.
Препоръчителен контролен списък за миграция
Този бърз списък Това включва задачите, които самият проект предлага, и какво произтича от промените:
- криптопроверете дали вашият
KexAlgorithmsпозволява хибридно PQ и генерира нов SSHFP в SHA‑256 сssh-keygen -r. - QoS: Разгледайте
IPQoSна клиент/сървър; мигриране на остарели ToS към DSCP; използване на EF за интерактивни сесии. - Агенти: адаптира скриптове и променливи към сокети под
~/.ssh/agent; цени автоматичното почистване от самия агент. - Големи конфигурацииАко генерирате групови конфигурации, ограничението се увеличава до 4MB; прилагайте го разумно и контролира валидирането.
- Анализаториизбягвайте изграждането на командни редове от ненадежден вход; използвайте
configлокални с литерали, когато имате странни случаи в потребителските имена.
Тези, които управляват смесени автопаркове, ще оценят това 10.1 стискайте сигурността там, където боли най-малко (парсери, агенти, предупреждения) и едновременно с това подобри ежедневното преживяване (Динамично QoS, SIGINFO, регистриране на сертификати). Ако вече сте използвали версия 10.0, преходът е лесен; ако идвате от версия 9.x, отделете време да настроите DSCP, да регенерирате SSHFP към SHA‑256 и да активирате хибридни KEX, за да се предпазите от квантовата заплаха, без да жертвате производителността.
