По четири месеци развој ослободување , отворена имплементација на клиент и сервер за работа преку протоколите SSH 2.0 и SFTP.
Клучно подобрување во објавувањето на OpenSSH 8.2 беше можноста да се користи двофакторна автентикација користејќи уреди што го поддржуваат протоколот , развиен од алијансата . U2F овозможува создавање на евтини хардверски токени за да се потврди физичкото присуство на корисникот, во интеракција со нив преку USB, Bluetooth или NFC. Ваквите уреди се промовираат како средство за двофакторна автентикација на веб-локациите, веќе се поддржани од главните прелистувачи и се произведени од различни производители, вклучувајќи ги Yubico, Feitian, Thetis и Kensington.
За да комуницирате со уредите што го потврдуваат присуството на корисникот, во OpenSSH се додадени нови типови на клучеви „ecdsa-sk“ и „ed25519-sk“, кои ги користат алгоритмите за дигитален потпис ECDSA и Ed25519, во комбинација со хашот SHA-256. Процедурите за интеракција со токени се сместени во средна библиотека, која се вчитува на сличен начин како библиотеката за поддршка на PKCS#11 и е обвивка на врвот на библиотеката , кој обезбедува алатки за комуникација со токени преку USB (поддржани се протоколите FIDO U2F/CTAP 1 и FIDO 2.0/CTAP 2). Средна библиотека libsk-libfido2 подготвена од развивачите на OpenSSH во јадрото libfido2, како и за OpenBSD.
За автентикација и генерирање клуч, мора да го наведете параметарот „SecurityKeyProvider“ во поставките или да ја поставите променливата на околината SSH_SK_PROVIDER, означувајќи ја патеката до надворешната библиотека libsk-libfido2.so (извезете SSH_SK_PROVIDER=/path/to/libsk-libfido2. така). Можно е да се изгради openssh со вградена поддршка за библиотеката на слоеви (--with-security-key-builtin), во овој случај треба да го поставите параметарот „SecurityKeyProvider=internal“.
Следно, треба да извршите „ssh-keygen -t ecdsa-sk“ или, ако копчињата се веќе креирани и конфигурирани, поврзете се на серверот користејќи „ssh“. Кога ќе го стартувате ssh-keygen, генерираниот пар клучеви ќе се зачува во „~/.ssh/id_ecdsa_sk“ и може да се користи слично како и другите клучеви.
Јавниот клуч (id_ecdsa_sk.pub) треба да се копира на серверот во датотеката authorized_keys. На страната на серверот, само дигиталниот потпис е потврден, а интеракцијата со токените се врши на страната на клиентот (не треба да инсталирате libsk-libfido2 на серверот, но серверот мора да поддржува тип на клуч „ecdsa-sk“) . Генерираниот приватен клуч (id_ecdsa_sk) во суштина е рачка на клучот, формирајќи вистински клуч само во комбинација со тајната секвенца зачувана на страната на токенот U2F. Ако клучот id_ecdsa_sk падне во рацете на напаѓачот, за да помине автентикација, тој исто така ќе треба да добие пристап до хардверскиот токен, без кој приватниот клуч зачуван во датотеката id_ecdsa_sk е бескорисен.
Дополнително, стандардно, при извршување на какви било операции со клучеви (и за време на генерирањето и за време на автентикацијата), потребна е локална потврда за физичкото присуство на корисникот, на пример, се предлага да се допре сензорот на токенот, што го отежнува врши далечински напади на системи со поврзан токен. Како друга линија на одбрана, може да се наведе лозинка и за време на фазата на стартување на ssh-keygen за пристап до датотеката со клучеви.
Новата верзија на OpenSSH, исто така, го најави претстојното укинување на алгоритмите кои користат хашови SHA-1 поради ефективноста на нападите од судир со даден префикс (трошокот за избор на судир се проценува на приближно 45 илјади долари). Во едно од претстојните изданија, тие планираат стандардно да ја оневозможат можноста за користење на алгоритам за дигитален потпис со јавен клуч „ssh-rsa“, кој е споменат во оригиналниот RFC за протоколот SSH и останува широко распространет во пракса (за тестирање на употребата на ssh-rsa во вашите системи, можете да се обидете да се поврзете преку ssh со опцијата „-oHostKeyAlgorithms=-ssh-rsa“).
За да се ублажи транзицијата кон нови алгоритми во OpenSSH, во идното издание поставката UpdateHostKeys ќе биде стандардно овозможена, што автоматски ќе ги префрли клиентите кон посигурни алгоритми. Препорачани алгоритми за миграција вклучуваат rsa-sha2-256/512 врз основа на RFC8332 RSA SHA-2 (поддржан од OpenSSH 7.2 и се користи стандардно), ssh-ed25519 (поддржан од OpenSSH 6.5) и ecdsa-sha2-nistp256/384 базиран на RFC521 ECDSA (поддржано од OpenSSH 5656).
Во OpenSSH 8.2, можноста за поврзување со помош на „ssh-rsa“ сè уште е достапна, но овој алгоритам е отстранет од списокот CASignatureAlgorithms, кој ги дефинира алгоритмите дозволени за дигитално потпишување нови сертификати. Слично на тоа, алгоритмот diffie-hellman-group14-sha1 е отстранет од стандардните поддржани алгоритми за размена на клучеви. Забележано е дека употребата на SHA-1 во сертификатите е поврзана со дополнителен ризик, бидејќи напаѓачот има неограничено време да бара судир за постоечки сертификат, додека времето на напад на клучевите на домаќинот е ограничено со истекот на врската (LoginGraceTime ).
Работењето ssh-keygen сега е стандардно на алгоритмот rsa-sha2-512, кој е поддржан уште од OpenSSH 7.2, што може да создаде проблеми со компатибилноста при обидот да се обработат сертификатите потпишани во OpenSSH 8.2 на системи што работат постари изданија OpenSSH (за да се реши проблемот кога Кога генерирајќи потпис, можете експлицитно да наведете „ssh-keygen -t ssh-rsa“ или да ги користите алгоритмите ecdsa-sha2-nistp256/384/521, поддржани од OpenSSH 5.7).
Други промени:
- Додадена е директива Вклучи во sshd_config, која ви овозможува да ја вклучите содржината на другите датотеки на моменталната позиција на конфигурациската датотека (може да се користат глоб маски кога се одредува името на датотеката);
- Опцијата „без потреба од допир“ е додадена на ssh-keygen, што ја оневозможува потребата физички да се потврди пристапот до токенот при генерирање на клучот;
- Директивата PubkeyAuthOptions е додадена на sshd_config, која комбинира различни опции поврзани со автентикација на јавен клуч. Во моментов, поддржано е само знамето „не е потребно допир“ за да се прескокнат проверките за физичко присуство за автентикација на токен. По аналогија, опцијата „не е потребно допир“ е додадена во датотеката authorized_keys;
- Додадена е опцијата „-O write-attestation=/path“ на ssh-keygen за да се дозволи да се пишуваат дополнителни сертификати за атестирање FIDO при генерирање на клучеви. OpenSSH сè уште не ги користи овие сертификати, но тие подоцна може да се користат за да се потврди дека клучот е ставен во доверлива продавница за хардвер;
- Во поставките ssh и sshd, сега е можно да се постави режимот за приоритизација на сообраќајот преку директивата IPQoS (Понизок напор по хоп однесување);
- Во ssh, при поставување на вредноста „AddKeysToAgent=yes“, ако клучот не содржи поле за коментар, тој ќе се додаде во ssh-agent што ја покажува патеката до клучот како коментар. ВО
ssh-keygen и ssh-agent, исто така, сега користат етикети PKCS#11 и името на предметот X.509 наместо патеката на библиотеката како коментари во клучот; - Додадена е можност за извоз на PEM за клучеви DSA и ECDSA во ssh-keygen;
- Додадена е нова извршна датотека, ssh-sk-помошник, што се користи за изолирање на библиотеката за пристап до токени FIDO/U2F;
- Додадена е опцијата за градење „--with-zlib“ на ssh и sshd за компилација со поддршка за библиотека zlib;
- Во согласност со барањето на RFC4253, предупредувањето за блокирање на пристапот поради надминување на ограничувањата на MaxStartups е обезбедено во банерот прикажан за време на поврзувањето. За да се поедностави дијагностиката, заглавието на процесот sshd, видливо кога се користи алатката ps, сега го прикажува бројот на моментално автентицирани врски и статусот на ограничувањето на MaxStartups;
- Во ssh и ssh-agent, кога повикувате програма за прикажување покана на екранот, наведена преку $SSH_ASKPASS, сега дополнително се пренесува знаменце со типот на поканата: „потврди“ - дијалог за потврда (да/не), „нема ” - информативна порака, „празно“ - барање лозинка;
- Додадена е нова операција за дигитални потписи „find-principals“ на ssh-keygen за пребарување на датотеката дозволени-потписници за корисникот поврзан со одреден дигитален потпис;
- Подобрена поддршка за изолација на процесот sshd на Linux со користење на механизмот seccomp: оневозможување на IPC системски повици, дозволување на clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().
Извор: opennet.ru