OpenSSH 8.2 heeft ondersteuning voor hardwarematige authenticatie via FIDO U2F

De release van versie 8.2 voegt ondersteuning voor FIDO U2F-hardwareauthenticators toe, waarmee bijvoorbeeld usb-sleutels op basis van de FIDO-standaard te gebruiken zijn voor tweetrapsauthenticatie.

Volgens de releasenotes van OpenSSH 8.2 kunnen de netwerktools dankzij de ondersteuning gebruikt worden in combinatie met relatief goedkope 2fa-hardware die gebruikt kan worden voor website-authenticatie. U2F staat voor Universal 2nd Factor en is een open standaard die wordt beheerd door de FIDO Alliance. OpenSSH ondersteunt FIDO-apparaten met nieuwe public key-types 'ecdsa-sk' en 'ed25519-sk', samen met corresponderende certificaattypes, staat in de releasenotes.

Wat beveiliging betreft accepteert OpenSSH het op sha1 gebaseerde 'ssh-rsa'-algoritme niet meer. Bij het berekenen van een via ssh-keygen aangemaakt certificaat wordt standaard het rsa-sha2-512-algoritme gebruikt. Sha1 is verouderd en vatbaar voor collision-aanvallen. Gebruik wordt daarom afgeraden.

Ook al maakt het certificaatformaat van OpenSSH uitbuiting van chosen-prefix collisions lastig, toch is sha1 volgens de ontwikkelaars een aantoonbaar gebrekkig algoritme en zijn verbeteringen van aanvallen zeer waarschijnlijk.

Reacties (23)

Zal dit betekenen dat ik geen OpenGPG meer nodig heb? En dus "native" op elke PC mn Yubikey kan inserten en kan SSH'en?

Zal dit betekenen dat ik geen OpenGPG meer nodig heb? En dus "native" op elke PC mn Yubikey kan inserten en kan SSH'en?

Als je een Yubikey hebt met FIDO2 (vanaf Yubikey 5 volgens mij), dan komt dat daarop neer ongeveer, maar je moet wel een security key library geïnstalleerd hebben nog (bijvoorbeeld die van Yubico).
Instructies hier: https://lists.mindrot.org...2019-November/037999.html

Conceptueel gezien komt het overeen met wat al mogelijk was met de OpenPGP applet die ook al op oudere Yubikeys zit (met GnuPG SSH agent).

Volgens mij gaat het niet zo "plug&play" makkelijk worden als nu met Chrome en WebUSB al mogelijk is met alle tricks in de browser meegeleverd.

[Reactie gewijzigd door gertvdijk op 14 februari 2020 17:13]

Client en server zullen het moeten ondersteunen. Op den duur komt dat vanzelf.

PAM werkt niet remote icm GnuPG of SC. Zelfs lokaal zal je DM het moeten ondersteunen. En PAM is nogal complex om te configureren.

Komt er op neer dat dit net zo gebruikersvriendelijk is als Chrome plus WebUSB. Het voordeel is dat je er een ander wachtwoord aan kunt hangen dan het wachtwoord zonder de token. Ook kun je forceren dat je enkel met public key authentication in kunt loggen.

Ander voordeel is dat FIDO2 only keys (dus met enkel die feature) goedkoop zijn. Rond de 20 EUR heb je er al eentje. Dat is 60% goedkoper dan een Yubikey 5 !

Client en server zullen het moeten ondersteunen.

Correct:

quote: https://lists.mindrot.org...2019-November/037999.html

[...] append the public key to authorized_keys as you would normally. Note that U2F keys are a new OpenSSH key type, so the server must support it too.

Als ik het goed begrijp heb je server-side verder niks nodig behalve een updated OpenSSH server. Ik leid hieruit af dat in de public key alle nodige informatie in zit voor de server. En je hebt dan geen fido2 library installatie nodig aan de serverkant? Zoals ik het lees is dat namelijk puur als middleware provider voor de SSH agent (die je client side alleen draait).

Als iemand dat kan bevestigen, graag.

Zo lees ik het ook inderdaad. Volgens mij is het 2FA gedeelte dat de private key op je lokale disk nog extra ondertekend moet worden door het harware token en dat die je door middel het aanraken van het token.

Ik vermoed van wel; zo werkt de huidige implementatie met de Yubikey via GPG naar SSH ook Zeker weten doe ik het eerdaags, zodra OpenSSH 8,2 in de snapshots van OpenBSD te vinden is probeer ik het gelijk uit!

[Reactie gewijzigd door jurroen op 14 februari 2020 22:31]

verwijder deze reactie

[Reactie gewijzigd door krabbedoelie op 17 februari 2020 22:21]

Dat is aan jezelf en ligt ook aan je Yubikey. Ze ondersteunen inderdaad FIDO2 maar daar heb je dus een Yubikey 5 voor nodig (vanaf die versie wordt FIDO2 ondersteund). Het gevaar aan deze setup is wel dat wanneer je je token verliest je ook meteen alles verliest. Voor een aanvaller is het daarmee heel interessant om je Yubikey buit te maken.

De andere optie is voor de oudere Yubikeys waarbij er alleen U2F wordt toegevoegd aan het ssh key pair. Je moet namelijk wel een nieuw key pair genereren omdat de fysieke token aan dat key pair gekoppeld moet worden. Dit werkt echter verder net als een normaal ssh key pair: zowel de public als private versie komen op je computer te staan. Daarmee heb je dus bijna hetzelfde probleem als met de FIDO2 situatie, het enige verschil is dat je hier nog wel je 2e factor token hebt en je key pair zonder die 2e factor dus niet bruikbaar is. Deze manier van werken is op internet al door een aantal mensen beschreven (het kon dus al veel eerder) maar het is goed om te zien dat dit soort dingen nu standaard onderdeel zijn van OpenSSH zelf.
Houdt er trouwens wel rekening mee dat het standaard gedrag is dat je wel iedere keer je Yubikey moet aanraken als je ergens inlogt (kan irritant gaan worden). Dat gedrag is uit te zetten door een nieuw key pair te genereren met de "no-touch-required" optie.

OpenGPG heeft in deze ook een aantal voordelen tov U2F en FIDO2: je private key staat op de Yubikey zelf en je kunt OpenGPG voor meer dan alleen ssh gebruiken (ondertekenen en versleutelen van berichten en bestanden). Bovendien scheidt je hiermee ook laptop en key. Handig want een laptop is nogal diefstalgevoelig. Daarentegen kun je zowel een laptop als Yubikey verliezen.

Wat je overigens wel oplost met een gewoon ssh key pair tov OpenGPG: je hoeft geen ssh-agent voor gpg-agent te vervangen en je hebt ook niet dat iets anders je Yubikey kaapt wanneer je deze bijv. ook gebruikt met certificaten.

Shit, die deprecation van ssh-rsa is vervelend want ik gebruik die met smartcards (OpenPGP en PIV). Allemaal ssh-rsa. Meestal yubikeys die ook met U2F werken, maar ik wil dat dan ook wel met pincode gebruiken en of deze implementatie dat ook doet is me nog niet duidelijk.

Op zich moet het ook wel mogelijk zijn om rsa-sha2-512 met een smartcard te doen, voor zover ik weet doet de smartcard alleen het RSA gedeelte en niet de hash die er overheen komt. Weer iets om uit te zoeken de komende tijd.

Overigens zullen de bestaande distributies nog wel lang de oudere versies blijven ondersteunen.

Je kan gewoon de RSA keys blijven gebruiken op tokens/smartcards. De hashes in de authenticatie zijn niet afhankelijk van het key type op disk ofzo, maar je hebt gelijk dat je token wel zo'n signature moet kunnen zetten. Het is dus afhankelijk wat de combinatie van SSH client + PKCS#11 middleware + hardware token kan met een RSA key. Als ergens in die chain alleen maar SHA1 zit, dan gaat het niet werken.

Op zich moet het ook wel mogelijk zijn om rsa-sha2-512 met een smartcard te doen, voor zover ik weet doet de smartcard alleen het RSA gedeelte en niet de hash die er overheen komt. Weer iets om uit te zoeken de komende tijd.

Juist wel. De token doet het werk door die hash te ondertekenen met de sleutel die hij heeft.

Als je nu RSA keys op disk hebt staan, heb je niks te vrezen. Een nieuwe SSH client kan gewoon SHA2 sigs maken in de authenticatie. Uit de RFC:

quote: https://tools.ietf.org/html/rfc8332#section-3

Since RSA keys are not dependent on the choice of hash function, the
new public key algorithms reuse the "ssh-rsa" public key format as
defined in [RFC4253]:

string "ssh-rsa"
mpint e
mpint n

All aspects of the "ssh-rsa" format are kept, including the encoded
string "ssh-rsa". This allows existing RSA keys to be used with the
new public key algorithms, without requiring re-encoding or affecting
already trusted key fingerprints.

[Reactie gewijzigd door gertvdijk op 15 februari 2020 01:14]

Juist wel. De token doet het werk door die hash te ondertekenen met de sleutel die hij heeft.

Ja maar de hash wordt zelf niet gegenereerd door de token volgens mij. Dus kan hij ook gewoon een SHA2 hash ondertekenen.

Ik heb de private keys niet op disk staan, alleen in de tokens zelf (is ook bij voorkeur de juiste manier omdat ze op die manier nooit kunnen lekken, je kan ze namelijk niet exporteren). Echter kan ik volgens mij wel de volledige public key uitlezen, dus dat zou op zich ook nog een manier zijn. Ga ik proberen.

Opzich heel leuk, maar je zit bij veel zaken vast aan de ssh versie die op het device (cisco, juniper etc) en het os (redhat) geleverd worden.

Meeste vendors maken gebruik van OpenSSH server, o.a. Juniper, Cisco en Red hat. Het is dus kwestie van tijd tot deze support krijgen van deze functie. Hou er echter rekening mee dat het sowieso niet tot de standaarden behoren van SSH.

Apple gebruikt al een tijdje LibreSsh ipv OpenSsh. Zover ik kon zien heeft LibreSsh nog geen U2f support.

MacOS gebruikt wel degelijk OpenSSH, echter gebruikt OpenSSH op MacOS niet OpenSSL maar LibreSSL als TLS/crypto library.
Volgens mij is LibreSSH een niet bestaand product/project.

[Reactie gewijzigd door mcbrown90 op 14 februari 2020 23:08]

Sorry je hebt gelijk, niet geheel.een snuggere opmerking van mij inderdaad.

Yep. Maar met die gedachte, komt er nooit iets nieuws.

Met een beetje gelukkig hebben de opvolgende apparaten deze ondersteuning wel, en over een jaar of 10 zijn die overal doorgedrongen.

Hoezo op de volgende apparaten? Cisco en juniper en dergelijke moeten ook hun software regelmatig bijwerken. Dat doet AMV voor de FritzBoxen ook. Omdat mijn fritzbox zelf het internet op mag, haalt ze regelmatig een nieuwere versie op.

Dus val vooral je favoriete vendor lastig met een feature request om dit te implementeren!

Hoera - eindelijk SSH met mijn open source solokeys! (ipv. die rommel van google te moeten gebruiken - is er een 2e alternatief).

Idd, en ook de SoloKeys nog ff doorontwikkelen

Helaas zonder ed25519 want Somu heeft die target niet gehaald.

Wat beveiliging betreft accepteert OpenSSH het op sha1 gebaseerde 'ssh-rsa'-algoritme niet meer. Bij het berekenen van een via ssh-keygen aangemaakt certificaat wordt standaard het rsa-sha2-512-algoritme gebruikt. Sha1 is verouderd en vatbaar voor collission-aanvallen. Gebruik wordt daarom afgeraden.

In deze release wordt ssh-rsa nog steeds ondersteund, maar in een 'near-future release' zal deze ondersteuning standaard uitgeschakeld worden.