[GH-ISSUE #5634] Add a setting to bypass "JWT Authentication" without --disable-ssh-auth #10877

Open
opened 2026-08-05 01:27:34 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @crntnvdl on GitHub (Mar 19, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5634

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
We use GitHub Actions to run commands on machines using Netbird to access them. The action uses an ephemeral setup key to add the runners. When the runner tries to SSH, Netbird ask it to authenticate using OIDC and blocks. I don't really want to disable ssh auth on the servers these runners are connecting to, and it would be nice to be able to limit them to connect only to specific restricted users.

Describe the solution you'd like
A clear and concise description of what you want to happen.
A switch to allow machines to bypass the IdP authentication without disabling it for everyone on the target peer with --disable-ssh-auth. Possible places for this setting:

  • In the policy when set to NETBIRD-SSH
    • When turned OFF machines being granted access by this policy (maybe could even check SSH user at this step too) must ask for "JWT Authentication" and user permissions get checked. Could be used for a multi-user machine where the machine can access "all users" on some peers and then each user on the system has to authenticate with IdP to be allowed to connect to specific users on target-peer.
    • When turned ON, don't require the user to authenticate and grant access only based on that policy.
  • In the setup key applying to peers who joined with it.
  • A global setting like "Enable user group propagation" applied to the whole organization

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Our current workaround is to use a TCP policy on port 22 and a classic SSH key pair.
You could up the target-peer with --disable-ssh-auth but this isn't optimal, you'd disable a layer of safety for connections coming from all peers and you wouldn't have fine grained access.

Additional context
I tried to understand how the NetBird SSH flow goes, basically something like this ?

  • User tries to SSH from an origin-peer to a target-peer.
  • The user might or not have an IdP account, and the machine might be (added with a setup key) or (linked to a user (with groups propagation enabled or not)).
  • First step is "Machine Identity" check, the origin-peer must have a policy allowing it to NBSSH to the target-peer (1), even if the machine is linked to a user this check use the groups of the machine (which may contain the user groups if propagation is enabled, part of them if some groups were manually removed or none at all if propagation is disabled). No SSH user check is made here.
  • Second step is "JWT Authentication" (bypassed if the target-peer was up with --disable-ssh-auth), a login link is printed / a browser opens asking the user to connect with IdP. The user must be in a group which has permission to NBSSH as a specific user in the target-peer.
  • If both checks pass the SSH connects.

Why can't machine identity also allow fine grained SSH access ?

(1): In previous versions when protocol is NETBIRD-SSH you could select a peer directly as source (iirc, I have some policies like that and I don't remember having to workaround) but now you can only pick a group. However you can 'bypass' this by setting the protocol to 'ALL', fill the source field with a peer and then switch to NETBIRD-SSH. Is this a UI issue ? Intended behavior ? Start of deprecation for this feature ? (Tested with Management v0.66.4, Dashboard v2.34.2)

Originally created by @crntnvdl on GitHub (Mar 19, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5634 **Is your feature request related to a problem? Please describe.** A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] We use GitHub Actions to run commands on machines using Netbird to access them. The action uses an ephemeral setup key to add the runners. When the runner tries to SSH, Netbird ask it to authenticate using OIDC and blocks. I don't really want to disable ssh auth on the servers these runners are connecting to, and it would be nice to be able to limit them to connect only to specific restricted users. **Describe the solution you'd like** A clear and concise description of what you want to happen. A switch to allow machines to bypass the IdP authentication without disabling it for everyone on the target peer with `--disable-ssh-auth`. Possible places for this setting: - In the policy when set to `NETBIRD-SSH` - When turned OFF machines being granted access by this policy (maybe could even check SSH user at this step too) must ask for "JWT Authentication" and user permissions get checked. Could be used for a multi-user machine where the machine can access "all users" on some peers and then each user on the system has to authenticate with IdP to be allowed to connect to specific users on target-peer. - When turned ON, don't require the user to authenticate and grant access only based on that policy. - In the setup key applying to peers who joined with it. - A global setting like "Enable user group propagation" applied to the whole organization **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. Our current workaround is to use a TCP policy on port 22 and a classic SSH key pair. You could up the target-peer with `--disable-ssh-auth` but this isn't optimal, you'd disable a layer of safety for connections coming from all peers and you wouldn't have fine grained access. **Additional context** I tried to understand how the NetBird SSH flow goes, basically something like this ? - User tries to SSH from an origin-peer to a target-peer. - The user might or not have an IdP account, and the machine might be (added with a setup key) or (linked to a user (with groups propagation enabled or not)). - First step is "Machine Identity" check, the origin-peer must have a policy allowing it to NBSSH to the target-peer **(1)**, even if the machine is linked to a user this check use the groups of the machine (which may contain the user groups if propagation is enabled, part of them if some groups were manually removed or none at all if propagation is disabled). No SSH user check is made here. - Second step is "JWT Authentication" (bypassed if the target-peer was up with `--disable-ssh-auth`), a login link is printed / a browser opens asking the user to connect with IdP. The user must be in a group which has permission to NBSSH as a specific user in the target-peer. - If both checks pass the SSH connects. Why can't machine identity also allow fine grained SSH access ? **(1)**: In previous versions when protocol is `NETBIRD-SSH` you could select a peer directly as source (iirc, I have some policies like that and I don't remember having to workaround) but now you can only pick a group. However you can 'bypass' this by setting the protocol to 'ALL', fill the source field with a peer and then switch to `NETBIRD-SSH`. Is this a UI issue ? Intended behavior ? Start of deprecation for this feature ? (Tested with Management v0.66.4, Dashboard v2.34.2)
saavagebueno added the feature-request label 2026-08-05 01:27:34 -04:00
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#10877