You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
ieugen
changed the title
Support access using SSH certificates + roles
Support access using SSH certificates + groups
Feb 15, 2024
johnmaguire
added
the
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
label
Feb 16, 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:
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.
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
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
The text was updated successfully, but these errors were encountered: