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

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] 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: #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: #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

• #32734 (closed as dup of #25933 — but #25933 is a different bug about environment dropdown)
• #26809 (port/host verification — partially related)
• #26997 (encrypted default key — partially related, worked around)
• #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