SSH Tunnel to Windows Server 2025 sshd with Key based Auth fails, Interactive/Password auth works fine

SSH Tunnel to Windows Server 2025 sshd with Key based Auth fails, Interactive/Password auth works fine

avatar
Brandon Jackson

In RDM I use an SSH Tunnel to a Windows 2025 Server running the native sshd service, and then run many sessions over it.

It has worked perfectly fine with Password auth, I was looking to switch to Private/Public Key Auth.

However, even though I have gotten it to accept the auth the SSH Tunnel session immediately closes/crashes, and in the Windows Event log you can see.

"sshd: ssh_dispatch_run_fatal: Connection from 10.215.246.227 port 63558: invalid format"

This entry is immediately after "sshd: Accepted publickey for".....

SSH Shell with the same key works perfectly fine, and again using Interactive/password auth for the tunnel works.

Any Ideas?


Windows Server 2025 fully updated, it is AD Joined (since shell and password work dont think ad matters but who knows)

The username does start with a ! (i.e !firstlast ), might be unrelated, but just noting.

All Comments (1)

avatar
Carl Marien

Hello.
Thanks for the detailed report — that's a good find. A few questions to help narrow this down:

  1. What version of RDM are you running?
  2. Is this a Local, Remote, or Dynamic tunnel?
  3. Does sshd_config on the Windows Server 2025 box have any non-default Ciphers, MACs, or KexAlgorithms restrictions?
  4. Just to confirm — the same private key works fine for an SSH Shell entry to the same server, correct?
  5. What type is the key — RSA, ED25519, or ECDSA? And was it generated in RDM's SSH Key entry, imported from an OpenSSH-format file, or linked from a local key file?
  6. When the tunnel fails, does RDM show an error dialog/toast, or does the session just silently disconnect?


If you're able to, two things that would really help us pin this down:

  • A screenshot of the RDM Tunnel entry's own connection log (enable "Show Logs" / verbose logging on the entry if possible) from a failed attempt, so we can compare what the client thinks it's doing against what the server received.


In the meantime, password auth for the tunnel remains a workaround.

Best regard

Carl Marien