Re: SSH CA + gpg-agent + gnuk => error
Francois Gervais via Gnupg-users wrote: > Would the SIGCONT be the source of my problem? No, not at all. It's completely normal. You need to locate the place where it fails. * * * FYI, we have a ticket for signing SSH CA by Gnuk Token. https://dev.gnupg.org/T5041 This problem is... (for me) because of bad design of digital signature for SSH CA. If it's not larger, Gnuk 1.2.16 works. I think it is possibly related to your issue. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH CA + gpg-agent + gnuk => error
I'm trying to follow up on a previous thread as I'm affected by the same issue. https://www.mail-archive.com/gnupg-users@gnupg.org/msg37567.html I'm seeking some help in order to track down the issue. Here's my current gpg-agent settings: fgervais@fgervais-System-Product-Name:~$ cat .gnupg/gpg-agent.conf enable-ssh-support debug-level guru debug-all verbose log-file /home/fgervais/gpg-agent-log I'm not getting much more info than previously posted. Basically everything is fine until 2020-09-29 12:49:17 gpg-agent[16002] smartcard signing failed: General error 2020-09-29 12:49:17 gpg-agent[16002] ssh sign request failed: General error I don't mind posting the whole thing if someone can confirm that it is safe to share. What could be my next step in order to track this issue? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH CA + gpg-agent + gnuk => error
I have more, I changed the scdaemon configuration: fgervais@fgervais-System-Product-Name:~$ cat .gnupg/scdaemon.conf verbose debug 2048 log-file /home/fgervais/scdaemon.log and I got the following: 2020-09-29 14:01:04 scdaemon[23361] DBG: dump: 2020-09-29 14:01:04 scdaemon[23361] Version-2+ .: yes 2020-09-29 14:01:04 scdaemon[23361] Extcap-v3 ..: no 2020-09-29 14:01:04 scdaemon[23361] Button .: yes 2020-09-29 14:01:04 scdaemon[23361] SM-Support .: no 2020-09-29 14:01:04 scdaemon[23361] Get-Challenge ..: yes (32 bytes max) 2020-09-29 14:01:04 scdaemon[23361] Key-Import .: yes 2020-09-29 14:01:04 scdaemon[23361] Change-Force-PW1: yes 2020-09-29 14:01:04 scdaemon[23361] Private-DOs : no 2020-09-29 14:01:04 scdaemon[23361] Algo-Attr-Change: yes 2020-09-29 14:01:04 scdaemon[23361] Symmetric Crypto: no 2020-09-29 14:01:04 scdaemon[23361] KDF-Support : yes 2020-09-29 14:01:04 scdaemon[23361] Max-Cert3-Len ..: 2048 2020-09-29 14:01:04 scdaemon[23361] Cmd-Chaining ...: yes 2020-09-29 14:01:04 scdaemon[23361] Ext-Lc-Le ..: no 2020-09-29 14:01:04 scdaemon[23361] Status-Indicator: 05 2020-09-29 14:01:04 scdaemon[23361] GnuPG-No-Sync ..: no 2020-09-29 14:01:04 scdaemon[23361] GnuPG-Def-PW2 ..: no 2020-09-29 14:01:04 scdaemon[23361] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2020-09-29 14:01:04 scdaemon[23361] DBG: raw apdu: 00 CA 00 6E 00 2020-09-29 14:01:04 scdaemon[23361] DBG: response: sw=9000 datalen=248 2020-09-29 14:01:04 scdaemon[23361] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 FF FE 43 11 22 34 00 00 5F 52 0A 00 31 84 73 80 01 80 05 90 00 73 81 D0 C0 0A 75 00 00 20 08 00 00 FF 01 00 C1 0A 16 2B 06 01 04 01 DA 47 0F 01 C2 0B 12 2B 06 01 04 01 97 55 01 05 01 C3 0A 16 2B 06 01 04 01 DA 47 0F 01 C4 07 01 7F 7F 7F 03 03 03 C5 3C D2 8D 3D 5D 50 9C 5B 11 25 D7 4A 2A 21 E3 A1 80 DE D9 53 6A 22 15 82 13 6A D6 E2 39 EA 82 D4 DC 16 9E E2 25 75 32 7A 51 6E E2 CD 7D AF D2 D1 F4 D1 C8 69 0A 34 D5 63 14 D4 84 07 11 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F 65 5D 93 5F 65 5E 1D 5F 65 5E 42 D6 02 00 20 D7 02 00 20 D8 02 00 20 7F 74 03 81 01 20 2020-09-29 14:01:04 scdaemon[23361] Key-Attr-sign ..: ECC, curve=Ed25519 (eddsa) 2020-09-29 14:01:04 scdaemon[23361] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2020-09-29 14:01:04 scdaemon[23361] DBG: raw apdu: 00 CA 00 6E 00 2020-09-29 14:01:04 scdaemon[23361] DBG: response: sw=9000 datalen=248 2020-09-29 14:01:04 scdaemon[23361] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 FF FE 43 11 22 34 00 00 5F 52 0A 00 31 84 73 80 01 80 05 90 00 73 81 D0 C0 0A 75 00 00 20 08 00 00 FF 01 00 C1 0A 16 2B 06 01 04 01 DA 47 0F 01 C2 0B 12 2B 06 01 04 01 97 55 01 05 01 C3 0A 16 2B 06 01 04 01 DA 47 0F 01 C4 07 01 7F 7F 7F 03 03 03 C5 3C D2 8D 3D 5D 50 9C 5B 11 25 D7 4A 2A 21 E3 A1 80 DE D9 53 6A 22 15 82 13 6A D6 E2 39 EA 82 D4 DC 16 9E E2 25 75 32 7A 51 6E E2 CD 7D AF D2 D1 F4 D1 C8 69 0A 34 D5 63 14 D4 84 07 11 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F 65 5D 93 5F 65 5E 1D 5F 65 5E 42 D6 02 00 20 D7 02 00 20 D8 02 00 20 7F 74 03 81 01 20 2020-09-29 14:01:04 scdaemon[23361] Key-Attr-encr ..: ECC, curve=Curve25519 (djb-tweak) 2020-09-29 14:01:04 scdaemon[23361] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2020-09-29 14:01:04 scdaemon[23361] DBG: raw apdu: 00 CA 00 6E 00 2020-09-29 14:01:04 scdaemon[23361] DBG: response: sw=9000 datalen=248 2020-09-29 14:01:04 scdaemon[23361] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 FF FE 43 11 22 34 00 00 5F 52 0A 00 31 84 73 80 01 80 05 90 00 73 81 D0 C0 0A 75 00 00 20 08 00 00 FF 01 00 C1 0A 16 2B 06 01 04 01 DA 47 0F 01 C2 0B 12 2B 06 01 04 01 97 55 01 05 01 C3 0A 16 2B 06 01 04 01 DA 47 0F 01 C4 07 01 7F 7F 7F 03 03 03 C5 3C D2 8D 3D 5D 50 9C 5B 11 25 D7 4A 2A 21 E3 A1 80 DE D9 53 6A 22 15 82 13 6A D6 E2 39 EA 82 D4 DC 16 9E E2 25 75 32 7A 51 6E E2 CD 7D AF D2 D1 F4 D1 C8 69 0A 34 D5 63 14 D4 84 07 11 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F 65 5D 93 5F 65 5E 1D 5F 65 5E 42 D6 02 00 20 D7 02 00 20 D8 02 00 20 7F 74 03 81 01 20 2020-09-29 14:01:04 scdaemon[23361] Key-Attr-auth ..: ECC, curve=Ed25519 (eddsa) 2020-09-29 14:01:04 scdaemon[23361] DBG: SIGCONT received - breaking select 2020-09-29 14:01:04 scdaemon[23361] sending signal 12 to client 23359 2020-09-29 14:01:04 scdaemon[23361] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0 2020-09-29 14:01:04 scdaemon[23361] DBG: raw apdu: 00 47 81 00 02 A4 00 00 2020-09-29 14:01:04 scdaemon[23361] DBG: response: sw=9000 datalen=37 2020-09-29 14:01:04
Re: SSH CA + gpg-agent + gnuk => error
Brennecke, Simon wrote: > I have a question regarding the interaction of SSH with gpg-agent > (and possibly also gnuk). [...] > So I generated a new ECC key in gnuk, imported the public keys in gpg. > Added the keygrip everything to "~/.gnupg/sshcontrol" Just FYI, for smartcard, adding a keygrip in sshcontrol is not needed, if it is OK for your gpg-agent to just fail for signing request when smartcard is not available. > "ssh-add -L" shows me the key. > I signed it with the CA. > ssh tries to use the key... > ... and this is where the error pops up. > > ssh tells me: > sign_and_send_pubkey: signing failed: agent refused operation > > and gpg-agent tells me: > gpg-agent[21629]: ssh request handler for sign_request (13) started > gpg-agent[21629]: DBG: detected card with S/N D276000124010200FFFE43032234 > gpg-agent[21629]: smartcard signing failed: General error > gpg-agent[21629]: ssh sign request failed: General error I don't think it is related to OpenSSH certificate. For some reason, possibly a bug, smartcard singing failed. You can configure .gnupg/scdaemon.conf with something like: debug-level guru debug-all verbose log-file /run/user/1000/scd.log to see what's going on. * * * Here is another information, related. OpenSSH certificate authentication doesn't work well with gpg-agent (yet). Ideally, OpenSSH certificate should be under control of gpg-agent. For detail, you can see: https://dev.gnupg.org/T1756 https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031479.html Protocol-wise, for gpg-agent, it is expected that the ssh does: * ssh askes ssh-agent (in our case, gpg-agent) to get OpenSSH certificate by REQUEST_IDENTITIES command * (only after) REQUEST_IDENTITIES command, ssh askes ssh-agent challenge-response by SIGN_REQUEST command But the first part does not occur by current OpenSSH client. The client by itself answers back to the server using the certificate on disk (under .ssh/), without asking ssh-agent. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
SSH CA + gpg-agent + gnuk => error
Hi guys, I have a question regarding the interaction of SSH with gpg-agent (and possibly also gnuk). I started out with the following setup: Every admin has his own ssh private key. All private keys are signed with an SSH CA. The server trust the CA, and thus the admins can login. No need to deploy individual keys, only the CA. Great. Now I wanted to store my private key in gnuk to protect it better. So I generated a new ECC key in gnuk, imported the public keys in gpg. Added the keygrip everything to "~/.gnupg/sshcontrol" "ssh-add -L" shows me the key. I signed it with the CA. ssh tries to use the key... ... and this is where the error pops up. ssh tells me: sign_and_send_pubkey: signing failed: agent refused operation and gpg-agent tells me: gpg-agent[21629]: ssh request handler for sign_request (13) started gpg-agent[21629]: DBG: detected card with S/N D276000124010200FFFE43032234 gpg-agent[21629]: smartcard signing failed: General error gpg-agent[21629]: ssh sign request failed: General error Without the CA (when I deploy my key explicitly on the server) it works fine. I'm not sure where the issue comes from. >From my understanding of ssh's internal workings, gnupg should not even get >informed that now a CA is used. Out of curiosity I tried the hole thing again, but without gnuk. Instead I stored the private key in gpg. And that works even with the SSH CA. Any ideas? Am I missing something obvious here? Or could this be a bug? Thanks & Regards Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users