SSH FIDO2 Support - Improving authentication security options

Feature requests
1

As described here SSH FIDO2 support

Supporting SSH FIDO2 requires the following to be set on the SSH server. This option isn’t currently exposed via the Vyos CLI.

PubkeyAuthOptions verify-required

Additionally, it would be good to confirm that VyOS supports the FIDO2 verification option even if it were exposed. I can’t see why not, as this should be handled natively through the SSH server.

2

Any feature must be created on forge https://vyos.dev/
There is no other way to add new features.

3

Done

⚓ T7483 SSH FIDO2 Support

1 Like
4

My account is currently disabled on vyos.dev. Here’s what I outlined for my setup process and the changes that are needed for the feature. I’ve mostly only accounted for changes needed in the vyos-1x project

Setup

  • fork repository
  • build live ISO image that includes packages:
    • vim/emacs along with vyos repos
    • maybe use sshfs here (from server back to local, run dev commands on server)
  • add edits, watchexec to run make, run tests when build completes
  • test against the running live ISO
  • build an iso, test live with various configs
  • run smoke tests

Feature

  • ensure dependencies satisfied for yubico fido2
  • add a node to be compatible with ConfigTree
    • update *.xml.in for interface_definitions
  • add validation logic to ./src/conf_mode/service_ssh.py
  • update .data/templates/ssh/sshd_config.j2 in vyos-1x (and elsewhere?)
    • SecurityKeyProvider: either set in the same jinja conditional or
    • PubkeyAuthOptions: none,touch-required,verify-required
  • docs should indicate that ed25519-sk is set first in user’s configuration or that key is provided with ssh -i $key
  • ensure other sshd configurations aren’t affected
    • there could be potential conflicts. if they result in lockout, it’s kind of a problem since it probably will break updates
5

You created a new account, and it was disabled?

6

yes… well i did a password reset. the username is dcunit3d, but i think it was inactive for some time.

7

I believe there are more changes than what I listed above.

While the sshd_config manpage indicates that the PubkeyAuthOptions only affect resident-key authentication, there’s maybe a chance of issues preventing new connections.

Neither the touch-required or verify-required options have any effect for other, non-FIDO, public key types.

I can’t say, but I’m being cautious, as I’ve never used these FIDO2-based keys (only PIV and gpg-agent)

The main unknown for me is determining which other projects besides vyos-1x require changes. I think this is mentioned in the docs, but I’ve been focused on other areas.

8

i just enabled it, you need to verify your mail, if the mail is not verified, it’s treated as a spam account (we have a lot of such registrations) and it will be disabled and deleted eventually

1 Like
9

k, i had hit a 400 error when I clicked it, but it just went through fine this time

10

Correct me if I’m wrong, but as far as I understand this, you don’t actually need this server option to be set, to make it verify on login. According to the man page, the option simply forces whatever is specified for “_sk” type keys. The default behavior is to follow whatever the key itself requires (depends on how it was created), or whatever is configured along the key in the authorized_keys file.

So exposing this option in vyos would simply allow to force verify/touch for all “_sk” keys, regardless on what their authorized_keys entry says. Is that the use-case you are looking for, or do you just want to be able to use FIDO2 backed login?

We were somewhat naively assuming FIDO2 support ~a year ago when setting up our infa, but back then it wasn’t working as AFAIR either the vyos middleware refusing the key type as invalid or the provided version/build of OpenSSH was not supporting it yet. We didn’t try again since then, would be great to finally have this!

11

Hi there - I read those man pages slightly differently, as it states that those options are only applicable for FIDO authenticator algorithms (ecdsa-sk and ed25519-sk). The verify-required option must still be set, but it won’t have any impact on non-sk keys.

12

I just had a talk with a collegue as we’re using sk backed auth on our phyiscal servers, where this option was not set, yet keys require you to touch/verify accordingly. If you have any linux server around, you could quickly try how it behaves there, but after reading the docs and the talk, I’m pretty convinced it works out of the box. :wink:

1 Like
13

Well, don’t I feel stupid! I should have checked before I wrote the forum post and feature request.

Everything is working without any action on the latest rolling version I have installed (2025.05.27-0019-rolling).

I just had to configure the key against my login and the PIN prompt and physical verification “just worked”.

@Viacheslav based on this, the feature request is “probably” OK to close, but I’m not sure whether all relevant SSH server options are exposed to ensure support and restrictions for FIDO2 authentication are available.

14

Nah, no need to feel stupid! As I said in my earlier message, it was actually not working ~1 year ago, but due to some different reasons.

I’m also glad to hear it now works, so we can switch over our routers as well, big win :smiley:

Also I’d leave the feature request open, but modify it a bit to at least reflect what the requested settings would actually accomplish. Or even better, make it more generic, so that any sort of options can be set via config (as that might come in handy in other situations).

Have a nice day :blush:

1 Like
15

Feel free to extend the current documentation, it will help other members to configure it or use specific use cases :slight_smile:

1 Like