I ran a loop creating keys with ssh-keygen to see how many fit into a NK3. The loop created fifteen keys, then quit with these messages for the sixteenth key:
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
Key enrollment failed: invalid format
When I try to access the keys with Chrome (chrome://settings/securityKeys, then Sign-in data), touch the NK3, enter the pin and click Continue, the NK3 LED turns red and the NK3 is catatonic. I had to reset the key.
can you please tell which NK3 exactly you are using ? NK3 Mini or NK3 A/C NFC ?
The problem in general is that there is no strict limit to RKs currently as it is not easy to predict how many keys will fit onto the Nitrokey3. So the current approach is to accept the creation of new keys until there is no space left, BUT reading them out should not panic the NK3 (red shining LED is essentially a panic/crash) …
Have you been able to use the NK3 apart from reading out the RKs ?
NK3 C with NFC, first generation (before your supply chain problems started).
Since the stick was catatonic, I took this as kind of a panic I have no problem with a variable limit on keys, but having to reset the stick is something that needs to be fixed. At least now it is kinda documented…
Yes, so far everything works fine. I’m especially impressed on the possible length of the PIN, I gave up at 26 characters and checked that all are compared which indeed they are. I did not check beyond the full alphabet.
Of course, I was not able to get at the private keys, but SSH was able to use them, as it is supposed to.
SSH resident keys work fine with my Debian Bullseye server, using OpenSSH_8.4p1 Debian-5+deb11u1. Client is OpenSSH_8.9p1 Ubuntu-3. Forced verification works.
I’ve also set up the Key for GitHub. Due to the reset, I also checked out their backup procedure