Mailing List Archive

On Montag, 20. November 2023 09:24:32 CET Felix E. Klee wrote:
> $ gpg --list-keys --keyid-format SHORT yubikey@f76.eu
> pub rsa4096/1B6ED589 2023-06-29 [SC]
> 7A0FE73DDB744F0F97341DA71BE349D11B6ED589
> uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
> sub rsa4096/D2E31736 2023-06-29 [E]
> sub rsa4096/FBA5B1E5 2023-11-20 [A]
>
> $ gpg --export-ssh-key FBA5B1E5
> gpg: key "FBA5B1E5" not found: Unusable public key
> gpg: export as ssh key failed: Unusable public key

Try
$ gpg --export-ssh-key FBA5B1E5!
(note the exclamation mark which indicates a subkey to gpg)
or
$ gpg --export-ssh-key 1B6ED589
(which makes gpg export the latest valid subkey which has an authentication
capability)

Regards,
Ingo

On Tue, Nov 21, 2023 at 12:38?AM Ingo Klöcker <kloecker@kde.org> wrote:
> $ gpg --export-ssh-key 1B6ED589

Thanks, this worked! I then added the key on the remote system to:

~/.ssh/authorized_keys

However, I could not log in. SSH reports:

Permission denied (publickey).

I then tried exporting the key using `ssh-add`:

ssh-add -L >~/.ssh/id_rsa.pub

If I add this key to `authorized_keys`, I can log in, after unlocking my
Yubikey with a PIN. Great! Or not, read on.

Now it gets a bit weird: Apparently the key exported by `ssh-add` is not
tied to my authentication key! I noticed this because I replaced the
authentication key. They key exported by `ssh-add` did not change. I can
still log in using that key. So I assume that key is based on the my
signature key `1B6ED589`:

$ gpg --list-keys --keyid-format SHORT yubikey@f76.eu
pub rsa4096/1B6ED589 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
sub rsa4096/D2E31736 2023-06-29 [E]
sub rsa4096/877CC64B 2023-11-22 [A]

Should I better use the authentication key exported by GPG for SSH? But
how to make that work?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Nov 21, 2023 at 12:38?AM Ingo Klöcker <kloecker@kde.org> wrote:
> $ gpg --export-ssh-key 1B6ED589

Thanks, this worked! I then added the key on the remote system to:

~/.ssh/authorized_keys

However, I could not log in. SSH reports:

Permission denied (publickey).

I then tried exporting the key using `ssh-add`:

ssh-add -L >~/.ssh/id_rsa.pub

If I add this key to `authorized_keys`, I can log in, after unlocking my
Yubikey with a PIN. Great! Or not, read on.

Now it gets a bit weird: Apparently the key exported by `ssh-add` is not
tied to my authentication key! I noticed this because I replaced the
authentication key. They key exported by `ssh-add` did not change. I can
still log in using that key. So I assume that key is based on the my
signature key `1B6ED589`:

$ gpg --list-keys --keyid-format SHORT yubikey@f76.eu
pub rsa4096/1B6ED589 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
sub rsa4096/D2E31736 2023-06-29 [E]
sub rsa4096/877CC64B 2023-11-22 [A]

Should I better use the authentication key exported by GPG for SSH? But
how to make that work?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Wed, 22 Nov 2023 19:39, Felix E. Klee said:

> However, I could not log in. SSH reports:
>
> Permission denied (publickey).

You need to make sure that the gpg-agent is running and the
SSH_AUTH_SOCK envvar is set correctly. Here is the snippet from by
~/.bashrc

--8<---------------cut here---------------start------------->8---
# Setup information required by GnuPG and ssh. We use the
# standard socket in GnuPG's homedir, thus there is no need for an
# environment variable. We reset any left over envvar.
# SSH_AGENT_PID should not be set either because it is only used
# to kill ssh-agent (option -k) but we don't want this to kill
# gpg-agent. Because ssh does not know about GnuPG's homedir we
# need to set its envvar to the standard gpg-agent. GPG_TTY needs
# to be set to the current TTY. The extra test is used to avoid
# setting SSH_AUTH_SOCK if gpg-agent has been started with a
# shell on the command line (often used for testing).
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
export GPG_TTY=$(tty)
--8<---------------cut here---------------end--------------->8---

In case you are switching to a different X server etc, you may need to
run

gpg-connect-agent updatestartuptty /bye

once. This will also make sure that the agent is launched.

Although gpg-agent by default creates the socket for the ssh-agent
protocol, some distros have a pecularity that they look into
~/.gnupg/gpg-agent.conf and check whether there is a
"enable-ssh-support" option set. If not they don't set the envvar (as
above) or do their necessary systemd stuff to create the socket.

> I then tried exporting the key using `ssh-add`:
>
> ssh-add -L >~/.ssh/id_rsa.pub

ssh-add should have connected to gpg-agent and exported the ssh public
keys it knows. You don't need to put this into id_rsa.pub. I use

> Now it gets a bit weird: Apparently the key exported by `ssh-add` is not
> tied to my authentication key! I noticed this because I replaced the
> authentication key. They key exported by `ssh-add` did not change. I can

What is in your ~/.gnupg/sshcontrol file? It should list the keygrips
of the keys to be used for ssh.

gpg -k --with-keygrip yubikey@f76.eu

Instead of putting this into sshcontrol you may also put them into the
private-keys-v1.d/<KEYGRIP>.key file with a line:

Use-for-ssh: yes

FWIW, you may also use

Label: My pink token

to have a nicer prompt.

> Should I better use the authentication key exported by GPG for SSH? But
> how to make that work?

gpg --export-ssh-key

Adds a comment with the keyid - is that one correct? Does it match what
you see with

ssh-add -L

(or ssh-add -l)?


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On Wed, Nov 22, 2023 at 8:57?PM Werner Koch <wk@gnupg.org> wrote:
> Here is the snippet from by ~/.bashrc

I have a similar config. Thank you for the detailed explanation!

Only the following line does not work right after autologin (default
with Ubuntu / WSL2), seems like something is not ready yet.

gpg-connect-agent updatestartuptty /bye

> What is in your ~/.gnupg/sshcontrol file?

It’s empty, with only comments at the top. I left it that way, and
proceeded as follows:

> Instead of putting this into sshcontrol you may also put them into the
> private-keys-v1.d/<KEYGRIP>.key file with a line:
>
> Use-for-ssh: yes

I added that to 0E67508AC6866D82ABB95E0B53CF5D18DC48A786.key, which is
my master key. But it still doesn’t work, see below.

Should I add a file with the authentication key instead?

> gpg --export-ssh-key
>
> Adds a comment with the keyid - is that one correct? Does it match what
> you see with
>
> ssh-add -L

Output:

$ gpg -k --with-keygrip yubikey@f76.eu
pub rsa4096 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
Keygrip = 0E67508AC6866D82ABB95E0B53CF5D18DC48A786
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
sub rsa4096 2023-06-29 [E]
Keygrip = 07D6164F019D2EDF59C650992CF93776B2DD17F2
sub rsa4096 2023-11-22 [A]
Keygrip = 9C67E5BBB72EF0BF2625792F8F134CE4FD961FF5
$ gpg --export-ssh-key yubikey@f76.eu
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== openpgp:0x877CC64B
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCpsX4nQnLh3SJDdIDkdX0DFY4c2uFu
6QJRPrXyub32Ae5SX+3rQnhj/7U8PGFG5LbRT8NVHMyxmoXAHda3wZ1Za3mTC8oWUPSz
dIlSgB7HrVNvmP0fvk0b1V9BOkBJrV6RMMNLEssiD9PCiI95z1+uEbxr9tZAJO/lDYnU
jhEK6PykBhQiJISHpWnWmE0qj+84wQ+/cEPJYnt4tgqLuFH+COFGBVuN6DDi6ubbDlCy
693UqQjWSNi1A34JmUKFOw5Kt0It3Qj3nNVdm8/hRiVZ84qPVbF1Vvp0gZ9k1sFg+3O9
LZYo0vZ73gLMx6AjO1A+Cqcef/e6O+aT+CVgINQ6oaDMyKtHkD7caflg8nPrmiVASxTe
nn51W3Uiu1wksrtEH2HCUcLXpMWKNTjjwpUUTSmMy4m069K5SENsjzsMsHiN2cTxdNu5
CufP1Q3XtGI4VCdW5ql0vgZMCPHIuXHLyFpz9scc2I68B8YnoMzzH0CDyLpjudBRlup+
BZD1g2xlCWB9f+43Oy+Ibf5wAW8/gjk5ly6fhQwB712GTHXNKpPl2ymXgtP2v0K48TE7
OsIfR0sBk2LbwuXr2tLB1WYgrNYs8YY83u/HC6RWHskrcIRq75ahcdeTu8Ukdz1VhAdL
sk25F529lMjW0CgshB9xvFxCwFzcGMmHniuMjoFN6Q== cardno:18 698 015
$ ssh-add -l
4096 SHA256:Pun8mwtl04HFOK8Z1LbCRZ/oQLgZDpkgNHU5/E1MM8I cardno:18 69
8 015 (RSA)

As you see, the public keys are different. `ssh-add -L` does not add the
key ID. So I’ve no idea what is going on.

The key exported by `ssh-add -L` works. I get asked for the PIN, the
Yubikey blinks, and then I’m in:

$ ssh user@example.com
[user@example ~]$

The key exported by `gpg --export-ssh-key yubikey@f76.eu` does not work:

$ ssh user@example.com
user@example.com: Permission denied (publickey).

As it works with the key exported with `ssh-add -L`, maybe I should not
complain. However what confuses me is that the output of `ssh-add -L`
does not change after I replaced the authentication subkey.

Can you explain why the output of `ssh-add -L` did not change? Also why
is it not the same as the output from `gpg --export-ssh-key
yubikey@f76.eu`?

(Background: I replaced the authentication subkey because the first time
I added it, I forgot to make a backup of the updated secret key.)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Another convenient way is to use “~/.config/ssh”. This allows different
configurations per host without changing your global environment.

Example:

Host gitlab.com
HostName gitlab.com
User git
IdentityAgent ${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh

Regards
Stephan

On Thu, Nov 23, 2023 at 2:19?PM Stephan Verbücheln via Gnupg-users
<gnupg-users@gnupg.org> wrote:
> Host gitlab.com
> HostName gitlab.com
> User git
> IdentityAgent ${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh

Thanks, that works. Even the variable is expanded.

In addition, I need:

gpg-connect-agent updatestartuptty /bye

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Thu, Nov 23, 2023 at 10:17?AM Felix E. Klee <felix.klee@inka.de>
wrote:
> Can you explain why the output of `ssh-add -L` did not change? Also
> why is it not the same as the output from `gpg --export-ssh-key
> yubikey@f76.eu`?

OK, I may have found the issue:

$ grep -rl Use-for-ssh ~/.gnupg/private-keys-v1.d/*
.gnupg/private-keys-v1.d/0E67508AC6866D82ABB95E0B53CF5D18DC48A786.key

That’s the key grip of the master key:

$ gpg -k --with-keygrip yubikey@f76.eu
pub rsa4096 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
Keygrip = 0E67508AC6866D82ABB95E0B53CF5D18DC48A786
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
sub rsa4096 2023-06-29 [E]
Keygrip = 07D6164F019D2EDF59C650992CF93776B2DD17F2
sub rsa4096 2023-11-22 [A]
Keygrip = 9C67E5BBB72EF0BF2625792F8F134CE4FD961FF5

I don’t remember adding this, but I guess I did, maybe some months ago.
Anyhow, now I removed `Use-for-ssh` from that key.

I then added the keygrip of the authentication key to
`~/.gnupg/sshcontrol`. However, that doesn’t work:

$ ssh-add -l
The agent has no identities.

Only if I add the key grip of the master key to `~/.gnupg/sshcontrol`,
then `ssh-add -l` is happy. But this seems wrong.

I notice that the private key stub of the authentication sub key isn’t
present in `~/.gnupg/private-keys-v1.d`:

$ ls -1 ~/.gnupg/private-keys-v1.d/
07D6164F019D2EDF59C650992CF93776B2DD17F2.key
0E67508AC6866D82ABB95E0B53CF5D18DC48A786.key
250CD54A263D092C462509D83D034E4BAAF73311.key
BB1D7402E4603D0C12512AB235B12FE1F4BD9667.key

*How do I generate the private key stub for the authentication sub key?*

`gpg --card-status` doesn’t do it.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

So `gpg --card-status` imports [SC] and [E], but not [A]:

$ rm ~/.gnupg/private-keys-v1.d/*
$ ls -a1 ~/.gnupg/private-keys-v1.d/
.
..
$ gpg --card-status
[…]
Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3
1736
created ....: 2023-06-29 03:50:43
Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
[…]
sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never
card-no: 0006 18698016
ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never
card-no: 0006 18698016
ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never
$ gpg --list-keys --keyid-format LONG --with-keygrip yubikey@f76.eu
pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
Keygrip = 0E67508AC6866D82ABB95E0B53CF5D18DC48A786
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@[…]>
sub rsa4096/7CC02D68D2E31736 2023-06-29 [E]
Keygrip = 07D6164F019D2EDF59C650992CF93776B2DD17F2
sub rsa4096/32B106F6877CC64B 2023-11-22 [A]
Keygrip = 9C67E5BBB72EF0BF2625792F8F134CE4FD961FF5
$ ls -a1 ~/.gnupg/private-keys-v1.d/
.
..
07D6164F019D2EDF59C650992CF93776B2DD17F2.key
0E67508AC6866D82ABB95E0B53CF5D18DC48A786.key

To me it looks like [A] is on the Yubikey, as it should.

*But how do I get the private key stub for [A] imported?*

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mittwoch, 29. November 2023 03:52:36 CET Felix E. Klee wrote:
> So `gpg --card-status` imports [SC] and [E], but not [A]:
>
> $ rm ~/.gnupg/private-keys-v1.d/*
> $ ls -a1 ~/.gnupg/private-keys-v1.d/
> .
> ..
> $ gpg --card-status
> […]
> Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
> D589
> created ....: 2023-06-29 03:50:43
> Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3
> 1736
> created ....: 2023-06-29 03:50:43
> Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
> D589
> created ....: 2023-06-29 03:50:43
> […]
> sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never
> card-no: 0006 18698016
> ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never
> card-no: 0006 18698016
> ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never
> $ gpg --list-keys --keyid-format LONG --with-keygrip yubikey@f76.eu
> pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC]
> 7A0FE73DDB744F0F97341DA71BE349D11B6ED589
> Keygrip = 0E67508AC6866D82ABB95E0B53CF5D18DC48A786
> uid [ultimate] Felix E. Klee (YubiKey) <yubikey@[…]>
> sub rsa4096/7CC02D68D2E31736 2023-06-29 [E]
> Keygrip = 07D6164F019D2EDF59C650992CF93776B2DD17F2
> sub rsa4096/32B106F6877CC64B 2023-11-22 [A]
> Keygrip = 9C67E5BBB72EF0BF2625792F8F134CE4FD961FF5
> $ ls -a1 ~/.gnupg/private-keys-v1.d/
> .
> ..
> 07D6164F019D2EDF59C650992CF93776B2DD17F2.key
> 0E67508AC6866D82ABB95E0B53CF5D18DC48A786.key
>
> To me it looks like [A] is on the Yubikey, as it should.
>
> *But how do I get the private key stub for [A] imported?*

If you compare the information for Signature key and Authentication key you'll
notice that they are identical. Further, if you compare the information for
Authentication key and the A subkey of you'll see that the key ID of the A
subkey doesn't match the fingerprint of the Authentication key (which is
logical because the Authentication key is identical to the SC key.

Hint: Add --with-fingerprint (maybe twice) to --list-keys to see the
fingerprints of the subkeys.

I don't know how you did it, but it looks like you have overwritten the
Authentication key on your Yubikey with the SC key. Or your Yubikey or gpg is
seriously broken.

Regards,
Ingo

Thanks for pointing out that the signature key and the authentication
keys are identical:

$ gpg --card-status
[…]
Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3
1736
created ....: 2023-06-29 03:50:43
Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
[…]
sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never

At the same time, the key IDs are different:

$ gpg --list-keys --keyid-format LONG yubikey@f76.eu
pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
sub rsa4096/7CC02D68D2E31736 2023-06-29 [E]
sub rsa4096/32B106F6877CC64B 2023-11-22 [A]

How does that go together?

I thought the long key ID is the last 16 characters of the fingerprint.
And the fingerprint is a 40 character hash of the public (or private?)
key.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Thanks for pointing out that the signature key and the authentication
keys are identical:

$ gpg --card-status
[…]
Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3
1736
created ....: 2023-06-29 03:50:43
Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
[…]
sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never

At the same time, here the key IDs are different:

$ gpg --list-keys --keyid-format LONG yubikey@f76.eu
pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC]
7A0FE73DDB744F0F97341DA71BE349D11B6ED589
uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
sub rsa4096/7CC02D68D2E31736 2023-06-29 [E]
sub rsa4096/32B106F6877CC64B 2023-11-22 [A]

How does that go together?

I thought the long key ID is the last 16 characters of the fingerprint.
And the fingerprint is a 40 character hash of the public (or private?)
key.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mittwoch, 27. Dezember 2023 13:40:40 CET Felix E. Klee wrote:
> Thanks for pointing out that the signature key and the authentication
> keys are identical:
>
> $ gpg --card-status
[...]
> Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
> D589
> created ....: 2023-06-29 03:50:43

-> Apparently created on the same day as the other keys on the card.

[...]
> ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never

-> Apparently created about 5 months later. Also note that "ssb#" indicates
that this is a stub key, i.e. the secret key doesn't exist on disk (or on
card).

> At the same time, here the key IDs are different:
>
> $ gpg --list-keys --keyid-format LONG yubikey@f76.eu
> pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC]
> 7A0FE73DDB744F0F97341DA71BE349D11B6ED589
> uid [ultimate] Felix E. Klee (YubiKey) <yubikey@f76.eu>
> sub rsa4096/7CC02D68D2E31736 2023-06-29 [E]
> sub rsa4096/32B106F6877CC64B 2023-11-22 [A]
>
> How does that go together?

It doesn't. The authentication key on the card is different from the key on
disk (or rather "not on disk" because you lack the secret key of the
authentication key registered in your keyring).

Regards,
Ingo

Thanks, Ingo!

Looking at my log, I realize that I indeed uploaded the primary key when
I did `keytocard`. I did not do `key 2` to select the authentication sub
key. Instead I was assuming that GnuPG does automatically select the
right sub key. There was a warning about moving the primary key, which I
ignored.

Today I fixed that, and now all works consistently:

$ gpg --card-status
[…]
Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3
1736
created ....: 2023-06-29 03:50:43
Authentication key: 9DFF AD98 566A 604F 7290 7C24 32B1 06F6 877C
C64B
created ....: 2023-11-22 15:14:14
General key info..: pub rsa4096/1BE349D11B6ED589 2023-06-29 Felix
E. Klee (YubiKey) <yubikey@f76.eu>
sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb> rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never
card-no: 0006 18698015
$ gpg --export-ssh-key yubikey
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== openpgp:0x877CC64B
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== cardno:18 698 015
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== (none)

Weird only is that `ssh-add -L` outputs the key twice.

Logging in via SSH with the authentication sub key now works as
expected, all smooth.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Thanks, Ingo!

Looking at my log, I realize that I indeed uploaded the primary key when
I did `keytocard`. I did not do `key 2` to select the authentication sub
key. Instead I was assuming that GnuPG does automatically select the
right sub key. There was a warning about moving the primary key, which I
ignored.

Today I fixed that, and now all works consistently:

$ gpg --card-status
[…]
Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E
D589
created ....: 2023-06-29 03:50:43
Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3
1736
created ....: 2023-06-29 03:50:43
Authentication key: 9DFF AD98 566A 604F 7290 7C24 32B1 06F6 877C
C64B
created ....: 2023-11-22 15:14:14
General key info..: pub rsa4096/1BE349D11B6ED589 2023-06-29 Felix
E. Klee (YubiKey) <yubikey@f76.eu>
sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never
card-no: 0006 18698015
ssb> rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never
card-no: 0006 18698015
$ gpg --export-ssh-key yubikey
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== openpgp:0x877CC64B
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== cardno:18 698 015
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== (none)

Weird only is that `ssh-add -L` outputs the key twice.

Logging in via SSH with the authentication sub key now works as
expected, all smooth.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, Nov 24, 2023 at 9:09?AM Felix E. Klee <felix.klee@inka.de> wrote:
> In addition, I need:
>
> gpg-connect-agent updatestartuptty /bye

or otherwise, I get no PIN entry dialog / prompt

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, 5 Jan 2024 10:07, Felix E. Klee said:

>> gpg-connect-agent updatestartuptty /bye
>
> or otherwise, I get no PIN entry dialog / prompt

That is right. The ssh-agent protocol has no means to tell the
ssh-agent or gpg-agent some important environment cariabales, like the
current tty or DISPLAY. I can't remember what ssh-askpass (?) works but
for GnUPG, gpg-agent uses the tty/display from where it was launched if
it does not know anything else

updatestartuptty tells gpg-agent that it should assume that the
tty/display whenre gpg-connect-agent was run should be the new default.

Fixing this in the ssh-agent protocol would be easy and I actually
implemented this but did not found the time to keep on nagging them to
include my patch to pass arbitrary envvars over the ssh-agent protocol.

The gnupg part has long been implemented:
https://dev.gnupg.org/rG224e26cf7b67f22bb0140133eac6b4ad24f3b1b7 and
somewhere on the openssh ML one should find my patch.

I am so used to run the updatestartuptty that I don't even think about
this. It is the first thing I do when I ssh into my laptop.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On Fri, Jan 5, 2024 at 2:43?PM Werner Koch <wk@gnupg.org> wrote:
> That is right. The ssh-agent protocol has no means to tell the
> ssh-agent or gpg-agent some important environment cariabales, like the
> current tty or DISPLAY.

Interesting, thanks for the look behind the scenes!

> I am so used to run the updatestartuptty that I don't even think about
> this. It is the first thing I do when I ssh into my laptop.

I have to do it twice, though, until it works. In my `~/.bashrc` I have:

gpg-connect-agent updatestartuptty /bye

Right after logging in (auto login on Ubuntu / WSL 2), I get:

gpg-connect-agent: no running gpg-agent - starting
'/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established

That looks good, but somehow it doesn’t work:

$ ssh some_server
sign_and_send_pubkey: signing failed for RSA "cardno:18 698 015"
from agent: agent refused operation
sign_and_send_pubkey: signing failed for RSA "(none)" from agent:
agent refused operation
felix@some_server: Permission denied (publickey).

After starting `tmux`, which runs `gpg-connect-agent` again, everything
works fine. I get the PIN entry dialog, and I can connect by SSH.

This is a non-issue, not really worth debugging. I start `tmux` every
time anyhow.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users