I am attempting to ssh onto a CentOS 7.5 machine ( via smart card technology.
Now I can SSH using the master slot's x509 certificate with the matching private key to accomplish this, but this means that I must put the certificate's public key onto every machine that I wish to SSH onto. That is tedious if you ask me.
Therefore I want to use a different public/private, specifically RSA keys, so that I can, at some time in the future, sign them with an RSA Certificate allowing for OpenSSH to trust the RSA Certificate and prevent the need to trust every single smart card's x509 Certificate. But for now I just want to SSH with this RSA key pair from the smart card.

Therefore I began following the typical steps to generate keys and load them onto a smart card.

  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. Placed the output of the above command onto my target CentOS machine.
  7. ssh gofish543@ -I [opensc-pkcs11.so]

With everything appearing to be working, I moved on over to Windows 10 to SSH with PuTTY. This is when everything falls apart. Using PuTTY-CAC for smart card SSH authentication it successfully loads my smart card's information into pageant, but when I go to ssh it fails with the error...

PuTTY terminal presents the following...

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

With the sshd error log showing the following...

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 port 50051 ssh2: RSA SHA256:Eor3aPxtNW6zrxLbq+1tB/urwql1CQB6EM8tFIx31+I^M

The Public, Private key authentication falls apart at the line key_verify: invalid argument. Searching for this problem yields zero applicable results. What can I do to fix this problem?

As a side note, if I disclosed anything in the error logs that I should not have, like a private key or private key information, know that all these machines are on an internal network hosted on a laptop isolated from the internet. And these keys are going to be deleted in a week or two.


I see you are using a Yubico device as a PIV. But on Windows you are using the PUTTY-CAC, and CAPI. This means the Windows 10 builtin PIV code is most likely being used to access the Yubico as a PIV type card. That should work, but it looks the signature returned does not verify. It could also be the Putty CAPI code is not constructing the SSH answer correctly.

looking at the Putty-CAC it is not clear if the code supports SHA256. The original Windows BSP did not, only supporting CALG_SHA1. CALG_SHA_256 was supported later. Microsoft ALG_ID

Putty does have a logging capability that might be helpful. WireShark might also be helpful to see ssh packets being exchanged.

You may want to try using the Putty-CAC PKCS#11 interface and use either the opensc-pkcs11 or Yubico pkcs11 modules.

Upon testing on Windows 10 with Putty-CAC (Client protocol version 2.0; client software version PuTTY_Release_0.70_4) to OpenSSH (Local version string SSH-2.0-OpenSSH_7.7) With a Yubikey 4 with PIV applet. I can get it to work with pkcs11 (opensc-pkcs11.dl) but not with the CAPI. I believe the problem is in Putty-CAC cert-capi.c line 68: if (CryptCreateHash((HCRYPTPROV)hCryptProv, CALG_SHA1, 0, 0, &hHash) != FALSE && I believe the problem is CALG_SHA1 should be CALG_SHA_256As newer OpenSSH do not support sha1 for signatures, but either rsa-sha-256 or rsa_sha-512.

I do not have a good environment setup to rebuild Putty-CAC.

Another good site is https://piv.idmanagement.gov/engineering/ssh/

See bug report at Putty-CAC/Issues/30

After further testing, it was found that removing the Yubico Minidriver package caused things to start working. The driver is not need because Windows 10 has a built in driver for PIV cards or tokens with a PIV applet. The Yubico Minidriver was unable to handle something causing a MessageBox to be displayed, but Putty-CAC did not handle the bad return codes and when ahead and sent a bogus response to SSHD with a bad signature.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.