Post kvar monatoj da evoluo liberigi , malferma kliento kaj servila efektivigo por labori per la SSH 2.0 kaj SFTP protokoloj.
Ŝlosila plibonigo en la liberigo de OpenSSH 8.2 estis la kapablo uzi dufaktoran aŭtentikigon uzante aparatojn kiuj subtenas la protokolon. , evoluigita fare de la alianco . U2F permesas la kreadon de malmultekostaj aparataj ĵetonoj por kontroli la fizikan ĉeeston de la uzanto, interagante kun ili per USB, Bluetooth aŭ NFC. Tiaj aparatoj estas reklamitaj kiel rimedo de dufaktora aŭtentigo en retejoj, jam estas subtenataj de ĉefaj retumiloj kaj estas produktitaj de diversaj fabrikantoj, inkluzive de Yubico, Feitian, Thetis kaj Kensington.
Por interagi kun aparatoj, kiuj konfirmas la ĉeeston de la uzanto, novaj ŝlosilaj tipoj "ecdsa-sk" kaj "ed25519-sk" estis aldonitaj al OpenSSH, kiuj uzas la algoritmojn de cifereca subskribo ECDSA kaj Ed25519, kombinitaj kun la SHA-256 hash. Proceduroj por interagado kun ĵetonoj estas metitaj en mezan bibliotekon, kiu estas ŝarĝita en simila maniero al la biblioteko por PKCS#11-subteno kaj estas envolvaĵo supre de la biblioteko. , kiu disponigas ilojn por komuniki kun ĵetonoj per USB (protokoloj FIDO U2F/CTAP 1 kaj FIDO 2.0/CTAP 2 estas subtenataj). Meza biblioteko libsk-libfido2 preparita de OpenSSH-programistoj en la kernon libfido2, same kiel por OpenBSD.
Por aŭtentikigi kaj generi ŝlosilon, vi devas specifi la parametron "SecurityKeyProvider" en la agordojn aŭ agordi la mediovariablon SSH_SK_PROVIDER, indikante la vojon al la ekstera biblioteko libsk-libfido2.so (eksportu SSH_SK_PROVIDER=/path/to/libsk-libfido2. do). Eblas konstrui openssh kun enkonstruita subteno por la tavola biblioteko (--with-security-key-builtin), ĉi-kaze vi devas agordi la parametron "SecurityKeyProvider=interna".
Poste vi devas ruli "ssh-keygen -t ecdsa-sk" aŭ, se la ŝlosiloj jam estas kreitaj kaj agordis, konekti al la servilo per "ssh". Kiam vi rulas ssh-keygen, la generita ŝlosilparo estos konservita en "~/.ssh/id_ecdsa_sk" kaj povas esti uzata simile al aliaj ŝlosiloj.
La publika ŝlosilo (id_ecdsa_sk.pub) estu kopiita al la servilo en la dosiero authorized_keys. Ĉe la servilo, nur la cifereca subskribo estas kontrolita, kaj interago kun ĵetonoj estas farita ĉe la klienta flanko (vi ne bezonas instali libsk-libfido2 sur la servilo, sed la servilo devas subteni la "ecdsa-sk" ŝlosiltipo) . La generita privata ŝlosilo (id_ecdsa_sk) estas esence ŝlosila tenilo, formante realan ŝlosilon nur en kombinaĵo kun la sekreta sekvenco stokita sur la U2F-ĵetonflanko. Se la id_ecdsa_sk-ŝlosilo falas en la manojn de atakanto, por pasigi aŭtentikigon li ankaŭ bezonos akiri aliron al la aparatara ĵetono, sen kiu la privata ŝlosilo konservita en la id_ecdsa_sk-dosiero estas senutila.
Krome, defaŭlte, kiam oni faras ajnajn operaciojn per klavoj (kaj dum generacio kaj dum aŭtentigo), loka konfirmo de la fizika ĉeesto de la uzanto necesas, ekzemple, oni proponas tuŝi la sensilon sur la ĵetono, kio malfaciligas fari forajn atakojn sur sistemoj kun konektita ĵetono. Kiel alia defendlinio, pasvorto ankaŭ povas esti specifita dum la ekfazo de ssh-keygen por aliri la ŝlosilan dosieron.
La nova versio de OpenSSH ankaŭ anoncis la venontan malrekomendiĝon de algoritmoj uzantaj SHA-1-haŝojn pro la efikeco de kolizio-atakoj kun donita prefikso (la kosto de elekto de kolizio estas taksita proksimume 45 mil dolaroj). En unu el la venontaj eldonoj, ili planas malebligi defaŭlte la kapablon uzi la ciferecan subskriban algoritmon de publika ŝlosilo "ssh-rsa", kiu estas menciita en la originala RFC por la SSH-protokolo kaj restas ĝeneraligita en la praktiko (por testi la uzon de ssh-rsa en viaj sistemoj, vi povas provi konekti per ssh kun la opcio "-oHostKeyAlgorithms=-ssh-rsa").
Por glatigi la transiron al novaj algoritmoj en OpenSSH, en estonta eldono la agordo UpdateHostKeys estos ebligita defaŭlte, kiu aŭtomate migros klientojn al pli fidindaj algoritmoj. Rekomenditaj algoritmoj por migrado inkluzivas rsa-sha2-256/512 bazitan sur RFC8332 RSA SHA-2 (subtenata ekde OpenSSH 7.2 kaj uzata defaŭlte), ssh-ed25519 (subtenata ekde OpenSSH 6.5) kaj ecdsa-sha2-nistp256/384/521/5656. sur RFC5.7 ECDSA (subtenata ekde OpenSSH XNUMX).
En OpenSSH 8.2, la kapablo konekti per "ssh-rsa" ankoraŭ haveblas, sed ĉi tiu algoritmo estis forigita de la listo CASignatureAlgorithms, kiu difinas la algoritmojn permesitajn por ciferece subskribi novajn atestojn. Simile, la diffie-hellman-group14-sha1-algoritmo estis forigita de la defaŭltaj ŝlosil-interŝanĝaj algoritmoj subtenataj. Oni rimarkas, ke la uzo de SHA-1 en atestiloj estas rilata al plia risko, ĉar la atakanto havas senliman tempon por serĉi kolizion por ekzistanta atestilo, dum la tempo de atako sur gastigaj ŝlosiloj estas limigita de la konektotempo (LoginGraceTime). ).
Ruli ssh-keygen nun defaŭlte al la rsa-sha2-512-algoritmo, kiu estas subtenata ekde OpenSSH 7.2, kiu povas krei kongruecajn problemojn kiam oni provas prilabori atestojn subskribitajn en OpenSSH 8.2 en sistemoj funkciantaj pli malnovajn OpenSSH-eldonojn (por trakti la problemon kiam Kiam generante subskribon, vi povas eksplicite specifi "ssh-keygen -t ssh-rsa" aŭ uzi la ecdsa-sha2-nistp256/384/521-algoritmojn, subtenatajn ekde OpenSSH 5.7).
Aliaj ŝanĝoj:
- Inkludi direktivo estis aldonita al sshd_config, kiu ebligas al vi inkluzivi la enhavon de aliaj dosieroj ĉe la nuna pozicio de la agorda dosiero (globaj maskoj povas esti uzataj kiam oni specifas la dosiernomon);
- La opcio "ne-tuŝa postulata" estis aldonita al ssh-keygen, kiu malŝaltas la bezonon fizike konfirmi aliron al la ĵetono dum generado de la ŝlosilo;
- PubkeyAuthOptions direktivo estis aldonita al sshd_config, kiu kombinas diversajn opciojn rilate al publika ŝlosila aŭtentikigo. Nuntempe, nur la "ne-tuŝa postulata" flago estas subtenata por salti fizikajn ĉeestkontrolojn por ĵetono-aŭtentikigo. Analogie, la opcio "ne-tuŝo-bezonata" estis aldonita al la dosiero authorized_keys;
- Aldonita "-O write-attestation=/path" opcio al ssh-keygen por permesi aldonaj FIDO-atestatestiloj esti skribitaj dum generado de ŝlosiloj. OpenSSH ankoraŭ ne uzas ĉi tiujn atestilojn, sed ili poste povas esti uzataj por kontroli, ke la ŝlosilo estas metita en fidinda aparataro;
- En la agordoj ssh kaj sshd, nun eblas agordi la trafikan prioritatreĝimon per la direktivo IPQoS. (Malsupra-Effort Per-Hop Konduto);
- En ssh, kiam oni fiksas la valoron "AddKeysToAgent=yes", se la ŝlosilo ne enhavas komentan kampon, ĝi estos aldonita al ssh-agent indikante la vojon al la ŝlosilo kiel komenton. EN
ssh-keygen kaj ssh-agent ankaŭ nun uzas PKCS#11-etikedojn kaj la X.509-subjektan nomon anstataŭ la biblioteka vojo kiel komentojn en la ŝlosilo; - Aldonis la kapablon eksporti PEM por DSA kaj ECDSA-ŝlosiloj al ssh-keygen;
- Aldonita nova rulebla, ssh-sk-helper, uzata por izoli la FIDO/U2F-ĵetonan alirbibliotekon;
- Aldonita "--with-zlib" konstruopcio al ssh kaj sshd por kompilo kun zlib biblioteko subteno;
- Konforme al la postulo de RFC4253, averto pri alirblokado pro superado de MaxStartups-limoj estas disponigita en la standardo montrita dum konekto. Por simpligi diagnozon, la sshd-proceza kaplinio, videbla dum uzado de la ps-utilo, nun montras la nombron da aktuale aŭtentikigitaj konektoj kaj la staton de la MaxStartups-limo;
- En ssh kaj ssh-agent, kiam oni vokas programon por montri inviton sur la ekrano, specifita per $SSH_ASKPASS, nun aldone transdonas flago kun la speco de invito: "konfirmi" - konfirma dialogo (jes/ne), "neniu". ” - informa mesaĝo, "blanka" - pasvorta peto;
- Aldonis novan operacion de ciferecaj subskriboj "find-principals" al ssh-keygen por serĉi la permesitajn subskribilojn por la uzanto asociita kun specifita cifereca subskribo;
- Plibonigita subteno por sshd-proceza izolado en Linukso uzante la seccomp-mekanismon: malŝaltante IPC-sistemvokojn, permesante clock_gettime64(), clock_nanosleep_time64 kaj clock_nanosleep().
fonto: opennet.ru