[BUG] Claude Desktop SSH: "Timed out while waiting for handshake" - Windows to Linux, server auth succeeds, getSSHGitInfo fails

[NonsuchNinja]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

Environment

• Product: Claude Desktop (Windows GUI app)
• OS: Windows 11
• Remote Server: Ubuntu 24.04, OpenSSH 9.6p1
• SSH Port: 2222 (non-standard)
• Auth Method: Ed25519 key, no passphrase
• Date: March 16, 2026

Problem

Claude Desktop's SSH remote connection consistently fails with "Timed out while waiting for handshake" after the initial SSH connection test succeeds.

Terminal SSH from the same Windows machine works perfectly:

ssh -i ~/.ssh/id_ed25519_claude -p 2222 ceo@143.198.151.210 "echo connected"
connected

Server-Side Evidence

Server auth logs show only one connection — authentication succeeds fully:

sshd[534079]: Connection from 172.56.213.60 port 45372 on 143.198.151.210 port 2222
sshd[534079]: Accepted key ED25519 SHA256:m/AtMDjb0edSy5XIT3sQS4OZZfDZO/J8MChr2BunAmo found at /home/ceo/.ssh/authorized_keys:1
sshd[534079]: Accepted publickey for ceo from 172.56.213.60 port 45372 ssh2
sshd[534079]: pam_unix(sshd:session): session opened for user ceo(uid=1000)
sshd[534079]: User child is on pid 534133

Critical finding: Only ONE connection attempt reaches the server. The testSSHConnection succeeds, but the second internal getSSHGitInfo handshake either never connects or times out client-side before reaching the server.

What Was Tried (All Failed)

1. Generated new passphrase-free ed25519 key — to eliminate encrypted key parsing issues (ref: SSH dialog: Cannot connect when default key (~/.ssh/id_ed25519) is encrypted #26997)
2. Renamed all other keys (id_rsa, nilassist_secure) out of ~/.ssh/ — to prevent ssh2 library from choking on encrypted default keys
3. Added host key via ssh-keyscan — ssh-keyscan -p 2222 143.198.151.210 >> known_hosts (ref: [BUG] Claude Code Desktop SSH: Port directive from ~/.ssh/config ignored + unhelpful host verification error #26809)
4. Restricted server KEX algorithms — removed sntrup761x25519-sha512@openssh.com and all post-quantum KEX, limited to curve25519-sha256, ecdh-sha2-nistp*, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha256
5. Verified server config is clean — UseDNS no, no ForceCommand, no Banner, .bashrc exits early for non-interactive sessions, PrintMotd no

Root Cause Analysis

Claude Desktop uses the Node.js ssh2 library internally rather than the system's OpenSSH. The testSSHConnection step uses one code path (works), while getSSHGitInfo uses a second SSH handshake that fails. Since the server only sees one connection, the second handshake appears to fail client-side before even reaching the server — possibly a timeout, KEX negotiation failure, or internal routing issue within the ssh2 library.

Connection Details Used in Claude Desktop Dialog

• SSH Host: ceo@143.198.151.210
• SSH Port: 2222
• Identity File: C:\Users\mjaba\.ssh\id_ed25519_claude

Related Issues

• Claude Desktop SSH: "Timed out while waiting for handshake" - testSSHConnection succeeds but getSSHGitInfo always fails #32734 (closed as dup of [BUG] SSH connection shows "connected" but doesn't appear in environment dropdown #25933 — but [BUG] SSH connection shows "connected" but doesn't appear in environment dropdown #25933 is a different bug about environment dropdown)
• [BUG] Claude Code Desktop SSH: Port directive from ~/.ssh/config ignored + unhelpful host verification error #26809 (port/host verification — partially related)
• SSH dialog: Cannot connect when default key (~/.ssh/id_ed25519) is encrypted #26997 (encrypted default key — partially related, worked around)
• [BUG] Claude Code desktop app gets stuck and progresses indefinitely when connected via SSH on Windows #27165 (Windows SSH connected but stuck)

What Should Happen?

Claude Desktop should complete the SSH connection and allow remote Claude Code execution, since terminal SSH works perfectly and server authentication succeeds.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

Latest (March 2026)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

[aL0ng-z]

same thing happened

[siberguvenlikhaberler]

same here

[omid-web]

Additional reproduction: macOS → Windows OpenSSH (WSL2 bash)

Environment:

• Client: macOS (Darwin 25.4.0), Claude Desktop latest, Claude Code 2.1.x
• Remote: Windows 11, OpenSSH_for_Windows_9.5, DefaultShell set to WSL2 bash (Ubuntu)
• Network: ZeroTier VPN, port 22 (standard)
• Auth: RSA key, no passphrase, pubkey auth succeeds
• Username: Contains a space (Omid Rajabi)

What works:

• Terminal SSH (ssh ccdesktop "echo OK") — connects instantly, authenticates, runs commands
• Remote server binary (~/.claude/remote/server serve --stdio) — starts, creates Unix socket at ~/.claude/remote/rpc.sock, responds to connections
• Claude Code CLI on the remote (claude --version) — installed and functional at /home/omid/.local/bin/claude

What fails:

• Claude Desktop SSH remote: "Timed out while waiting for handshake"
• When bypassing the SSH config alias and using explicit Omid Rajabi@10.242.34.225, the error changes to: "RPC call to server.ping timed out" and "Timeout waiting for remote server socket" — meaning SSH auth succeeded but the server never starts

Evidence the server never launches:

• ~/.claude/remote/remote-server.log remains 0 bytes after every Claude Desktop attempt
• ~/.claude/remote/rpc.sock is never created
• No claude or server processes appear in ps after the attempt
• The same server binary runs perfectly when invoked manually via terminal SSH

Troubleshooting attempted (all failed):

1. Disabled SSH compression (Compression no) — no change
2. Used SSH config alias (ccdesktop) vs explicit user@host — alias gives handshake timeout, explicit gives RPC timeout
3. Verified KEX compatibility — server uses ecdh-sha2-nistp256, host key ssh-ed25519, cipher aes128-gcm@openssh.com — all standard algorithms
4. Confirmed ~/.local/bin is in PATH (added before .bashrc interactive guard)
5. Verified server binary is correct architecture (ELF 64-bit, x86-64, statically linked)
6. Confirmed disk space, permissions, and socket directory are all fine

Possible root cause:
Consistent with the original report — Claude Desktop's Node.js ssh2 library successfully authenticates but fails to execute the remote server binary. The server log being empty (not even a startup error) suggests the ssh2 library's exec or shell channel never actually runs the command, even though the SSH session is established. This is distinct from a server-side issue — the problem is entirely client-side within the ssh2 library's command execution after authentication.

The username containing a space may be a contributing factor, as the ssh2 library may not properly handle usernames with spaces in the exec command construction.

[chris-shim]

Same on Windows + WireGuard VPN. Network latency measured ~11s consistently, ssh2 hardcoded 10s timeout always triggers. Please expose readyTimeout option or increase default. Terminal SSH and VS Code Remote SSH (60s ConnectTimeout) work fine on identical setup.