SSH Key Management

Development
1

Hi everyone,

I have some problems with the current system of configuring SSH keys for users.

Is there a good reason for VyOS putting an additional validation layer over what OpenSSH already provides?

That seems unnecessary and creates a few problems:

  1. Supported OpenSSH features are rendered unusable because they are not configurable through the configuration system and system config files are reset regularly.
  2. It creates an unnecessary maintenance burden because when OpenSSH introduces new features the VyOS configuration system must be updated, too.
  3. The configuration experience is more complicated than it needs to be. But this might just be my personal preference.

Why not just simplify the current configuration command to

set system login user <username> authentication public-keys <authorized-keys-file-syntax-string>

and then use ssh-keygen to check the validity?

Wouldn’t this be a viable solution that solves above mentioned problems and achieve automatic feature parity with the shipped OpenSSH version? Am I missing something?

Interested to hear some feedback! I would also be willing to make the necessary changes to the codebase.

Additional context
We need support for authenticating users via SSH certificates. The OpenSSH version shipped with VyOS actually supports this, but the necessary keys cannot be configured because the require the key type to be prepended with cert-authority. There is also no way to set other options for the keys

3

Hello @heilerich , your idea looks interesting to me. I believe we need to keep both solutions

  1. Allow to configure SSH keys without additional params and validate via ssh-keygen or additional python crypto libs
  2. Keep possibility manually define additional options
    Before contributing, please read documentation Development — VyOS 1.3.x (equuleus) documentation
4

I need to note, I saw that some VyOS users have many workspaces/devices and add many keys for one user. Current VyOS ssh implementation is enough easy for this.

set system login user user1 authentication public-keys home key 'public key'
set system login user user1 authentication public-keys home type 'ssh-rsa'
set system login user user1 authentication public-keys work key 'public key'
set system login user user1 authentication public-keys work type 'ssh-rsa'
5

That’s very useful but I’m not sure that’s what the OP was looking for.

Think of SSH CA authentication as a great alternative to Radius authentication. You can authenticate with signed credentials that auto-expire (to prevent compromise of a long lived key or simply self-destructing if a team member leaves the team) and also work if for whatever reason the Vyos instance cannot talk to the Radius server.

There are also other nice things too and I think this post explains it best:

Some products, such as Teleport’s even allow SSO to authenticate before signing you a certificate. Imagine if you could lock down a VyOS instance to the point where you have to use a U2F key, a Gmail account, a GitHub account, a Facebook account, SMS messages, and/or other bizarre/convenient/security enhancing things before such a product would grant you a certificate that can login. SSH CAs would allow that. And there are other vendors than Teleport.

I’m not sure if a Radius server could match the security and convenience of what SSH CAs could possibly enable.