{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"OpenSSH 8.2-udgivelse med underst\u00f8ttelse af FIDO\/U2F to-faktor-autentifikationsenheder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Efter fire m\u00e5neders udvikling pr\u00e6senteret<\/a><\/noindex> udgivelse OpenSSH 8.2<\/a><\/noindex>, en open source-implementering af klient og server til arbejde med SSH 2.0- og SFTP-protokoller. <\/p>\n

En central forbedring i OpenSSH 8.2-udgivelsen er muligheden for at bruge to-faktor-autentifikation ved hj\u00e6lp af enheder, der underst\u00f8tter protokollen U2F<\/a><\/noindex>, udviklet af alliancen FIDO<\/a><\/noindex>. U2F muligg\u00f8r oprettelse af omkostningseffektive hardware tokens til bekr\u00e6ftelse af brugerens fysiske tilstedev\u00e6relse, hvor interaktionen sker via USB, Bluetooth eller NFC. S\u00e5danne enheder markedsf\u00f8res som et middel til to-faktor autentificering p\u00e5 websteder, underst\u00f8ttes allerede af de fleste webbrowsere og produceres af forskellige producenter, herunder Yubico, Feitian, Thetis og Kensington.<\/p>\n

For interaction with devices that verify the presence of a user, OpenSSH has added new key types «ecdsa-sk» and «ed25519-sk», which utilize the ECDSA and Ed25519 digital signature algorithms, together with the SHA-256 hash. The procedures for interacting with tokens have been extracted into an intermediate library, which is loaded similarly to the library that supports PKCS#11 and serves as a wrapper over the library. libfido2<\/a><\/noindex>, der giver midler til kommunikation med tokens over USB (underst\u00f8tter FIDO U2F\/CTAP 1 og FIDO 2.0\/CTAP 2 protokoller). Det mellemlag, der er forberedt af udviklerne af OpenSSH, er indarbejdet i hovedbiblioteket libfido2, ligesom er<\/a><\/noindex> HID-driveren til OpenBSD.<\/a><\/noindex> For at aktivere U2F kan du bruge den seneste version af kodebasen fra<\/p>\n

To authenticate and generate a key, you must specify the «SecurityKeyProvider» parameter in the settings or set the environment variable SSH_SK_PROVIDER, providing the path to the external library libsk-libfido2.so (export SSH_SK_PROVIDER=\\\/path\\\/to\\\/libsk-libfido2.so). It is possible to build openssh with built-in support for the wrapper library (\u2014with-security-key-builtin), in which case you must set the «SecurityKeyProvider=internal» parameter.
\nNext, you need to run «ssh-keygen -t ecdsa-sk», or if the keys are already created and configured, connect to the server using «ssh». When running ssh-keygen, the created key pair will be saved in «~\\\/ .ssh\\\/id_ecdsa_sk» and can be used similarly to other keys. <\/p>\n

The public key (id_ecdsa_sk.pub) should be copied to the server in the authorized_keys file. On the server side, only the digital signature is verified, and interaction with tokens is performed on the client side (there is no need to install libsk-libfido2 on the server, but the server must support the «ecdsa-sk» key type). The generated private key (id_ecdsa_sk) is essentially a descriptor of the key, forming the real key only in conjunction with the secret sequence stored on the U2F token. If the id_ecdsa_sk key falls into the hands of an attacker, they will also need access to the hardware token to pass authentication, without which the private key stored in the id_ecdsa_sk file is useless. <\/p>\n

Desuden kr\u00e6ves der som standard lokalt bekr\u00e6ftelse af brugerens fysiske tilstedev\u00e6relse ved udf\u00f8relse af enhver operation med n\u00f8gler (b\u00e5de ved generering og autentificering), for eksempel ved at ber\u00f8re sensoren p\u00e5 tokenet, hvilket vanskeligg\u00f8r udf\u00f8relsen af fjernafg\u00f8rende angreb p\u00e5 systemer med tilsluttet token. Som et ekstra sikkerhedstr\u00e6k kan der ved opstart af ssh-keygen ogs\u00e5 angives en adgangskode for at f\u00e5 adgang til n\u00f8glefilen. <\/p>\n

I den nye version af OpenSSH er der ogs\u00e5 offentliggjort en kommende nedgradering af algoritmer, der bruger SHA-1-hashes, i forbindelse med for\u00f8gelsen<\/a><\/noindex> effektiviteten af kollisionsangreb med et givet pr\u00e6fiks (omkostningerne ved at finde en kollision estimeres til cirka 45.000 dollars). I en af de kommende udgaver planl\u00e6gges det at deaktivere muligheden for at bruge algoritmen til digitale signaturer baseret p\u00e5 offentlige n\u00f8gler «ssh-rsa» som standard, hvilket n\u00e6vnes i den originale RFC for SSH-protokollen og stadig er meget udbredt i praksis (for at tjekke brugen af ssh-rsa i dine systemer kan du pr\u00f8ve at oprette forbindelse via ssh med indstillingen «-oHostKeyAlgorithms=-ssh-rsa»).<\/p>\n

For at lette overgangen til de nye algoritmer i OpenSSH vil der i en af de kommende udgaver blive inkluderet indstillingen UpdateHostKeys som standard, der automatisk vil overf\u00f8re klienter til mere p\u00e5lidelige algoritmer. Blandt de anbefalede algoritmer til migration n\u00e6vnes rsa-sha2-256\/512 baseret p\u00e5 RFC8332 RSA SHA-2 (underst\u00f8ttet siden OpenSSH 7.2 og bruges som standard), ssh-ed25519 (underst\u00f8ttet siden OpenSSH 6.5) og ecdsa-sha2-nistp256\/384\/521 baseret p\u00e5 RFC5656 ECDSA (underst\u00f8ttet siden OpenSSH 5.7).<\/p>\n

I versionen OpenSSH 8.2 er muligheden for at oprette forbindelse ved hj\u00e6lp af \u00abssh-rsa\u00bb stadig bevaret, men denne algoritme er blevet fjernet fra listen over CASignatureAlgorithms, der definerer de algoritmer, der er tilladt til digital signatur af nye certifikater. Tilsvarende er algoritmen diffie-hellman-group14-sha1 blevet fjernet fra de algoritmer til n\u00f8gleudveksling, der underst\u00f8ttes som standard. Det bem\u00e6rkes, at brugen af SHA-1 i certifikater medf\u00f8rer en \u00f8get risiko, da en angriber har ubegribelig tid til at finde kollisioner for et eksisterende certifikat, mens tiden for angreb p\u00e5 v\u00e6rtens n\u00f8gler er begr\u00e6nset af forbindelsestiden (LoginGraceTime). <\/p>\n

N\u00e5r ssh-keygen k\u00f8res, anvendes algoritmen rsa-sha2-512 som standard, hvilket har v\u00e6ret underst\u00f8ttet siden OpenSSH 7.2, hvilket kan skabe kompatibilitetsproblemer, n\u00e5r der fors\u00f8ges at behandle certifikater, der er underskrevet i OpenSSH 8.2, p\u00e5 systemer med \u00e6ldre versioner af OpenSSH (for at omg\u00e5 problemet under oprettelsen af signaturen kan man eksplicit angive \u00abssh-keygen -t ssh-rsa\u00bb eller bruge algoritmerne ecdsa-sha2-nistp256\/384\/521, som har v\u00e6ret underst\u00f8ttet siden OpenSSH 5.7).<\/p>\n

Andre \u00e6ndringer:<\/p>\n