SSH dialog: Cannot connect when default key (~/.ssh/id_ed25519) is encrypted

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25661
2. https://github.com/anthropics/claude-code/issues/26809

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

Yeah, this is a frustrating one.

Additional Context: SSH Agent Integration Not Working

Setup

• OS: macOS (Darwin 25.2.0)
• ssh-agent: Running with keys loaded via macOS Keychain integration
• SSH config: Well-configured with UseKeychain yes, AddKeysToAgent yes, and multiple IdentityFile entries
• Keys loaded: 3 keys in ssh-agent (ED25519 via 1password, RSA webdev key, local RSA)
• SSH_AUTH_SOCK: Set and functional

Issue Reproduction

1. Attempted to use existing encrypted ED25519 key: ~/.ssh/1password.bdmorin.id_ed25519.key
2. Specified full path in Identity File field
3. Got error: Cannot parse privateKey: Encrypted private OpenSSH key detected, but no passphrase given
4. Attempted workaround with unencrypted key, also failed with key format error

Root Cause Analysis

Claude Desktop is reading key files directly instead of using the running ssh-agent that already has decrypted keys available. This completely bypasses the infrastructure that's already in place (Keychain, agent, SSH config).

Impact

• Users with properly-configured SSH infrastructure have to create credential-sprawl workarounds (separate unencrypted keys)
• Each remote host requires manual authorized_keys management for these workaround keys
• Defeats the purpose of ssh-agent and Keychain management
• Creates security regression (unencrypted keys on disk)

Expected Fix Priority

This should be high priority because:

1. It makes SSH sessions unusable for anyone with standard SSH security practices
2. The workaround requires creating unencrypted keys, which is an anti-pattern
3. Proper SSH clients integrate with ssh-agent out of the box

Confirmed regression — worked in build 1.1.3189, broken in current builds

I can confirm this bug and have identified it as a regression. It worked the first time I tried it when the feature was introduced and it subsequently stopped working. I downloaded build 1.1.3189 (Feb 17) via Uptodown, launched it offline to prevent auto-update, and was able to connect to an SSH server with no issues. Current builds fail with the same error described in this issue.

Environment

• macOS (Apple Silicon)
• Keys: passphrase-protected id_ed25519 and id_rsa, both loaded and unlocked in macOS ssh-agent
• ssh-add -l confirms both keys are available
• $SSH_AUTH_SOCK is identical across all terminals and inside Claude Desktop
• Regular terminal SSH works perfectly

Real-world consequence: server lockout

This bug caused me to get locked out of a remote server. Because the app repeatedly attempts to authenticate with multiple keys and fails on each one, clicking "Try again" in the error message rapidly burns through the server's MaxAuthTries limit (default 6).

Anyone connecting to a server with rate limiting or intrusion detection should be aware that this bug can lock you out.

Summary

| Build | SSH Status |
|-------|-----------|
| 1.1.3189 (Feb 17) | ✅ Works — connects successfully |
| Current builds (1.1.3830+) | ❌ Fails — encrypted key parse error |

The regression was likely introduced somewhere between builds 1.1.3189 and 1.1.3830 (roughly Feb 17–21).

Got the same issue, tried using ssh agent in Powershell, but does not work, but strangely enough, even if I create a new key without password protection, then create a new SSH remote connection with that key, i get the same error message.
The only way to get the new non-password-protected key to work is by uninstalling and reinstalling the windows app.

Got the similar problem as "Cannot parse privateKey: Encrypted private OpenSSH key detected, but no passphrase given Try again" in windows 11, Claude 1.1.4328 (d8e391).

Same issue for Claude 1.1.4498 (24f768) 2026-02-26T19:47:09.000Z on MacOSX

When I connected to mac it said Darwin was not supported.

Unsupported remote platform: darwin. Only Linux hosts are supported for SSH connections. Try again

When I try WSL2 I get

Cannot parse privateKey: Encrypted private OpenSSH key detected, but no passphrase given Try again

Still a problem. Running Claude 1.1.5368 (d12d02) 2026-03-05T17:29:33.000Z

Error:

Cannot parse privateKey: Encrypted private OpenSSH key detected, but no passphrase given Try again

Anyone found a workaround yet?

Anyone found a workaround yet?

Im planning on installing keys on my hosts that dont have passphrases until its fixed.

> Anyone found a workaround yet? Im planning on installing keys on my hosts that dont have passphrases until its fixed.

Already tried, didn't work for me

Got the same issue on macOS 26.3.1 (25D2128) with Claude 1.1.7203 (034f07) 2026-03-17T17:48:28.000Z.

The only workaround that worked for me was temporarily renaming my default ~/.ssh/id_ed25519, then adding the specific key I actually wanted to use to the SSH agent:

mv ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.backup
mv ~/.ssh/id_ed25519.pub ~/.ssh/id_ed25519.pub.backup
ssh-add ~/.ssh/id_ed25519_my_key

After that, in Claude’s SSH setup I used:

• Host: user@hostname
• Port: 22
• Identity File: left empty

That finally worked for me.

bumping this

it should just work the passphrase protected ssh key that you have added to your keychain agent

On both W11 and Tahoe latest, using 1password and ssh-agent

Claude 1.1.9493 (b58a0b) 2026-03-29T03:33:07.000Z

I am only able to connect with dedicated non password protected keys. I am unable to connect using encrypted keys. Nor will it unlock using decrypted keys loaded in ssh-agent.

It still seems to be broken on Mac OS, can anyone advise me on this?
The workarounds aren't working, the key is already part of the ssh-add agents

It still seems to be broken on Mac OS, can anyone advise me on this? The workarounds aren't working, the key is already part of the ssh-add agents

+1, waiting for resolution for Intel Macs as well

+1, I cannot use Claude Code (Mac OS) because ssh access with key with passphrase is needed. Is this going to be prioritized?

The workaround from @YanPina was the only way I could get this to work. It doesn't seem to matter at all what you put into the "Identity File" field -- even creating a unencrypted key and explicitly putting the path to that key as the identity file doesn't fix the problem.

If your _default_ key is encrypted, you cannot connect.

Cannot parse privateKey: Encrypted private OpenSSH key detected, but no passphrase given 

Still an issue on macOS

Claude 1.569.0 (49894a)
2026-04-02T20:01:42.000Z

Got the same issue on macOS 26.3.1 (25D2128) with Claude 1.1.7203 (034f07) 2026-03-17T17:48:28.000Z. The only workaround that worked for me was temporarily renaming my default ~/.ssh/id_ed25519, then adding the specific key I actually wanted to use to the SSH agent: `` mv ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.backup mv ~/.ssh/id_ed25519.pub ~/.ssh/id_ed25519.pub.backup ssh-add ~/.ssh/id_ed25519_my_key `` After that, in Claude’s SSH setup I used: Host: user@hostname Port: 22 * Identity File: left empty That finally worked for me.

This works great, but this bug should still be fixed as it means we wan't use our default key to connect to anything anymore without going and renaming the file again. Huge pain!

Hey @anthropics, this bug has been active for nearly a month without a response or a fix.
Please prioritize fixing your software, especially since you’ve blocked other agent harnesses for subscribers.

This is very poor customer service.

The issue is a bit more general - Claude Code is trying to read all keys in ~/.ssh and fails if any key in the directory is encrypted.

Instead of doing...whatever you're currently doing, please use a standard ssh library. OpenSSH is 25 years old, you'll never be able to support all possible workflows (cert authorities, Yubikeys, etc) with an in-house solution.

Confirmed fix for macOS + Tailscale setup (Apr 2026)

Adding a working solution for those still stuck. The core issue for me: the key generated by ssh-keygen without explicit -N "" can be misread by ssh2 as encrypted even when it isn't. Additionally, ssh-copy-id silently skips installing the new key if your ssh-agent has an old key cached that's already in the remote's authorized_keys.

Environment: MacBook Air (client) → Mac mini over Tailscale, Claude Desktop 1.1.8629, Claude Code CLI 2.1.109

Prerequisites first

1. Make sure claude is in PATH for non-interactive SSH on the remote (the app spawns a non-login shell). If it's in ~/.local/bin, terminal SSH works but the Desktop app can't find it. Fix on the remote machine:

``bash
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshenv
`
Verify: ssh user@remote 'claude --version'` — must work before touching the Desktop app.

1. Remote must be signed into the same Anthropic account: claude /login on the remote.

The fix (run on client/laptop)

# Back up existing key
mv ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.bak
mv ~/.ssh/id_ed25519.pub ~/.ssh/id_ed25519.pub.bak

# Generate fresh key with EXPLICIT empty passphrase
ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519 -C "my-laptop"

# Force-install new pubkey on remote (-f bypasses agent cache, -i targets the new file)
ssh-copy-id -f -i ~/.ssh/id_ed25519.pub user@remote-ip

# Verify passwordless before trying the app
ssh -i ~/.ssh/id_ed25519 user@remote-ip 'claude --version'

The -f -i flags on ssh-copy-id are critical — without them, if your ssh-agent has the old key cached and it's already in authorized_keys, the command silently skips the new key and says "all keys already installed."

Desktop app dialog settings

• SSH Host: user@100.x.x.x (Tailscale IP — MagicDNS may not resolve correctly in the app's SSH context)
• SSH Port: blank (22)
• Identity File: blank or explicit path to ~/.ssh/id_ed25519

Red herrings that wasted hours

• [sessions-bridge] Poll error, backing off in main.log — unrelated, that's the Remote Control feature polling Anthropic's cloud, not SSH
• Signing out/in of Claude Desktop — doesn't fix the key parsing bug
• Setting Identity File explicitly in the dialog — ssh2 still scans default keys regardless
• Tailscale connectivity — if ssh user@host 'claude --version' works in terminal, Tailscale isn't the issue

Hope this saves someone a few hours.

It works for me since this version. No extra configuration for SSH needed.

<img width="432" height="472" alt="Image" src="https://github.com/user-attachments/assets/c177776a-412a-426a-8ddd-df03140953a6" />

I can confirm that it works now using the 1password SSH agent.

Claude for Mac
Version 1.3109.0 (35cbf6)

Same issue on windows 11.
2026-04-17 17:38:03 [info] [SSH2Connection] Skipping identity file ~/.ssh/id_ed25519: Encrypted private OpenSSH key detected, but no passphrase given
Classic, they shout about a new feature everyone wants to use, and then fail to fix the months-long bugs preventing the average developer from using said feature...

Running this powershell export to force node ssh2 to use openssh keys properly:

[Environment]::SetEnvironmentVariable('SSH_AUTH_SOCK', '\\.\pipe\openssh-ssh-agent', 'User')

I can confirm that it works now using standard Mac SSH key agent

Claude for Mac
Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z

Confirmed working for encrypted keys in directory.

Still not working for certificate authorities. Specifically, if I have ~/.ssh/key, ~/.ssh/key.pub, and ~/.ssh/key-cert.pub, Claude doesn't send the cert file to the server.

This is an issue because it requires special-casing agent sandboxes to use authorized_keys instead of AuthorizedPrincipalsFile.

Additionally, please present the client side error to the user. Currently, Claude only shows "Connection failed. Try again?", which is opaque and requires debugging connection errors on the server side.

Confirmed working for encrypted keys in directory. Still not working for certificate authorities. Specifically, if I have ~/.ssh/key, ~/.ssh/key.pub, and ~/.ssh/key-cert.pub, Claude doesn't send the cert file to the server. This is an issue because it requires special-casing agent sandboxes to use authorized_keys instead of AuthorizedPrincipalsFile. Additionally, please present the client side error to the user. Currently, Claude only shows "Connection failed. Try again?", which is opaque and requires debugging connection errors on the server side.

2026-04-23 10:01:31 [info] [SSH2Connection] Skipping identity file ~/.ssh/second_id_ed25519: Encrypted private OpenSSH key detected, but no passphrase given

I have already added second_id_ed25519 to ssh-agent and macOS keychain, but It doesn't work : (

Works for me too for some time.
I have all the ssh configs related to jump proxy, custom port and so on done in ~/.ssh/config
The ssh keys are encrypted in my 1password vault which is accessible only with the TouchID.