I have two Nitrokeys and wanted to have the second one as a backup. I followed the steps to create the GPG keys manually and transfer them to the Nitrokey(s) which seems to have worked fine. I can now use the backup key to sign files with gpg directly as well.
However, when I try to log in with the second key via SSH, the remote SSH server denies the key because it seems to check the serial number of the OpenPGP keycard. Is this intentional, i.e. will I have to use two distinct SSH keys and insert both in the authorized_keys file? Or did I just do something wrong?
the authorized_keys file should be the very same as the pubkey of the subkey for authentication is the base for this. What happens here is that the gpg of the client has a private key information that points to the other device. You can delete the private keys stubs in the gnupg key ring, import the pubey and do a ‘gpg --card-status’. Afterwards it should be fine again.
Do you understand what I mean? Does this work for you?
Actually, I used the second Nitrokey on a completely new machine but imported the public key into the gpg keyring based on the public key I obtained during the creation of the key on the first nitrokey. So if I understand you correctly, I should have exported the public key off the backup nitrokey instead of reusing the publickey from the first nitrokey - right?
No, I think there is something wrong The pubkey and the authorized_keys does not contain any information about a device serial and shall be the same for both devices.
Did you may have exported the whole key with the private key stubs? Because these stubs are created automatically after connecting the device and starting gnupg on a system which has the pubkey imported. If they already exist, this won’t happen and thus gnupg looks for the other device.
@nitroalex You were right, the problem was client-side. After removing the gpg directory and NOT importing the gpg public key but just editing gpg-agent.conf and gpg.conf everything seems to work as intended. I can log in with the backup key from another machine without touching anything on the remote side.
Many thanks for your hint that led me to the (hopefully proper) solution.
Just for the record, as this is solved already: the X’s should represent the fingerprint ID of the key, but it is indeed only to make the entry more human readable. This part of a authorized_keys is ignored while processing and even can be left empty.
The pubkey and the authorized_keys does not contain any information about a device serial and shall be the same for both devices.