netbirdio
SSH & RDP access from the management dashboard
Summary
We are currently working on adding support for administrators to connect directly to peers via SSH and RDP sessions from the NetBird management dashboard.
Details
The goal of this feature is to allow administrators to establish a secure, browser-based connection to peers without the need to install or configure additional tools on their own devices. By embedding SSH and RDP access directly into the dashboard, administrators will be able to perform troubleshooting, maintenance, or user support tasks with just a few clicks.
How it will work
- A new option will be available in the peer view for Connect via SSH or Connect via RDP.
- Connections will run through a browser client, leveraging NetBird’s existing secure infrastructure.
- Existing access controls and permissions will continue to apply, ensuring only authorized users can initiate sessions.
- No agent or local client installation is required for administrators.
Why this matters
This feature will simplify remote management workflows, reduce friction for administrators, and make NetBird more effective as an all-in-one platform for secure connectivity and operations.
We’ll keep this issue updated as development progresses. Feedback is welcome!
Very happy with this upcoming change to SSH and addition of RDP, a question I have is will those capabilities be under a new role? Or is there a rework on the RBAC system coming to provide more ganularity/custom roles?
@Coler-e, initially, we will start with access granted for Admins and Owners only. The access control will be integrated into our Policies system for other users.
I see this as a security issue, as not all administrators should be allowed indiscriminate access to other people workstations. One thing is to be able to administer the VPN network, and another thing is being able to watch what users are doing (i.e. there might be reserved information on some screens, like accounting or management). Ideally, the owner of the network should be able to grant only specific administrators access to this feature.
@pquan I was worried about those things too, but got calmed down by the assurance that all of those remote access/control features need to be explicitly enabled both on the Management and the client side. We should definitely make it more visible, but the number of steps required to turn on the feature is enough to prevent turning those on accidentally.
A role (or permission) separate from simply Admin/Owner roles sounds like a good idea.
I see this as a security issue, as not all administrators should be allowed indiscriminate access to other people workstations. One thing is to be able to administer the VPN network, and another thing is being able to watch what users are doing (i.e. there might be reserved information on some screens, like accounting or management). Ideally, the owner of the network should be able to grant only specific administrators access to this feature.
Thanks for the feedback @pquan. In this case, if your administrator might have too much power already, as they can change policies and group membership. The best case for you would be to update their role to Network Admin, which allows them to create and perform some operations, but not use this feature or update their way into a peer config, like enable ssh. See more details here: https://docs.netbird.io/how-to/add-users-to-your-network#manage-user-roles
Thank you guys for the feedback on that part, I also assume RDP/SSH access would be represented in the upcoming control center to make sure everyone does have the right level of access?
Now as for my feedback on the feature, currently on windows the client only has allow SSH mentionned but nothing related to RDP. Under the assumption this might only be a GUI problem and both SSH and RDP might be allowable on the same button, I enabled it and then tried enabling again SSH on the Windows client I want to RDP to on the management server :
But I just get a re-auth from my IDP (Entra in my case) and then get sent back to the peers list as mentionned in #4580 by others.
Both Management and Clients were freshly updated to the latest release about 20 minutes ago.
We've released a new version of the dashboard handling a few issues, but with the connect button disabled. We are investigating a few issues on some deployments. Once they are resolved, we will enable it again.
Helloq folks, we've released a new version.
Please update the management, signal, and dashboard. If you deployed using our quick-start guide, ensure to review the steps in the following URL as some ports have changed:
https://docs.netbird.io/selfhosted/selfhosted-quickstart#support-browser-clients
For those using Traefik or Nginx, we've updated the Docker template from our infrastructure_files:
https://github.com/netbirdio/netbird/blob/main/infrastructure_files/docker-compose.yml.tmpl.traefik https://github.com/netbirdio/netbird/blob/main/infrastructure_files/nginx.tmpl.conf
I see this as a security issue, as not all administrators should be allowed indiscriminate access to other people workstations. One thing is to be able to administer the VPN network, and another thing is being able to watch what users are doing (i.e. there might be reserved information on some screens, like accounting or management). Ideally, the owner of the network should be able to grant only specific administrators access to this feature.
Thanks for the feedback @pquan. In this case, if your administrator might have too much power already, as they can change policies and group membership. The best case for you would be to update their role to
Network Admin, which allows them to create and perform some operations, but not use this feature or update their way into a peer config, like enable ssh. See more details here: https://docs.netbird.io/how-to/add-users-to-your-network#manage-user-roles
Thanks for the clarification @mlsmaycon . I understand that administrators already have significant privileges, but my concern is about the scope of that access. Ideally, administrative power should be limited to managing the network itself, not extending into users’ individual workstations or sessions. That introduces a different level of control — and potential privacy implications.
What would really help is a more fine-grained access control system (ACL) for roles. For example:
-
A “Network Admin” could manage peers and configurations without being able to access devices directly.
-
Meanwhile, limited roles (e.g., for HR or onboarding) could add users without the risk of changing security policies or tags.
At the moment, granting full admin rights feels risky, especially since there’s no audit log for who modifies peer tags or policies. Implementing modular, task-based permissions using existing ACL libraries could make the system both more secure and adaptable to different organizational needs.
As a side note, I’d suggest reconsidering the addition of built-in remote access features like SSH or RDP. While they can be convenient, there are already mature, dedicated tools for this purpose (e.g., RustDesk). Integrating such capabilities might unintentionally raise security concerns, as some may perceive them as unnecessary or intrusive.
I hope this feedback is taken in the spirit intended — as a suggestion to strengthen flexibility and trust in the platform’s security model. Thanks for considering it!
Helloq folks, we've released a new version.
Please update the management, signal, and dashboard. If you deployed using our quick-start guide, ensure to review the steps in the following URL as some ports have changed:
https://docs.netbird.io/selfhosted/selfhosted-quickstart#support-browser-clients
For those using Traefik or Nginx, we've updated the Docker template from our infrastructure_files:
https://github.com/netbirdio/netbird/blob/main/infrastructure_files/docker-compose.yml.tmpl.traefik https://github.com/netbirdio/netbird/blob/main/infrastructure_files/nginx.tmpl.conf
Thanks for this. But what if someone installed it prior to 0.59 and followed the Advanced guide section with another IDP? We don't have Caddyfile, nor a proxy. So, we have a Signal issue where the domain has SSL, but the socket is using WS instead of WSS.
Helloq folks, we've released a new version.
Please update the management, signal, and dashboard. If you deployed using our quick-start guide, ensure to review the steps in the following URL as some ports have changed:
https://docs.netbird.io/selfhosted/selfhosted-quickstart#support-browser-clients
For those using Traefik or Nginx, we've updated the Docker template from our infrastructure_files:
https://github.com/netbirdio/netbird/blob/main/infrastructure_files/docker-compose.yml.tmpl.traefik https://github.com/netbirdio/netbird/blob/main/infrastructure_files/nginx.tmpl.conf
Thanks for this. But what if someone installed it prior to 0.59 and followed the Advanced guide section with another IDP? We don't have
Caddyfile, nor a proxy. So, we have a Signal issue where the domain has SSL, but the socket is using WS instead of WSS.
@SasSam I think you missed this message: https://github.com/netbirdio/netbird/issues/4580#issuecomment-3383010649
Nice feature! I was wondering if it could be extended to allow to ssh|rdp connect to other resources within the allowed network. For example, suppose I need to connect using browser client to a server in the allowed network via RDP. I’d prefer not to install the Netbird client on that server, since the entire network is already added.
Coming back to the question who is allowed to connect via the new browser feature. I like the idea and the implementation!
To support even more use cases, I would highly appreciate seperate permission:
Which user can connect to which peer via which protocol. There are users which should be able to connect via browser to RDP to their individual desktop pcs in the office - which are enrolled as peers already.
In the scenario an additional requirement would be, to disable/prevent users to add (classic) peers. So then they would be limited to connect via browser.
This would enable netbird to replace less secure or at least more complex Remote login scenarios (e.g. today via Apache Guacamole or Rustdesk).
Great feature, though I agree with the need for more granular rights management. One detail: Are you talking about simple RDP, where the current user gets locked-out or a connection possible while the user is working on his desk (like TeamViewer, RustDesk, ...)? Especially for support, the latter is relevant. In that case, it would be great to also differentiate into "unsupervised connection" with respecting rights and "Prompt for Connection" with limited rights, that opens a pop-up on the client-site.
