OpenSSH 10.3 сега на разположение Той въвежда комбинация от корекции за сигурност, промени в поведението и нови възможности, които засягат както системните администратори, така и разработчиците. Въпреки че много от новите функции са технически, някои могат да причинят прекъсвания на връзката с по-стари клиенти или сървъри, ако конфигурациите не бъдат внимателно прегледани.
За корпоративни среди, където OpenSSH е основен компонент на Linux сървъри, BSD системи и мрежови устройства, тази актуализация е особено важна. Версия 10.3 отстранява уязвимости, коригира валидирането на сертификати и променя начина, по който се обработват определени опции за конфигурация, така че е препоръчително да се тества в предпроизводствени среди преди масово внедряване.
Нарушена съвместимост с имплементации без прекодировъчна система
Една от най-значимите промени в OpenSSH 10.3 е премахването на кода за „Съвместимост с грешки“ с имплементации, които не поддържат прекодиранеДосега проектът поддържаше серия от вътрешни корекции, които му позволяваха да продължи да комуникира с по-стари или нестандартни SSH клиенти или сървъри, на които им липсваше тази възможност за предоговаряне на ключове по време на сесията.
От тази версия нататък, ако a SSH клиентът или сървърът не поддържа прекодиранеВръзката с OpenSSH 10.3 просто ще се провали при опит за установяване на връзка или по време на сесията. Това може да повлияе на инфраструктури, които все още използват остарял софтуер, вградени устройства или собствени решения, които имплементират SSH протокола непълно.
Системните мениджъри в организациите трябва Инвентаризация на SSH устройства и услуги За да проверите дали всички компоненти поддържат прекодиране преди надстройване. В инсталации, където се поддържа по-стар хардуер или персонализиран софтуер, може да се наложи да надстроите тези компоненти или да ги изолирате в сегменти, където не се използва OpenSSH 10.3.
Поправка за грешка в инжектирането на команди чрез потребителско име
На клиента SSH коригира уязвимост при валидиране Това позволяваше, при определени условия, специалните символи на shell, присъстващи в потребителското име, да бъдат разширени преди проверката за сигурност. Проблемът възниква при използване на потребителски имена, контролирани от трети страни, и разширени конфигурации със заместващи токени.
По-конкретно, уязвимостта е засегнала конфигурации, които включват токена %u в рамките на блоковете за изпълнение Match във файла ssh_config. В този сценарий, нападател с възможността да повлияе на потребителското име, предадено на ssh командата, би могъл да изпълни произволни команди в обвивката, възползвайки се от разширяването на метасимволите.
Новата версия коригира реда на валидиране на тези параметри, за да предотвратяване на опасно разширяване на злонамерени потребителски имена. Въпреки това, разработчиците ни напомнят, че излагането на аргументи от командния ред на SSH на ненадежден вход все още е лоша дизайнерска практика, особено в скриптове или автоматизирани инструменти, използвани в големи среди.
Промени в обработката на сертификати и основни
OpenSSH 10.3 въвежда няколко съществени промени в Управление на SSH сертификати и неговите "основни" елементи (самоличности, с които е свързан сертификатът), с пряко въздействие върху начина на валидиране на достъпа.
Грешка при съпоставянето на главните символи със запетаи
Грешка е коригирана в sshd при сравняване на основната опция="" Проблемът възникна от записите в authorized_keys със списъка с принципали, включени в сертификат. Грешката възникна, когато едно от имената на принципали в сертификата съдържаше запетая, което можеше да доведе до неправилни съвпадения в много специфични сценарии.
За да може проблемът да бъде използваем, трябваше да бъдат изпълнени няколко условия: входните данни от authorized_keys включва повече от един основенГрешката накара сертифициращия орган да издаде сертификат с няколко от тези имена, разделени със запетаи, и да използва доверени от потребителя CA ключове. Основният поток за удостоверяване на сертификата, базиран на TrustedUserCAKeys и AuthorizedPrincipalsFile, не беше засегнат.
Сертификати с празен списък с главници
Друга промяна в поведението коригира проблемен исторически дизайн в сертификатитеДосега, когато сертификат с празна секция principals се използваше заедно с authorized_keys principals="", той се третираше де факто като заместващ символ, позволявайки удостоверяване като всеки потребител, който се доверява на същия сертифициращ орган.
Това представляваше неочевиден риск: CA, който погрешно издаде сертификат с празен основен списък Неволно предоставяше изключително широк достъп. В OpenSSH 10.3 тази ситуация се променя и сертификат без принципали вече се счита за несъответстващ на никой принципал, предотвратявайки това опасно поведение със „уайлдкард“.
Освен това, проектът има унифицирано третиране на заместващи символи в основните сертификатиИзползването на заместващи символи е разрешено в сертификатите на хостовете, но не и в потребителските сертификати. Това цели по-предсказуемо и одитираемо поведение, нещо особено ценено при одити на сигурността на европейски организации, подчинени на рамки като NIS2 или ENS.
Стриктно прилагане на ECDSA алгоритми
В криптографския раздел, OpenSSH 10.3 коригира проблем в прилагането на директивите PubkeyAcceptedAlgorithms и HostbasedAcceptedAlgorithms за ECDSA ключове. До тази версия, ако името на ECDSA алгоритъм се появяваше в някой от тези списъци, сървърът де факто приемаше други ECDSA алгоритми, дори ако те не бяха изрично изброени.
С новата редакция, sshd точно спазва списъка с разрешени алгоритмиТова запълва тази празнина и предлага по-фин контрол върху това кои варианти на ECDSA могат да се използват. Това е полезно за администратори, които искат да ограничат набора от алгоритми до по-надеждни профили или да се съобразят с препоръките за национална сигурност.
Корекция в scp при изтегляне като root
Инструментът scp също получава корекция за сигурност Когато се използва в legacy режим (съвместимост с rcp) и се изпълнява като root. В предишни версии, при изтегляне на файлове без използване на опцията -p, програмата не премахваше битовете setuid и setgid от получените файлове.
Това поведение, наследено от Оригиналната CPR на БърклиТова може да е опасно при определени работни потоци за копиране, тъй като файл, прехвърлен със специални разрешения, може да бъде изпълнен с повишени привилегии на целевата система. OpenSSH 10.3 коригира това поведение, за да засили сигурността при отдалечено администриране, често срещана практика на производствени сървъри в центрове за данни.
Подобрено валидиране и контрол на мултиплексирането на ProxyJump
Що се отнася до разширените опции за свързване, клиентът въвежда подобрения в ProxyJump (параметър -J или -oProxyJump)Сега стойностите на потребителя и хоста, предавани чрез командния ред, са по-стриктно валидирани, за да се предотвратят потенциални вектори за инжектиране на команди в конфигурации, където тези полета могат да бъдат повлияни от ненадежден вход.
Важно е да се отбележи, че това Валидацията се прилага само за това, което е получено чрез командния ред и не засяга стойностите, дефинирани в конфигурационните файлове. Въпреки това, осигурява допълнителен слой защита за скриптове, автоматизации и инструменти, които използват ProxyJump динамично.
В областта на мултиплексирането на връзките е решен проблем с потвърждение на сесията при използване на ControlMaster ask/autoask в прокси режим, използвайки "ssh -O proxy". Преди това заявките за потвърждение не се оценяваха правилно в този тип мултиплексирана сесия.
Освен това са добавени нови команди за получаване подробна информация за активните сесииКомандата „ssh -O conninfo“ и escape sequence „~I“ показват информация за връзката за текущи сесии, докато „ssh -O channels“ съобщава кои канали процесът на мултиплексора държи отворени. Тези функции могат да улеснят отстраняването на проблеми при сложни внедрявания, които са много често срещани в големи организации и доставчици на услуги в ЕС.
Какво е новото в ssh-agent, ssh-add и управлението на ключове
OpenSSH 10.3 прави още една крачка в съгласуване с проекта на IETF draft-ietf-sshm-ssh-agent Що се отнася до SSH агента, добавена е съвместимост с новите кодови точки, зададени от IANA за пренасочване на агенти, така че когато сървърът рекламира поддръжка за тези имена, използвайки съобщението EXT_INFO, OpenSSH дава приоритет на използването на стандартизираните идентификатори.
Въпреки това, подкрепата за Исторически разширения с наставката @openssh.comосигуряване на оперативна съвместимост със съществуващите инфраструктури. Компонентът ssh-agent включва и поддръжка за разширението „query“, дефинирано в същия проект, което позволява по-структурирано запитване към възможностите на агента.
От своя страна, полезността ssh-add добавя опцията -Q да заявите разширенията на протоколите, които агентът поддържа. Тази функционалност е особено полезна за екипи по сигурност и операции, които трябва да проверят какви функции са налични на агенти, разположени в различни системи.
В областта на ключовете, ssh-keygen вече включва възможността за запис на ED25519 ключове във формат PKCS8.Това улеснява интеграцията му с други криптографски инструменти и библиотеки, използвани в бизнес и публична администрация.
Произходни санкции и диагностични подобрения в SSHD
SSH сървърът включва подобрения, насочени към намаляване на злоупотребите и улесняване на наблюдаемостта. Едно от тях е въвеждането на наказание за невалиден потребител в рамките на PerSourcePenaltiesкоето се прилага, когато се получат опити за вход с потребителски имена, които не съществуват в системата.
По подразбиране това ново наказание се състои от изчакай пет секундиТова е в съответствие със съществуващото наказание за authfail, но администраторите могат да конфигурират по-дълги продължителности, ако открият атаки с груба сила или масови потребителски проверки. Освен това, времевата резолюция на наказанията вече е с плаваща запетая, което позволява наказания по-малки от една секунда при сценарии с висока честота на събития.
Успоредно с това, новите възможности за мултиплексиране, описани по-горе („ssh -O conninfo“, „ssh -O channels“ и escape „~I“) предоставят по-голяма видимост на активните връзкиТова може да бъде много полезно при диагностициране на проблеми със закъснението, блокиране или необичайно използване на SSH тунели и канали.
Още промени в сигурността и съвместимостта
Добавя OpenSSH 10.3 sshd сървърната опция GSSAPIDelegateCredentialsТази настройка контролира дали сървърът приема делегирани идентификационни данни, предлагани от клиента. Тази опция отразява съществуващата политика от страна на клиента и позволява поведението да се адаптира към вътрешните политики на всяка организация относно Kerberos и подобни делегирания на идентификационни данни.
Обхватът на Директиви RevokedHostKeys в ssh_config и RevokedKeys в sshd_configкойто вече може да сочи към множество файлове. Това улеснява управлението на списъци с отменени ключове, разделени по проекти, отдели или нива на доверие – полезно в големи инфраструктури с множество екипи и доставчици.
Версията също така коригира редица практически проблеми: грешка в Въвеждането на ПИН код за ключове PKCS#11 е въведено във версии 10.1 и 10.2., подобрена е обработката на подписи на FIDO/WebAuthn сертификати, коригиран е срив на sshd, свързан с липсващи директиви на подсистемата в блоковете Match, и е адресиран проблем с объркване на потребителски имена в PAM модула в преносимия клон.
С тази версия, OpenSSH 10.3 консолидира a цялостен пакет от промени, които подобряват безопасносттаТой коригира наследените поведения и разширява възможностите за управление, без да губи съвместимост с повечето съвременни внедрявания. Организациите, които разчитат на SSH за отдалечено администриране, автоматизация и сигурно тунелиране, биха направили добре да планират надстройката, като първо прегледат тестовите си среди за потенциални проблеми със наследени внедрявания, необичайни опции или силно персонализирани конфигурации.
