SSH-Keygen - Key enrollment failed: invalid format

[jtitosky]

Device: Ledger Nano X V2.0 Fido-U2F Ledger App Version: 1.3.1 Secure Element Version: 2.2.3 Microcontroller: 2.3.0 Bootloader: 1.16

Attempting to use this Ledger App with SSH-Keygen, but receiving the error "Key enrollment failed: invalid format". It is working without issue with a Yubikey device.

This is the verbose output of ssh-keygen:

ssh-keygen -vvvv -t ed25519-sk
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug3: start_helper: started pid=13770
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/libexec/openssh/ssh-sk-helper 
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x01, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_enroll: using device /dev/hidraw1
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_INVALID_ARGUMENT
debug1: sshsk_enroll: provider "internal" failure -1
debug1: ssh-sk-helper: Enrollment failed: invalid format
debug1: main: reply len 8
debug3: ssh_msg_send: type 5
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=13770
Key enrollment failed: invalid format

It does seem to work with the weaker "ecdsa-sk", but unless I'm mistaken, Ledgers contain support for ed25519.

[xchapron-ledger]

Hello @jtitosky ,

You are trying it with the Ledger app FIDO U2F which supports U2F/CTAP1 (aka FIDO1) which doesn't support ed25519. But it works with the Ledger app Security Key which supports FIDO2/CTAP2. You can find the app on the Ledger Live store and the git repository is here: https://github.com/LedgerHQ/app-security-key/

[jtitosky]

Thanks very much for the clarification!

For anyone that stumbles across this, keys created with ssh-keygen -t ed25519-sk in conjunction with the security-key app xchapron has mentioned can be restored with the recovery mneumonic. So long as you still have the id file (which is generated with the ssh-keygen command) available to your ssh client.

[xchapron-ledger]

For anyone that stumbles across this, keys created with ssh-keygen -t ed25519-sk in conjunction with the security-key app xchapron has mentioned can be restored with the recovery mneumonic. So long as you still have the id file (which is generated with the ssh-keygen command) available to your ssh client.

Exact, just make sure not to use the resident key option -O resident as this will mess up with recovery from seed. Also you can consider using -O application=ssh:CustomInput to have a better text on screen.

[wget]

Thanks very much for the clarification!

For anyone that stumbles across this, keys created with ssh-keygen -t ed25519-sk in conjunction with the security-key app xchapron has mentioned can be restored with the recovery mneumonic. So long as you still have the id file (which is generated with the ssh-keygen command) available to your ssh client.

Wow. I think this /needs/ to be stored somewhere into the official documentation. I stumbled upon this problem and even asked that question a few months ago on the Discord without much results (the support team and myself where not eager to do the test, fearing to lose their key :sweat_smile: )

Glad we now have a concrete answer :pray: :partying_face:

[jtitosky]

Thanks very much for the clarification! For anyone that stumbles across this, keys created with ssh-keygen -t ed25519-sk in conjunction with the security-key app xchapron has mentioned can be restored with the recovery mneumonic. So long as you still have the id file (which is generated with the ssh-keygen command) available to your ssh client.

Wow. I think this /needs/ to be stored somewhere into the official documentation. I stumbled upon this problem and even asked that question a few months ago on the Discord without much results (the support team and myself where not eager to do the test, fearing to lose their key 😅 )

Glad we now have a concrete answer 🙏 🥳

I've tested wiping a ledger and restoring from mneumonic and was still able to use the ssh keys. So I can confirm it does work for sure.

Someone correct me if I'm wrong, but just note that this is NOT the case for Fido2 Discoverable Credentials (Resident Keys). Which would be because the metadata is stored in memory rather than generated from a mneumonic. You can get restorable credentials using the Fido U2F app, since the metadata for those are stored server-side with the service you're logging into.

[xchapron-ledger]

Hello, You can found some information here: https://www.ledger.com/blog/strengthen-the-security-of-your-accounts-with-webauthn Mostly in the "limitation part".

As mentioned above:

• FIDO U2F application derive everything from the seed (only server side credential are supported): so no risk to loose everything when restoring from seed only
• Security Key application allow to generate:
  • server-side credential which are only derived from the seed: can be restoring from the seed only
  • Discoverable credentials (residents keys) which are stored on the device memory, and therefore lost when it's memory is wiped : App deletion, App update, Os update.. the seed is not enough to restore the credential.

For this reason, discoverable credential are for now disabled by default in the Security Key application, they can be enabled using a setting. Hopefully at some point a backup and restore mechanism will be implemented to allow having them enabled by default without exposing the user to the risk of losing them.