OpenSSH 8.2 mit FIDO support!

[Mickey Mouse]

(vor)gestern ist OpenSSH 8.2 mit support für FIDO raus gekommen (release notes)

leider finde ich keine binary Version für Windows. Das was es da von MS direkt gibt ist uralt und so buggy, dass es nichtmal (die im Moment von mir genutzte Variante) über KeepassXC funktioniert. Hoffentlich gibt es da bald Updates, ich habe nichtmal einen Compiler installiert.

allerdings funktioniert das ganze auch (noch) nicht out of the box auf den Macs. Sowohl die "fertige" homebrew als auch die selbst aus den sourcen compilierte Variante zeigt auf drei verschiedenen Macs dasselbe (Fehl)Verhalten beim (Versuch) Generieren eines FIDO gesicherten key-pairs:
Generating public/private ecdsa-sk key pair. You may need to touch your authenticator to authorize key generation. Provider „/usr/local/lib/yubico-piv-tool-2.0.0-mac/lib/libykcs11.dylib" dlsym(sk_api_version) failed: dlsym(0x7fbb4cd00730, sk_api_version): symbol not found Key enrollment failed: invalid format

ich muss nachher mal in Ruhe gucken was da schief läuft bzw. fehlt (Library für den Stick?)

auf jeden Fall ist das eine sehr interessante Sache, weil mal Hand aufs Herz, wer versieht seine ssh keys schon mit wirklich einzigartigen, sicheren und langen passphrases? Und physikalischer Zugriff auf den (FIDO)key ist auch noch nötig.
hoffentlich klappt das bald (Mac und Windows)

 

[madmax2010]

Ja, auch gesehen. Super gut

 

[Piktogramm]

auf jeden Fall ist das eine sehr interessante Sache, weil mal Hand aufs Herz, wer versieht seine ssh keys schon mit wirklich einzigartigen, sicheren und langen passphrases?

🙋‍♂️

Danke für die News.

 

[Mickey Mouse]

leider bekomme ich das auf dem Mac nicht zum Laufen (unter Windows natürlich schon gar nicht).
es geht wohl "nur" um die shared library "libsk-libfido2.so" (libykcs11.dylib aus dem Beispiel oben war eh falsch).
wenn ich die nach Anleitung aus den Sourcen kompilieren möchte, dann bekomme ich eine libfido2 aber keine libsk-fido2. In den gesamten src-tree gibt es nicht einen einzigen Verweis auf libsk-fido2, nichts!

in einem Tar Archive direkt von Yubico gibt es tatsächlich die Library. Aber die verweist auf die anderen Libraries (die ich ja sogar habe) an völlig krummen Ort (/Users/eddy/... oder so). Auch das habe ich mal nach gespielt und es existieren die Symbols aber die Version ist zu alt für OpenSSH 8.2 und wird nicht akzeptiert.

woher soll man denn diese Library bekommen?
in den docs wird willkürlich zwischen libfido2 und libsk-fido2 gewürfelt, das macht die Sache nicht leichter...
z.B. hier:
"2. Build libfido2:

If you're on OpenBSD, the see my recent posts to the ports@ mailing
list for libfido2 and its dependencies. Hopefully these will be added
to the ports tree soon.

Otherwise, you'll need to install libfido2's dependencies and
libfido2 HEAD yourself by cloning https://github.com/Yubico/libfido2
and following its build instructions. libfido2 will install a
${libdir}/libsk-libfido2.so shared object - that's the middleware you
need for the subsequent steps."

GENAU DAS habe ich gemacht (s.o.) und es gibt KEINE libsk-libfido2 (weder .so noch .dylib, nichtmal ne .a), obwohl es keine Fehler gibt und auch die Beispiel Programme kompiliert (und gelinkt) werden.
s.o. in dem GESAMTEN Tree, der explizit als Quelle für libsk-libfido2 genannt wird, taucht der String libsk-libfido2 nicht ein einziges Mal auf, wollen die einen nur verarschen oder was?

Edit: die aktuelle libfido2 Version (1.3.0 von Yubico, auf die auch überall verwiesen wird) scheint nicht kompatibel/ausreichend zu/für OpenSSH 8.2p1 zu sein.
libsk-libfido2.so" implements unsupported version 0x00020001 (supported: 0x00040000)
und nein, es reicht nicht aus, einfach die Version hoch zu setzen, es fehlt tatsächlich Funktionalität, z.B. die Funktion sk_load_resident_keys.

mit anderen Worten: ja, OpenSSH unterstützt jetzt "scheinbar" FIDO2, man muss sich nur die notwendige Middleware dafür SELBER PROGRAMMIEREN, selber kompilieren reicht nicht aus, toll...

 

[Mickey Mouse]

ich hole das nochmal hoch,weil es leider immer noch nicht funktioniert (man nervt mich das an...)

selber kompilieren hat nicht geklappt, die "middleware" wurde trotz "--with-security-key-builtin" und "--enable-security-key" beim configure ums Verrecken nicht einkompiliert, beim Versuch darauf zuzugreifen kommt immer nur "no internal security key builtin".
egal, die Jungs und Mädels von homebrew haben das offensichtlich umschifft und damit kann ich jetzt einen "ecdsa-sk" Key-Paar generieren, mit dem Yubikey, der muss auch drin stecken und man muss den Knopf drücken (wenn nicht anders angegeben).

nur ist dieses Key-Paar komplett nutzlos

ich kann es weder zum ssh-agent adden noch mich damit bei einem anderen Rechner anmelden, was ansonsten alles funktioniert.

also es läuft so ab, alles völlig normal wie man das immer macht:

• key pair mit ssh-keygen -t ecdsa-sk generieren
• ssh-copy-id -i .ssh/id_ecdsa_sk login@remote

normalerweise kann ich mich jetzt per ssh einloggen, hier wird aber der public key abgewiesen.
relevanter Teil bei ssh -vvvv -i .ssh/id_ecdsa_sk:
debug1: Offering public key: .ssh/yubi ECDSA-SK SHA256:xxxxxxxxxxxxxxxxxxxxxx explicit authenticator debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password,keyboard-interactive

wenn man nach ssh login Fehlern mit "type 51" sucht, dann kommen tausende Posts mit den üblichen Anfängerfehlern, wie falsche Rechte auf dem .ssh Verzeichnis usw.
das trifft hier aber alles nicht zu, "alles richtig konfiguriert" und funktioniert ja seit Ewigkeiten mit "normalen" Keys. Ich kann die o.g. Schritte wiederholen und als einzigen Unterschied den Key-Type von ecdsa-sk auf ecdsa ändern, schon funktioniert alles wie gewohnt. Der pub-key steht auch nach dem ssh-copy-id korrekt in authorized_keys, alles "ganz normal wie es sein soll".

selbst wenn kein zweiter Rechner im Spiel ist, ich kann wie gesagt den Key auch nicht lokal dem agent adden:
~ % ssh-add .ssh/id_ecdsa_sk Could not add identity ".ssh/id_ecdsa_sk": agent refused operation
wogegen die gleiche Operation mit dem "Nicht Security Key"-Key wieder ohne Probleme funktioniert.
~ % ssh-add .ssh/id_ecdsa Identity added: .ssh/id_ecdsa
wobei ich mir nicht sicher bin, ob das überhaupt funktionieren soll/kann? Der private Teil soll ja den Yubikey nicht verlassen. Aber mit einem "resident key" geht es ja auch nicht, s.u.

als "source" habe ich zwei verschiedene MacBook Pro mit Catalina, als "destination" neben diesen beiden auch noch einen MacMini und zwei SuSE Tumbleweed probiert.
zur Sicherheit habe ich auch mal eine Passphrase (zusätzlich) vergeben und auch die "resident key" Funktion probiert, ändert alles nix.
wenn ich z.B. den resident key aus dem Yubikey mit ssh-add -K in den agent übertragen möchte, dann wird zwar der Yubi PIN abgefragt aber anschließend gibt es wieder:
~ % ssh-add -K Enter PIN for authenticator: Unable to add key ECDSA-SK SHA256:xxx