Smartcard OpenSSH und PuTTY SSH

1307
gofish

Ich versuche, auf einer CentOS 7.5-Maschine (192.168.1.5) mittels Smartcard-Technologie zu sshs.
Jetzt kann ich SSH verwenden, um das x509-Zertifikat des Master-Steckplatzes mit dem dazugehörigen privaten Schlüssel zu verwenden. Dies bedeutet jedoch, dass ich den öffentlichen Schlüssel des Zertifikats auf jeden Computer stecken muss, auf den ich SSH möchte. Das ist langweilig, wenn Sie mich fragen.
Daher möchte ich einen anderen öffentlichen / privaten Schlüssel verwenden, insbesondere RSA-Schlüssel, damit ich sie irgendwann mit einem RSA-Zertifikat signieren kann, das OpenSSH das Vertrauen in das RSA-Zertifikat ermöglicht und verhindert, dass jedem einzelnen Smart vertraut werden muss x509-Zertifikat der Karte. Aber fürs Erste möchte ich einfach mit diesem RSA-Schlüsselpaar von der Chipkarte aus SSH.

Daher begann ich den typischen Schritten zum Generieren von Schlüsseln und zum Laden dieser auf eine Chipkarte.

  1. ssh-keygen -f gofish
  2. ssh-keygen -f gofish.pub -e -m pem
  3. ykman piv import-key 9c gofish
  4. ykman piv generate-certificate 9c gofish.pem -s 'gofish543'
  5. ssh-keygen -D [opensc-pkcs11.so] -e
  6. Platzierte die Ausgabe des obigen Befehls auf meiner CentOS-Zielmaschine.
  7. ssh gofish543@192.168.1.5 -I [opensc-pkcs11.so]

Da alles scheinbar funktioniert, wechselte ich mit PuTTY von Windows 10 zu SSH. Dann fällt alles auseinander. Mit PuTTY-CAC für die Smartcard-SSH-Authentifizierung werden die Informationen meiner Smartcard erfolgreich in pageant geladen, aber wenn ich zu ssh gehe, schlägt der Fehler fehl ...

Das PuTTY-Terminal präsentiert folgende ...

Using username "gofish543". Authenticating with public key "CAPI:5e084cb687f0c54adf8ddd733720db48407d3195" from agent Server refused public-key signature despite accepting key! gofish543@192.168.1.5's password:

Mit dem sshd-Fehlerprotokoll wird Folgendes angezeigt ...

debug1: matching key found: file /home/gofish543/.ssh/authorized_keys, line 1 RSA SHA256:Eor3aPxtNW6zrxLbq+1tB/urwql1CQB6EM8tFIx31+I^M debug1: restore_uid: 0/0^M debug3: mm_answer_keyallowed: key 0x55d310674760 is allowed^M debug3: mm_request_send entering: type 23^M debug3: mm_key_verify entering [preauth]^M debug3: mm_request_send entering: type 24 [preauth]^M debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth]^M debug3: mm_request_receive_expect entering: type 25 [preauth]^M debug3: mm_request_receive entering [preauth]^M debug3: mm_request_receive entering^M debug3: monitor_read: checking request 24^M key_verify: invalid argument^M debug3: mm_answer_keyverify: key 0x55d310674710 signature unverified^M debug3: mm_request_send entering: type 25^M Failed publickey for gofish543 from 192.168.1.3 port 50051 ssh2: RSA SHA256:Eor3aPxtNW6zrxLbq+1tB/urwql1CQB6EM8tFIx31+I^M

Die Authentifizierung des öffentlichen, privaten Schlüssels fällt an der Leitung auseinander key_verify: invalid argument. Die Suche nach diesem Problem führt zu null anwendbaren Ergebnissen. Was kann ich tun, um dieses Problem zu beheben?

Als Randbemerkung: Wenn ich in den Fehlerprotokollen Angaben gemacht habe, über die ich nicht verfügen sollte, wie etwa ein privater Schlüssel oder Informationen zu einem privaten Schlüssel, wissen Sie, dass sich all diese Maschinen in einem internen Netzwerk befinden, das auf einem vom Internet getrennten Laptop gehostet wird. Und diese Schlüssel werden in ein, zwei Wochen gelöscht.

3

1 Antwort auf die Frage

2
Douglas Engert

Ich sehe, dass Sie ein Yubico-Gerät als PIV verwenden. Unter Windows verwenden Sie jedoch den PUTTY-CAC und die CAPI. Dies bedeutet, dass der in Windows 10 integrierte PIV-Code höchstwahrscheinlich für den Zugriff auf den Yubico als PIV-Karte verwendet wird. Das sollte funktionieren, aber es sieht so aus, als würde die zurückgegebene Signatur nicht bestätigen. Es kann auch sein, dass der Putty-CAPI-Code die SSH-Antwort nicht korrekt erstellt.

Wenn Sie den Putty-CAC betrachten, ist nicht klar, ob der Code SHA256 unterstützt. Das ursprüngliche Windows-BSP unterstützte nicht nur CALG_SHA1. CALG_SHA_256 wurde später unterstützt. Microsoft ALG_ID

Putty verfügt über eine Protokollierungsfunktion, die hilfreich sein kann. WireShark kann auch hilfreich sein, um zu sehen, wie ssh-Pakete ausgetauscht werden.

Möglicherweise möchten Sie die Putty-CAC PKCS # 11-Schnittstelle verwenden und entweder die opensc-pkcs11- oder die Yubico pkcs11-Module verwenden.

Beim Testen unter Windows 10 mit Putty-CAC (Client-Protokollversion 2.0; Client-Softwareversion PuTTY_Release_0.70_4) bis OpenSSH (lokale Versionszeichenfolge SSH-2.0-OpenSSH_7.7) mit einem Yubikey 4 mit PIV-Applet. Ich kann es mit pkcs11 (opensc-pkcs11.dl) arbeiten lassen, aber nicht mit der CAPI. Ich glaube, das Problem liegt in Putty-CAC cert-capi.c Zeile 68: if (CryptCreateHash((HCRYPTPROV)hCryptProv, CALG_SHA1, 0, 0, &hHash) != FALSE && Ich glaube, das Problem CALG_SHA1sollte sein. CALG_SHA_256Als neuere OpenSSH unterstützen sha1 nicht für Signaturen, sondern entweder rsa-sha-256 oder rsa_sha-512.

Ich habe keine gute Umgebungseinstellung, um Putty-CAC neu zu erstellen.

Eine weitere gute Site ist https://piv.idmanagement.gov/engineering/ssh/

Siehe Fehlerbericht unter Putty-CAC / Issues / 30

Nach weiteren Tests stellte sich heraus, dass das Entfernen des Yubico Minidriver-Pakets dazu führte, dass die Arbeit anfing. Der Treiber ist nicht erforderlich, da Windows 10 einen integrierten Treiber für PIV-Karten oder -Token mit einem PIV-Applet enthält. Der Yubico Minidriver konnte nicht mit etwas umgehen, was dazu führte, dass eine MessageBox angezeigt wurde, aber Putty-CAC hat die fehlerhaften Rückkehrcodes nicht verarbeitet und im Voraus eine falsche Antwort mit falscher Signatur an SSHD gesendet.

Verwandte Probleme