Support access using SSH certificates + groups

[ieugen]

What version of nebula are you using? (nebula -version)

1.8.2

What operating system are you using?

N/A

Describe the Bug

Users can be allowed to acces nebula SSH interface by having nebula trust certificates issues by an SSH certificate authority.

This feature should be accompanied by a set of options to trust a specific user name or users from a specific group - specified in the certificate.

One advantage of using an SSH CA is that you can also sign the host key by the CA and thus avoid the dangers of trusting the host key on first connect.

A configuration could look like this

sshd:
  enabled: true
  listen: 127.0.0.1:2222
  host_key: /etc/ssh/ssh_host_ed25519_key
  certificate_authorities:
    - allow_groups:
        - sysadmins
        - team-dev1
      keys:
        - /etc/ssh/user_ca_key.pub

Some examples on how to setup ssh CA

• https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate-based_Authentication
• https://www.hashicorp.com/blog/managing-ssh-access-at-scale-with-hashicorp-vault

This issue is somewhat related to #1051 .

Logs from affected hosts

N/A

Config files from affected hosts

N/A

[johnmaguire]

Hi @ieugen - I put up an exploratory PR for this, however I'm a bit confused by one thing in your request. You mention allowed groups, but neither of the links you provided discuss groups, and I'm not aware of any kind of groups feature in SSH certificates. Can you share more about this?

For some context, here's the output of ssh-keygen -L:

id_ed25519-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:/fLSWl/aFbaS1dBp0m31YBQxxCccSLAuxRVuvamPsZ4
        Signing CA: RSA SHA256:wg3OrnFDgh03ns6nA/4ddxbSSoqwnD2GWjj4Weka5pM (using rsa-sha2-512)
        Key ID: "jmaguire"
        Serial: 0
        Valid: forever
        Principals:
                jmaguire
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

[ieugen]

Hi @johnmaguire , yes you are right.

SSH has principals which is not the same.
So I guess s/groups/principals :) ?!

It's explained here quite well: https://betterprogramming.pub/how-to-use-ssh-certificates-for-scalable-secure-and-more-transparent-server-access-720a87af6617

See "Multiple Servers With the Same Username"

When you issue a certificate with usernames, let’s say root , you will be giving access to all your servers that trust your certificate authority.
Instead of issuing the certificate username in principals, you need to create a strategy for principals and map those to usernames. You can do this by using AuthorizedPrincipalsFile.