Bug 3355

no-touch-required flag is not set by ssh utilities when a key is restored from hardware tokens and defaults to always requiring user presence. Even when ed25519_sk or ecdsa-sk keys are generated with no-touch-required active, the process or restoring the key on another computer or using the key without downloading will result in always requiring touch because the flag is not properly restored.

This incorrect behavior is consistent for ed25519_sk and ecdsa-sk keys. I have tested and replicated the issue with SoloKey or Yubikey hardware tokens.


After looking at the openssh code it seems that the flag below is never properly used when reading or restoring a key from hardware tokens: 

sk-api.h
  #define SSH_SK_USER_PRESENCE_REQD   0x01


Here is lists of steps to fully reproduce the issue:

Step 1. Generate a new ed25519_sk. This new key will be stored in .ssh/id_ed25519_sk. Please note the `no-touch-required` and `resident` parameters on the key generation.

$ ssh-keygen -vvvv -t ed25519-sk -O no-touch-required -O resident -O application=ssh:test

Step 2. Confirm the generated key has `no-touch-required` option enabled with ssh-keygen. In the output below, please note sk_flags 0x20. This is the correct value for a key generated with resident and no-touch-required additional flags.

$ ssh-keygen -v -y -f id_ed25519_sk
sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIF7VJC49NC4UjXCS9H4PhmH5Jfnh+TLKOHfttd9mL3h4AAAACHNzaDp0ZXN0 my@desktop
debug1: sk_application: "ssh:test", sk_flags 0x20


Step 3. Configure the server with to accept the new key by adding it at the end of `.ssh/authorized_keys`; `no-touch-required` option is required on the server.

no-touch-required sk-ecdsa-sha2-nistp256@openssh.com A....


Step 4. Attempt to connect to the server with newly setup key, please note that no-touch-required works as expected, and the key is loaded by default from ssh-agent which has the correct flags. The client will connect to the server without requiring a hardware token touch.

$ ssh -vvvv user@server 


Step 5. Delete the key files from the disk of the client

$ cd .ssh
$ rm id_ed25519_sk
$ rm id_ed25519_sk.pub

Step 6. Clean ssh-agent from any loaded certificates

$ ssh-add -D

Step 7. List the keys loaded by ssh-agent to ensure the key generated at step 1 is no longer available to ssh-agent

$ ssh-add -L

Step 8. Attempt again to connect to the server after removing the key. This should fail because the key is now deleted from disk and memory. At this time the key only exists on the hardware token but not available at all to ssh utilities on the client machine.

$ ssh -vvvv user@server
.... fails to authenticate .....



So far everything works as expected with regards to no-touch-required, however the next few steps will show the problem. There are two ways to reproduce the issue. First attempt will use the keys from memory without downloading them on disk. 


Step 9. Load the key from the hardware token into ssh-agent without downloading the key to disk.

$ ssh-add -K
Enter PIN for authenticator: 
Resident identity added: ED25519-SK SHA256:

Step 10. List the keys loaded by ssh-agent to ensure the key generated at step 1 is now available again to ssh-agent.

$ ssh-add -L

Step 11. Try to connect to the server again, the authentication works but a touch is required because they key was not restored properly from the hardware token. 

$ ssh user@server 
.... touch required .....


Alternatively, here is one more way to reproduce the issue. The first 8 steps are identical, but this time download the file on disk from the hardware token.

Step 9. Download the key files from the hardware token to local disk in .ssh folder

$ cd .ssh
$ ssh-keygen -K
Enter PIN for authenticator: 
You may need to touch your authenticator to authorize key download.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Saved ED25519-SK key ssh:test to id_ed25519_sk_rk_test

Step 10. Rename the downloaded keys to default file names expected by ssh-agent

$ mv id_ed25519_sk_rk_test id_ed25519_sk
$ mv id_ed25519_sk_rk_test.pub id_ed25519_sk.pub

Step 11. Connect to server again, a touch is required because they key was not restored properly from the hardware token. 

$ ssh user@server 
.... touch required .....

Step 12. Review the downloaded key from hardware token to confirm it lost `no-touch-required` flag. In the output below, please note sk_flags 0x21, which means the key lost no-touch-required flag from the initial configuration during the restore process.

$ ssh-keygen -vvvv -y -f id_ed25519_sk
sk-ssh-ed25519@openssh.com AA.......... ssh:test
debug1: sk_application: "ssh:test", sk_flags 0x21



For these tests, I used standard Ubuntu 21.04 installations with no modifications on both server and client. This includes running distribution standard ssh packages.

$ uname -a
Linux 5.11.0-34-generic #36-Ubuntu SMP Thu Aug 26 19:22:09 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ ssh -V
OpenSSH_8.4p1 Ubuntu-5ubuntu1.1, OpenSSL 1.1.1j  16 Feb 2021

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 21.04
Release:	21.04
Codename:	hirsute



For additional details please review this thread: https://github.com/solokeys/solo/issues/374#issuecomment-912943294