SSH remote connection fails on Windows — hardcoded /usr/bin/ssh path

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25187
2. https://github.com/anthropics/claude-code/issues/7528

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same problem here, thank you.

Та же проблема

I'm experiencing the same problem.

Same problem

same problem

I've tried these commands as a workaround but got another error: Host denied (verification failed)

mkdir C:\usr\bin
mklink C:\usr\bin\ssh.exe "C:\Windows\System32\OpenSSH\ssh.exe"

Following advice from @SSS135 in this thread, I created a symlink to work around it:

mkdir C:\usr\bin
mklink C:\usr\bin\ssh.exe "C:\Windows\System32\OpenSSH\ssh.exe"

This fixed the ENOENT error — but revealed a second, separate bug: the app now uses its built-in ssh2 library (as seen by [SSH2Connection] in logs instead of spawning system ssh), and host key verification is completely broken for non-standard SSH ports.

Environment

• Windows 11 Pro 10.0.26100 (x64)
• Claude Desktop 1.1.3189
• Claude Code (bundled) 2.1.41
• Target: remote server on port 40010 (non-standard) — cloud GPU instance

The new error

After the symlink workaround, every connection attempt now fails with:

[SSH2Connection] Resolved root@<host> -> root@<host>:40010
[SSH2Connection] Host <host>:40010 is not in known_hosts
[SSH2Connection] Connecting to root@<host>:40010 (agent: false, key: true, proxy: false, keyboard: true)
[SSH2Connection] Connection error: Host denied (verification failed)

The host key IS in ~/.ssh/known_hosts. The same SSH connection works perfectly from any terminal: ssh -p 40010 root@<host> connects instantly.

What I tried to fix it (nothing works)

| Attempt | Result |
|---------|--------|
| Host key in known_hosts as [<host>]:40010 (standard OpenSSH format) | Not recognized by Claude Desktop |
| Host key added as <host> (without port, without brackets) | Not recognized |
| Host key added as <host>:40010 (colon format matching the log output) | Not recognized |
| trustedHosts in ssh_configs.json with all format variants | No effect whatsoever |
| StrictHostKeyChecking no in ~/.ssh/config for this host | Ignored |
| UserKnownHostsFile /dev/null in ~/.ssh/config | Ignored |
| Full restart of Claude Desktop between each attempt | Same error |

Verified via ssh-keygen -F "[<host>]:40010" that the keys are present and valid (ed25519, rsa, ecdsa — all three).

Additional bug: ~ not resolved in sshIdentityFile on Windows

The sshIdentityFile field in ssh_configs.json does not resolve ~ on Windows.

• "sshIdentityFile": "~/.ssh/id_ed25519" → log shows key: false (key not found)
• "sshIdentityFile": "C:\\Users\\<user>\\.ssh\\id_ed25519" → log shows key: true (works)

ssh.log timeline showing both bugs in sequence

Phase 1 — ENOENT (before symlink workaround):

[RemoteServerController] Connection failed: Failed to spawn /usr/bin/ssh: spawn /usr/bin/ssh ENOENT

Phase 2 — Host verification failure (after symlink, ssh2 library used):

[SSH2Connection] Host <host>:40010 is not in known_hosts
[SSH2Connection] Connection error: Host denied (verification failed)

Root cause analysis

The built-in ssh2 library in Claude Desktop:

1. Cannot parse known_hosts for non-standard ports. OpenSSH stores non-standard port entries as [host]:port (with square brackets). The ssh2 library searches for host:port (without brackets) and never finds a match.

1. Has no UI for accepting unknown hosts. When the host key is not found, the connection is immediately rejected. There is no prompt to accept/trust the key — unlike every standard SSH client. The only UI option is "Try again", which loops the same error indefinitely.

1. Ignores trustedHosts in ssh_configs.json. This field appears to have no effect on host key verification.

1. Ignores StrictHostKeyChecking and UserKnownHostsFile from ~/.ssh/config. The ssh2 library reads Host, Port, HostName from the config (it resolves the port correctly), but does not respect security-related directives.

Suggested fixes

1. Fix known_hosts parsing to handle the [host]:port bracket format per OpenSSH spec
2. Add a UI prompt to accept unknown host keys (standard SSH behavior)
3. Make trustedHosts in ssh_configs.json actually bypass host verification
4. Respect StrictHostKeyChecking from ~/.ssh/config
5. Resolve ~ in sshIdentityFile on Windows

Workaround

None for Claude Desktop with non-standard SSH ports on Windows. Claude Code CLI works fine since it uses system OpenSSH.

---

This effectively means SSH remote connections on Claude Desktop are broken for anyone using non-standard ports

Thank you @pockerhead for the additional detail. I run sshd on other ports for many of my sandbox VMs. The suggested fixes would be amazing.

IMO, a roadmap to your suggestion should be that Claude runs the built in Windows ssh (C:\Windows\System32\OpenSSH\ssh.exe) and expects that the user has already set up the and established a connection that succeeds that way. Then it could leverage what you get out of a git (cygwin) bash+ssh solution. But it has to build off of the "potentially duplicated issues" cited above by running bash via those git installs and then running ssh within those shells. Lastly, wsl is installed andthe user has a home dir with .sssh/XXXs stuff, use that to execute the ssh connections,

Sorry about this folks, this will be fixed in the next release.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.