openssh bugs - Oct 2021 - [Bug 3355] New: no-touch-required flag not restored from hardware token

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

            Bug ID: 3355
           Summary: no-touch-required flag not restored from hardware
                    token
           Product: Portable OpenSSH
           Version: 8.4p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: snegrea at gmail.com

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 at openssh.com
AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIF7VJC49NC4UjXCS9H4PhmH5Jfnh+TLKOHfttd9mL3h4AAAACHNzaDp0ZXN0
my at 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 at 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 at 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 at 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 at 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 at 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 at 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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I don't think the FIDO standard offers any way for the security key to
communicate whether a resident key requires touch back to the
application. Typically in the web model this information is held and
communicated to the client from the RP, but there is no analogue for
this in the SSH setting.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #2 from snegrea at gmail.com ---
Thanks for the insight about the FIDO standard. Could you please give
me a pointer about where to find documentation regarding the standard?
I did not have much luck searching.

Is there a way to set no-touch-required flag after the key is
downloaded from the hardware? The main issue is that while the key
is/was properly configured in the hardware token there is no way to
correctly set this flag on the local disk files in the event of a
restore operation. ssh relies local disk files to pick up this flag so
if there is another way to correctly set this flag, then this becomes a
user configuration issue.

This particular issue makes it impossible to consistently use a
hardware token on multiple computers because the flags are not
correctly restored.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
(In reply to snegrea from comment #2)
> Thanks for the insight about the FIDO standard. Could you please
> give me a pointer about where to find documentation regarding the
> standard? I did not have much luck searching.
They are at https://fidoalliance.org/specifications/download/ but
aren't especially easy to read unfortunately.
> Is there a way to set no-touch-required flag after the key is
> downloaded from the hardware? The main issue is that while the key
> is/was properly configured in the hardware token there is no way to
> correctly set this flag on the local disk files in the event of a
> restore operation. ssh relies local disk files to pick up this flag
> so if there is another way to correctly set this flag, then this
> becomes a user configuration issue.
Not at present. I'll think about how we could add this...

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

Nikolas Sch?ller <nikolas at bobbie.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nikolas at bobbie.de

--- Comment #4 from Nikolas Sch?ller <nikolas at bobbie.de> ---
I can replicate this issue if using a passphrase for the new key.
Otherwise it works fine.

Device type: YubiKey 5 NFC
Firmware version: 5.2.4

$ uname -a
Linux [...] 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64
GNU/Linux

$ ssh -v
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #5 from nikolas at bobbie.de ---
(In reply to nikolas from comment #4)
> I can replicate this issue if using a passphrase for the new key.
> Otherwise it works fine.
> 
> Device type: YubiKey 5 NFC
> Firmware version: 5.2.4
> 
> $ uname -a
> Linux [...] 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08)
> x86_64 GNU/Linux
> 
> $ ssh -v
> OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
> 
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:    Debian GNU/Linux 11 (bullseye)
> Release:        11
> Codename:       bullseye
Please excuse me, I have been wrong. Passphrases don't affect this bug.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

mindrot at wombat.eu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at wombat.eu.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

4xoc <mindrot at 4xoc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at 4xoc.com

--- Comment #6 from 4xoc <mindrot at 4xoc.com> ---
Has there been any progress on this issue by any chance, the issue
still exists in OpenSSH_9.2p1. If there's still no clear idea forward I
would suggest adding the `-O no-touch-required` option to the `ssh-add
-K` and `ssh-keygen -K` commands when loading keys from a fido token.
This way the action to use no touch on restore is conscious but easily
automated with for example shell aliases.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Created attachment 3682
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3682&action=edit
ssh-keygen: accept -O no-touch-required with -K

This (should - it's untested) allow manually clearing the
touch-required flag when downloading resident keys from a FIDO token.

E.g.

ssh-keygen -K -O no-touch-required

Please give it a try

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #8 from 4xoc <mindrot at 4xoc.com> ---
Fantastic, I can confirm that this patch works on latest HEAD. Would
the same change be easily applicable to ssh-add too?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
Created attachment 3683
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3683&action=edit
ssh-add: support -O no-touch-required with -K

Here's the same for ssh-add.

I guess the next thing people will ask for is selecting which keys are
downloaded or added, since they might not want to apply
no-touch-required to all of them. I guess adding support for the userand
application= strings to the respective download options is next.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

--- Comment #10 from 4xoc <mindrot at 4xoc.com> ---
ssh-add works fine as well, great stuff

I agree on having some flexibility on selecting what keys should be
with additional features. However, ideally this should be based on the
fido credential id in my opinion. At least I believe that application
and user can be identical for multiple keys and thus would affect more
than one key. This would not allow more granular selection of one
specific key. Credential id should however be unique (at least from
what I can see on my Yubikey)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

daemonhorn at nullcore.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daemonhorn at nullcore.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

Danny Navarro <j at dannynavarro.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |j at dannynavarro.net

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

Merritt Krakowitzer <merritt at krakowitzer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |merritt at krakowitzer.com

--- Comment #11 from Merritt Krakowitzer <merritt at krakowitzer.com> ---
Is there any possibility for this to be included in newer releases?

I have managed to patch 9.2p1 and verified that both ssh-add and
ssh-keygen work as described. 

However the patches are no longer valid on the latest release (9.7p1).

Thanks in advance if this is possible. I would prefer to be able rely
on an upstream release rather than roll my own.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

Dominik Rimpf <dev at drimpf.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dev at drimpf.de

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.