Cannot use --homedir when moving keys to card

Nitrokeys
1

As a try-out to use my nitrokey start, I had generated some 25519 keys using --homedir as argument to gpg in order not to interfere with normal gpg operations.

Generating worked out fine, but when after starting gpg --homedir <somedir> --edit-key, toggle, selecting a key to move and doing addkey I got:

gpg> keytocard
gpg: selecting card failed: No such device
gpg: key operation not possible: No such device

Doing gpg --card-status in another window gave me the expected list of (not yet set) card data.

I moved .gnupg to the side, renamed my to .gnupg and restarted the operation without --homedir as an argument and got the secret keys onto the nitrokey start

This is unexpected, as at least one blog/documentaton out there uses some gnuk based token with --homedir.
What can I check, or make verbose to get more information to know where to report this (here, gpg, gnuk)?

My ~/.gnupg is a link to another directory xxx/yyy

gpg --card-status: works ok
gpg --homedir ~/.gnupg --card-status: works ok
gpg --homedir ~/xxx/yyy --card-status: gives "OpenPGP card not available: No such device"

I have not downloaded the sources of gnupg yet, if necesary I can. I do want to start using the card for real in the near future.

I can download and compile gnupg if that helps, (I have been using Unix since 1984)

Linux: Solus 4.1

2

Hi @avdn!

My initial guess was, that current homedir is having opened socket file to the gpg-agent, and another gpg instance could not connect to it with changed homedir. Your experiment with renaming the homedir has confused me, but perhaps this would work anyway.
Could you try closing the gpg-agent before using the changed homedir, and try again?
You can do so by running one of these (or both):

  • gpg-connect-agent /bye;
  • gpgconf --kill gpg-agent?

(taken from https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html)

3

In case you use the scdaemon to connect to your NK, you could add the following inside the

.gnupg/scdaemon.conf

debug-level expert
log-file /path-2-log/scdaemon.log

or you use gpgconf --change-options to enable Debug on Expert Level

4

Yes, this would produce the proper logs, however I am afraid nothing more will be present in them, than mentioned connection error.
@avdn In case of setting the log please remember to remove it later from the configuration, as all the communication is stored raw there, including PINs.

5

Neither gpg-connect-agent /bye nor gpgconf --kill-agent would do anything, but killall gpg-agent does. So

killall gpg-agent ; gpg --homedir ~/testdir --card-status ; killall gpg-agent ; gpg --card-status

gives output of the card twice, and without the killalls, it gives it only once.

After that I reset the card to factory status, remove ~/.gnupg and moved the original back, and then was able to do killall gpg-agent; gpg --homedir ~/testdir --edit-key anthon and move the keys onto the card from the alternative homedir.

So for me this is solved,
thanks

1 Like
6

:flushed: Ups, yes - it is not directly visible, but when you know what you search you code decode the pin … Good point :+1: