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: selecting card failed: No such device
gpg: key operation not possible: No such device
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
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
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):
gpgconf --kill gpg-agent?
(taken from https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html)
In case you use the scdaemon to connect to your NK, you could add the following inside the
or you use gpgconf --change-options to enable Debug on Expert Level
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.
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,
Ups, yes - it is not directly visible, but when you know what you search you code decode the pin … Good point