Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support access using SSH certificates + groups #1076

Open
ieugen opened this issue Feb 15, 2024 · 2 comments
Open

Support access using SSH certificates + groups #1076

ieugen opened this issue Feb 15, 2024 · 2 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.

Comments

@ieugen
Copy link

ieugen commented Feb 15, 2024

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

This issue is somewhat related to #1051 .

Logs from affected hosts

N/A

Config files from affected hosts

N/A

@ieugen ieugen changed the title Support access using SSH certificates + roles Support access using SSH certificates + groups Feb 15, 2024
@johnmaguire johnmaguire added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Feb 16, 2024
@johnmaguire
Copy link
Collaborator

johnmaguire commented Mar 26, 2024

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: [email protected] 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
Copy link
Author

ieugen commented Mar 26, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

2 participants