NetBird SSH Server Access Requiring Machine Reboot
Hi, I have recently encountered issues with the NetBird's built-in SSH server.
Previously I could do:
netbird up --allow-server-ssh -k <key>.- Once the peer shows up in dashboard, then enable the SSH access on it.
- Last step would be
sudo netbird ssh <target>which would grant SSH access to the peer as the root user.
However, at the moment, for the SSH server to work, the peer requires a reboot, or issuing netbird down followed by netbird up --allow-server-ssh, while the SSH Access is enabled within NetBird's dashboard.
Same issue regarding disabling of the SSH access. The peer needs to be rebooted for the dashboard SSH access change to take place.
I tried disabling the SSH server access while the peer is powered off, and then enabling it once the peer is powered on via the NetBird's dashboard, however, I have faced issues connecting to it. It almost seems like the netbird service on the peer now requires a restart for the dashboard SSH access changes to take place, which was not the case before.
This defeats the purpose of the SSH server as if deployed remotely, the peer can't be accessed, and the peer requires remote access to fix the issue.
Please let me know if I can provide any additional details. Thank you,
hey @AV3T thank you for this report. Can you please tell us:
- client version
- OS version (release and kernel)
I would try to replicate on our side before asking for anything else. Thanks for the info!
Hello @mgarces , you are most welcome.
The client version in this case is 0.30.3.
I was previously able to use the built-in SSH feature on version 0.30.1 of the client without issues, but that is no longer the case. I experience the same issue on the 0.30.1 client version now as well.
The host OS version is Ubuntu 24.04.1 LTS, kernel is 6.8.0-47-generic.
The peer OS is Ubuntu 24.04 LTS, kernel is 6.8.0-41-generic.
Edit: The NetBird in use if the official version, and not the self-hosted one - if that helps as well. Thank you
Additional update:
I was able to SSH to the peer with built-in server after changing the group to which the peer belongs to. 44338/TCP is whitelisted/allowed within both groups. I wonder if the group change caused the netbird service to communicate to the dashboard and fetch the SSH access information at that point. Weird, but hope additional information helps.
@AV3T I can confirm that your workaround works. It seems that the dashboard sends a put request to the server to enable ssh but the server doesn't update the connected clients unless the group change trick is used.
+1
scenario 1: cannot connect netbird ssh without netbird up --allow-server-ssh
scenario 2: after netbird up --allow-server-ssh i have to remove and add the groups again to allow communications
WSL2
This should've been fixed a while ago, which version(s) are you on?
@lixmal unfortunately. both runs on v0.36.5
I get this, when trying to ssh Both devices have ssh enabled using the webgui as well as using the terminal command
C:\Users\alexd>netbird ssh [email protected]
Error: dial tcp 100.101.58.115:44338: i/o timeout
Couldn't connect. Please check the connection status or if the ssh server is enabled on the other peer
You can verify the connection by running:
netbird status
Error: dial tcp 100.101.58.115:44338: i/o timeout
Same as above. Running version 0.44.0 on both ends.
Using latest version and this is still happening. Simply toggling the switch in dashboard doesn't work, have to use the command line.
This issue has been open for at least 8 months which is making me reluctant to move my entire infrastructure over from tailscale.
A shame, because I liked netbird.
Moved to tailscale because of ssh issue
Same problem on our side.
I have this issue as well, I can't connect over netbird ssh unless I reboot the ssh server node.
Tried everything I've found as a solution online but no luck with ssh connection, i get timeout error even when ping works. Running latest version as of today.. I liked Netbird so i hope you find a solution for ssh.
Same issue here, the latest agents on both sides, unfortunately, nothing worked, even a Server restart.
Similar issues here. I was lucky to find a solution for a hassle-free + secure ssh management. But with the newer versions this is not possible any more.
I am using client node version 0.59.11 and server node version 0.45.1.
Still have the same issue with Windows machines. No issues with Linux machines (Debian and Raspbian).
Folks, can you test the latest 0.60.x please
I just updated both my client and an agent installed on another device from 0.59.x to 0.60.4 and SSH has stopped working. Previously, the Netbird SSH server was running on port 44338, now it seems to be attempting to connect over port 22.
$ sudo netbird ssh [email protected]
Failed to connect to [email protected]:22
Troubleshooting steps:
1. Check peer connectivity: netbird status -d
2. Verify SSH server is enabled on the peer
3. Ensure correct hostname/IP is used
Error: dial 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted:22: SSH server detection: connect to 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted:22: dial tcp 100.102.187.253:22: connect: connection refused
When I try and specify the old port number directly, it doesn't seem to support custom port numbers.
$ sudo netbird ssh [email protected]:44338
Failed to connect to [email protected]:44338:22
Troubleshooting steps:
1. Check peer connectivity: netbird status -d
2. Verify SSH server is enabled on the peer
3. Ensure correct hostname/IP is used
Error: dial 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted:44338:22: parse address 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted:44338:22: address 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted:44338:22: too many colons in address
I am able to ping the device
$ ping 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted
PING 689ceab78d45d0107dea3c2e-187-253.netbird.selfhosted (100.102.187.253): 56 data bytes
64 bytes from 100.102.187.253: icmp_seq=0 ttl=64 time=232.345 ms
64 bytes from 100.102.187.253: icmp_seq=1 ttl=64 time=148.904 ms
64 bytes from 100.102.187.253: icmp_seq=2 ttl=64 time=172.323 ms
64 bytes from 100.102.187.253: icmp_seq=3 ttl=64 time=437.396 ms