[GH-ISSUE #5872] bug: netbird ssh bypasses NetBird SSH and connects to plain SSH on port 22 in 0.68.1 #12215

Closed
opened 2026-08-05 01:32:41 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @renne on GitHub (Apr 13, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5872

Summary

netbird ssh <peer> does not use NetBird SSH on my setup with NetBird 0.68.1.

Instead of connecting to the NetBird SSH server on port 22022 with NetBird identity SSH (JWT/SSO), the client appears to fall back to plain SSH on port 22. The server-side NetBird daemon logs nothing during the attempt, which suggests the NetBird SSH server is never reached at all.

This is a high-severity regression for me because the feature is completely broken.

Expected behavior

netbird ssh <peer> should:

  1. Use NetBird identity SSH (JWT/SSO)
  2. Connect to the NetBird SSH server on port 22022
  3. Produce server-side NetBird logs visible in journalctl -u netbird

Actual behavior

netbird ssh <peer> appears to:

  1. Connect to port 22 using plain SSH
  2. Fail with:
    ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password]
    
  3. Produce zero server-side NetBird logs in journalctl -u netbird

Reproduction

Client command:

netbird ssh target-peer.example.internal -v

Client error:

Failed to connect to user@target-peer.example.internal:22
Error: ssh handshake failed: unable to authenticate,
attempted methods [none password], no supported methods remain

Server log during the attempt:

(EMPTY - nothing - zero lines)

Evidence that the server is ready

Server listening sockets

LISTEN 100.x.y.10:22022 -> netbird
LISTEN 0.0.0.0:22       -> sshd

So:

  • NetBird SSH server is listening on 100.x.y.10:22022
  • Normal SSH daemon is listening on 0.0.0.0:22

Server netbird status

SSH Server: Enabled
NetBird IP: 100.x.y.10/16
Management: Connected

Client netbird status

SSH Server: Enabled
NetBird IP: 100.x.y.20/16
Management: Connected

Evidence that policy is configured

Dashboard policy:

  • Protocol = NetBird SSH
  • Source group = Users (contains client peer client-peer)
  • Destination group = SSH servers (contains server peer target-peer)
  • SSH Access = Full Access
  • Policy = ENABLED

Environment

Management host

  • NetBird version: v0.68.1
  • Dashboard version: v2.36.0
  • Deployment type: self-hosted

Client peer

  • Hostname: client-peer.example.internal
  • NetBird IP: 100.x.y.20/16
  • OS: Ubuntu 24.04 inside WSL2 on Windows 11
  • Arch: linux/amd64
  • Daemon: 0.68.1
  • CLI: 0.68.1

Server peer

  • Hostname: target-peer.example.internal
  • NetBird IP: 100.x.y.10/16
  • OS: Linux VM on Proxmox VE
  • Arch: linux/amd64
  • Daemon: 0.68.1
  • CLI: 0.68.1

Why this seems different from #3832

Issue #3832 looks like a case where the NetBird SSH server is reached but authentication fails.

This bug appears different:

  • the client connects to :22
  • the NetBird SSH server on :22022 is never reached
  • the server writes zero NetBird logs during the attempt

So this looks more like the client is bypassing NetBird SSH entirely rather than a server-side auth problem.

Running:

netbird ssh configure

treats configure as a hostname and tries to connect to configure:22.

That suggests there is no local SSH config/configure subcommand in 0.68.1, and also reinforces the impression that the client is behaving like a plain SSH wrapper instead of using NetBird SSH.

Question

Is there a known regression in 0.68.1 where netbird ssh bypasses the NetBird SSH server completely, even when:

  • a NetBird SSH policy exists
  • the destination server has NetBird SSH enabled
  • port 22022 is open and listening
  • both peers are connected to management successfully?
Originally created by @renne on GitHub (Apr 13, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5872 <!-- Saved: 2026-04-13 15:08 CEST --> ## Summary `netbird ssh <peer>` does not use NetBird SSH on my setup with NetBird `0.68.1`. Instead of connecting to the NetBird SSH server on port `22022` with NetBird identity SSH (JWT/SSO), the client appears to fall back to plain SSH on port `22`. The server-side NetBird daemon logs nothing during the attempt, which suggests the NetBird SSH server is never reached at all. This is a high-severity regression for me because the feature is completely broken. ## Expected behavior `netbird ssh <peer>` should: 1. Use NetBird identity SSH (JWT/SSO) 2. Connect to the NetBird SSH server on port `22022` 3. Produce server-side NetBird logs visible in `journalctl -u netbird` ## Actual behavior `netbird ssh <peer>` appears to: 1. Connect to port `22` using plain SSH 2. Fail with: ```text ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password] ``` 3. Produce **zero** server-side NetBird logs in `journalctl -u netbird` ## Reproduction Client command: ```bash netbird ssh target-peer.example.internal -v ``` Client error: ```text Failed to connect to user@target-peer.example.internal:22 Error: ssh handshake failed: unable to authenticate, attempted methods [none password], no supported methods remain ``` Server log during the attempt: ```text (EMPTY - nothing - zero lines) ``` ## Evidence that the server is ready ### Server listening sockets ```text LISTEN 100.x.y.10:22022 -> netbird LISTEN 0.0.0.0:22 -> sshd ``` So: - NetBird SSH server is listening on `100.x.y.10:22022` - Normal SSH daemon is listening on `0.0.0.0:22` ### Server `netbird status` ```text SSH Server: Enabled NetBird IP: 100.x.y.10/16 Management: Connected ``` ### Client `netbird status` ```text SSH Server: Enabled NetBird IP: 100.x.y.20/16 Management: Connected ``` ## Evidence that policy is configured Dashboard policy: - Protocol = `NetBird SSH` - Source group = `Users` (contains client peer `client-peer`) - Destination group = `SSH servers` (contains server peer `target-peer`) - SSH Access = `Full Access` - Policy = `ENABLED` ## Environment ### Management host - NetBird version: `v0.68.1` - Dashboard version: `v2.36.0` - Deployment type: `self-hosted` ### Client peer - Hostname: `client-peer.example.internal` - NetBird IP: `100.x.y.20/16` - OS: `Ubuntu 24.04` inside `WSL2` on `Windows 11` - Arch: `linux/amd64` - Daemon: `0.68.1` - CLI: `0.68.1` ### Server peer - Hostname: `target-peer.example.internal` - NetBird IP: `100.x.y.10/16` - OS: `Linux VM on Proxmox VE` - Arch: `linux/amd64` - Daemon: `0.68.1` - CLI: `0.68.1` ## Why this seems different from #3832 Issue #3832 looks like a case where the NetBird SSH server is reached but authentication fails. This bug appears different: - the client connects to `:22` - the NetBird SSH server on `:22022` is never reached - the server writes **zero** NetBird logs during the attempt So this looks more like the client is bypassing NetBird SSH entirely rather than a server-side auth problem. ## Related observation Running: ```bash netbird ssh configure ``` treats `configure` as a hostname and tries to connect to `configure:22`. That suggests there is no local SSH config/configure subcommand in `0.68.1`, and also reinforces the impression that the client is behaving like a plain SSH wrapper instead of using NetBird SSH. ## Question Is there a known regression in `0.68.1` where `netbird ssh` bypasses the NetBird SSH server completely, even when: - a NetBird SSH policy exists - the destination server has NetBird SSH enabled - port `22022` is open and listening - both peers are connected to management successfully?
Author
Owner

@aliamerj commented on GitHub (Apr 15, 2026):

I use NetBird SSH heavily and wanted to verify the issue.
I tried to reproduce this using a simple setup with two Linux VMs acting as peers (peer1 and peer2), both connected to a self-hosted NetBird instance. NetBird SSH was enabled on the target peer and the policy was configured to allow access.

From peer2 I ran:

netbird ssh peer1

At first it looked like the client was connecting to port 22, which made it seem like it was falling back to normal SSH. But during the connection I got the SSO/JWT login prompt, which already suggests NetBird SSH is in use.

Image

To be sure, I checked traffic on peer1 using tcpdump with tcpdump -ni any port 22 or port 22022 and looked at the SSH banner. The response on port 22 was:

SSH-2.0-NetBird-SSH

here on peer 1

Image

So even though the connection is made to port 22, it’s not plain sshd. NetBird is intercepting that connection and handling it internally (redirecting to its own SSH service on 22022).

In other words, connecting to port 22 here is expected behavior and doesn’t mean NetBird SSH is being bypassed. In my test, everything went through NetBird SSH correctly.

So I wasn’t able to reproduce a case where it actually falls back to plain SSH.

<!-- gh-comment-id:4251090480 --> @aliamerj commented on GitHub (Apr 15, 2026): I use NetBird SSH heavily and wanted to verify the issue. I tried to reproduce this using a simple setup with two Linux VMs acting as peers (peer1 and peer2), both connected to a self-hosted NetBird instance. NetBird SSH was enabled on the target peer and the policy was configured to allow access. From peer2 I ran: ``` netbird ssh peer1 ``` At first it looked like the client was connecting to port 22, which made it seem like it was falling back to normal SSH. But during the connection I got the SSO/JWT login prompt, which already suggests NetBird SSH is in use. <img width="415" height="270" alt="Image" src="https://github.com/user-attachments/assets/2287cc7c-071f-401d-b859-67f896a972d1" /> To be sure, I checked traffic on peer1 using tcpdump with `tcpdump -ni any port 22 or port 22022` and looked at the SSH banner. The response on port 22 was: ``` SSH-2.0-NetBird-SSH ``` here on peer 1 <img width="522" height="760" alt="Image" src="https://github.com/user-attachments/assets/80244072-9ffb-4070-95cc-606622b99bd4" /> So even though the connection is made to port 22, it’s not plain sshd. NetBird is intercepting that connection and handling it internally (redirecting to its own SSH service on 22022). In other words, connecting to port 22 here is expected behavior and doesn’t mean NetBird SSH is being bypassed. In my test, everything went through NetBird SSH correctly. So I wasn’t able to reproduce a case where it actually falls back to plain SSH.
Author
Owner

@renne commented on GitHub (Apr 23, 2026):

Port 22 is correct. Solved with https://github.com/netbirdio/netbird/releases/tag/v0.69.0. May have been https://github.com/netbirdio/netbird/pull/5903

<!-- gh-comment-id:4302545905 --> @renne commented on GitHub (Apr 23, 2026): Port 22 is correct. Solved with https://github.com/netbirdio/netbird/releases/tag/v0.69.0. May have been https://github.com/netbirdio/netbird/pull/5903
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#12215