Na vier maanden ontwikkeling release , een open implementatie van een client en server voor communicatie via de SSH 2.0- en SFTP-protocollen.
Een belangrijke verbetering in de release van OpenSSH 8.2 is de mogelijkheid om two-factor authenticatie te gebruiken met apparaten die het protocol ondersteunen , ontwikkeld door de alliantie . U2F maakt het mogelijk om goedkope hardwaretokens te creëren voor het bevestigen van fysieke aanwezigheid van de gebruiker, waarbij interactie plaatsvindt via USB, Bluetooth of NFC. Dergelijke apparaten worden gepromoot als een middel voor tweefactorauthenticatie op sites, worden al ondersteund door de belangrijkste browsers en worden geproduceerd door verschillende fabrikanten, waaronder Yubico, Feitian, Thetis en Kensington.
Om te communiceren met apparaten die de aanwezigheid van de gebruiker bevestigen, zijn in OpenSSH nieuwe type sleutels 'ecdsa-sk' en 'ed25519-sk' toegevoegd, die gebruik maken van de digitale handtekeningalgoritmes ECDSA en Ed25519, in combinatie met de SHA-256 hash. De procedures voor interactie met tokens zijn verplaatst naar een tussentijdse bibliotheek die wordt geladen op een manier die vergelijkbaar is met de bibliotheek voor PKCS#11 en fungeert als een wrapper voor de bibliotheek. , die middelen biedt voor communicatie met tokens via USB (de protocollen FIDO U2F/CTAP 1 en FIDO 2.0/CTAP 2 worden ondersteund). De tussenbibliotheek libsk-libfido2, ontwikkeld door de ontwikkelaars van OpenSSH, is geïntegreerd in de hoofdbibliotheek libfido2, net zoals de HID-driver Om U2F in te schakelen, kan een recente snapshot van de codebase worden gebruikt uit
Voor authenticatie en sleutelgeneratie moet de parameter 'SecurityKeyProvider' in de instellingen worden opgegeven of de omgevingsvariabele SSH_SK_PROVIDER worden ingesteld met het pad naar de externe bibliotheek libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Het is ook mogelijk om openssh te bouwen met ingebouwde ondersteuning voor de tussenbibliotheek (-with-security-key-builtin), in dat geval moet de parameter 'SecurityKeyProvider=internal' worden ingesteld.
Vervolgens moet 'ssh-keygen -t ecdsa-sk' worden uitgevoerd of, als de sleutels al zijn gemaakt en geconfigureerd, verbinding worden gemaakt met de server via 'ssh'. Bij het uitvoeren van ssh-keygen zal het aangemaakte sleutelpaar worden opgeslagen in '~/.ssh/id_ecdsa_sk' en kan het worden gebruikt zoals andere sleutels.
De openbare sleutel (id_ecdsa_sk.pub) moet naar de server worden gekopieerd in het bestand authorized_keys. Aan de serverzijde wordt alleen de digitale handtekening gecontroleerd, terwijl de interactie met tokens aan de clientzijde plaatsvindt (libsk-libfido2 hoeft niet op de server te worden geïnstalleerd, maar de server moet het sleutetype 'ecdsa-sk' ondersteunen). De aangemaakte privésleutel (id_ecdsa_sk) fungeert in wezen als een descriptor voor de sleutel, die samen met de geheime volgorde die op het U2F-token is opgeslagen, de echte sleutel vormt. Als de sleutel id_ecdsa_sk in handen van een aanvaller valt, heeft deze ook toegang tot het hardware-token nodig om de authenticatie te doorstaan; zonder het opgeslagen id_ecdsa_sk-bestand is de privésleutel nutteloos.
Daarnaast is het standaard vereist dat een lokale bevestiging van de fysieke aanwezigheid van de gebruiker plaatsvindt bij het uitvoeren van enige sleuteloperaties (zoals generatie en authenticatie), bijvoorbeeld door te vragen om een sensor op de token aan te raken, wat het moeilijker maakt om op afstand aanvallen uit te voeren op systemen met een aangesloten token. Als een extra beveiligingsmaatregel kan ook een wachtwoord voor toegang tot het sleutelbestand worden ingesteld tijdens het opstarten van ssh-keygen.
In de nieuwe versie van OpenSSH is ook aangekondigd dat er binnenkort algoritmes die gebruikmaken van SHA-1-hashes als verouderd zullen worden geclassificeerd, vanwege van de effectiviteit van prefix-collision attacks (de kosten voor het raden van een botsing worden geschat op ongeveer 45 duizend dollar). In een van de komende versies is het plan om standaard de mogelijkheid tot het gebruik van het digitale handtekeningalgoritme "ssh-rsa", dat wordt genoemd in de originele RFC voor het SSH-protocol en nog steeds wijdverbreid is in de praktijk, uit te schakelen (om te controleren of ssh-rsa in uw systemen wordt toegepast, kunt u proberen verbinding te maken via ssh met de optie "-oHostKeyAlgorithms=-ssh-rsa").
Om de overgang naar nieuwe algoritmes in OpenSSH te vergemakkelijken, zal in een van de volgende versies standaard de instelling UpdateHostKeys worden ingeschakeld, die klanten automatisch naar betrouwbaardere algoritmes zal overzetten. Onder de aanbevolen algoritmes voor migratie worden rsa-sha2-256/512 op basis van RFC8332 RSA SHA-2 (ondersteund sinds OpenSSH 7.2 en standaard gebruikt), ssh-ed25519 (ondersteund sinds OpenSSH 6.5) en ecdsa-sha2-nistp256/384/521 op basis van RFC5656 ECDSA (ondersteund sinds OpenSSH 5.7) vermeld.
In OpenSSH versie 8.2 is de mogelijkheid om verbinding te maken met "ssh-rsa" voorlopig behouden, maar dit algoritme is verwijderd uit de lijst CASignatureAlgorithms, die de algoritmes bepaalt die zijn toegestaan voor digitale handtekeningen van nieuwe certificaten. Evenzo is het algoritme diffie-hellman-group14-sha1 verwijderd uit de standaard ondersteunde algoritmes voor sleuteluitwisseling. Het wordt opgemerkt dat het gebruik van SHA-1 in certificaten extra risico met zich meebrengt, omdat een aanvaller onbeperkte tijd heeft om een botsing voor een bestaand certificaat te vinden, terwijl de tijd voor aanvallen op hostkeys beperkt is door de verbindingstimeout (LoginGraceTime).
Bij het uitvoeren van ssh-keygen wordt nu standaard het rsa-sha2-512 algoritme toegepast, dat wordt ondersteund vanaf OpenSSH 7.2, wat compatibiliteitsproblemen kan veroorzaken bij het verwerken van certificaten ondertekend in OpenSSH 8.2 op systemen met oudere versies van OpenSSH (om het probleem bij het genereren van handtekeningen te omzeilen, kan "ssh-keygen -t ssh-rsa" expliciet worden opgegeven of kunnen algoritmen ecdsa-sha2-nistp256/384/521 worden gebruikt, die worden ondersteund vanaf OpenSSH 5.7).
Andere wijzigingen:
- In sshd_config is de Include-directive toegevoegd, waarmee de inhoud van andere bestanden op de huidige positie van het configuratiebestand kan worden opgenomen (bij het opgeven van de bestandsnaam zijn glob-patronen toegestaan);
- In ssh-keygen is de optie "no-touch-required" toegevoegd, waarmee de noodzaak voor fysieke bevestiging van de toegang tot de token bij het genereren van de sleutel wordt uitgeschakeld;
- In sshd_config is de directive PubkeyAuthOptions toegevoegd, die verschillende opties met betrekking tot authenticatie via openbare sleutels combineert. Momenteel wordt alleen de vlag "no-touch-required" ondersteund om de controle op fysieke aanwezigheid bij autorisatie met behulp van de token over te slaan. In overeenstemming hiermee is de optie "no-touch-required" ook toegevoegd aan het bestand authorized_keys;
- In ssh-keygen is de optie "-O write-attestation=/path" toegevoegd, waarmee extra attestatiecertificaten FIDO kunnen worden geschreven bij het genereren van sleutels. OpenSSH gebruikt deze certificaten momenteel nog niet, maar ze kunnen in de toekomst worden gebruikt om de plaatsing van de sleutel in een betrouwbaar hardware-opslagmedium te verifiëren;
- In de instellingen van ssh en sshd kan nu via de directive IPQoS de prioriteitsmodus voor verkeer worden ingesteld. (Lower-Effort Per-Hop Behavior);
- In ssh, bij het instellen van de waarde "AddKeysToAgent=yes", als de sleutel geen commentaarveld bevat, wordt deze toegevoegd aan de ssh-agent met het pad naar de sleutel als commentaar. In
ssh-keygen en ssh-agent worden nu ook PKCS#11 labels en het onderwerp X.509 naam als commentaar in de sleutel gebruikt in plaats van het pad naar de bibliotheek; - In ssh-keygen is de mogelijkheid toegevoegd om PEM te exporteren voor DSA- en ECDSA-sleutels;
- Een nieuw uitvoerbaar bestand ssh-sk-helper is toegevoegd, dat wordt gebruikt voor de isolatie van de toegang tot FIDO/U2F-tokenbibliotheek;
- In ssh en sshd is een bouwoptie "--with-zlib" toegevoegd voor compilatie met ondersteuning voor de zlib-bibliotheek;
- Conform de eisers van RFC4253 wordt in de weergegeven banner bij de verbinding een waarschuwing getoond over de blokkering van de toegang wegens overschrijding van de MaxStartups-limieten. Voor vereenvoudigde diagnose wordt het aantal momenteel geauthentiseerde verbindingen en de status van de MaxStartups-limiet weergegeven in de kop van het sshd-proces, dat zichtbaar is bij het gebruik van de ps-tool;
- Bij ssh en ssh-agent wordt nu, bij het aanroepen van het programma dat de prompt op het scherm toont, dat via $SSH_ASKPASS is ingesteld, een vlag met het type prompt meegegeven: "confirm" — bevestigingsdialoog (ja/nee), "none" — informatief bericht, "blank" — wachtwoord prompt;
- In ssh-keygen is een nieuwe bewerking voor digitale handtekeningen toegevoegd: "find-principals" voor het zoeken in het bestand allowed-signers van de gebruiker, gerelateerd aan de opgegeven digitale handtekening;
- De ondersteuning voor procesisolatie van sshd in Linux is verbeterd met behulp van het seccomp-mechanisme: systeemaanroepen IPC zijn verboden, terwijl clock_gettime64(), clock_nanosleep_time64 en clock_nanosleep() zijn toegestaan.
Bron: opennet.ru
