[BUG] Desktop SSH: dead-end password prompt on key-only hosts (nonexistent identity file silently ignored, no default key fallback)

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 1 comment · opened Aug 4, 2026

What's Wrong?

Starting a task on a remote SSH connection to a key-only host shows an "SSH password required" dialog that can never succeed. The target sshd only advertises publickey ("Authentications that can continue: publickey" in ssh -v), so every password typed into the dialog is rejected. The same host connects instantly with ssh <alias> from a terminal.

Three gaps in the desktop app's key resolution combine to produce this dead end:

  1. A nonexistent Identity File path is accepted and silently ignored. With ~/.ssh/id_rsa entered on a machine whose only key is ~/.ssh/id_ed25519, the connection saves without complaint and behaves as if no key was configured. No validation at save time, no "identity file not found" at connect time.
  2. Leaving Identity File empty does not use the default SSH key. The field's helper text says "Leave empty to use default SSH key or SSH config", and the desktop docs say the same. In practice an empty field only consults ssh-agent via SSH_AUTH_SOCK. When the agent has no identities loaded (the default on a fresh macOS login when keys were never ssh-added), no key is offered at all. The OpenSSH client falls back to the standard on-disk identities (~/.ssh/id_ed25519, ~/.ssh/id_rsa, ...); the app does not.
  3. The password dialog appears even though the server does not accept passwords. The server declares its permitted auth methods before any attempt is made, so the app has enough information to show an actionable error ("this server only accepts public-key authentication; no usable key was found") instead of a prompt that is guaranteed to fail.

What Should Happen?

With Identity File empty, the app resolves the key the way ssh does: agent identities, then IdentityFile directives from the matched ~/.ssh/config block, then the default on-disk identities. With Identity File set to a path that does not exist, the app surfaces an error naming the path. A password prompt only appears when the server actually permits password authentication.

Error Messages/Logs

$ ssh-add -l
The agent has no identities.

$ ssh -v remote exit 2>&1 | grep -E "Authentications|Offering|accepts"
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/<user>/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Server accepts key: /Users/<user>/.ssh/id_ed25519 ED25519 SHA256:...

Terminal ssh succeeds via on-disk default key discovery. The desktop app, given the identical alias, shows "SSH password required".

Steps to Reproduce

Setup: macOS host whose ~/.ssh/config contains a plain alias (Host remote with HostName and User, no IdentityFile directive), a single key at ~/.ssh/id_ed25519, target sshd with PasswordAuthentication no.

  1. Confirm ssh-add -l reports "The agent has no identities."
  2. Confirm ssh remote connects from a terminal without prompting.
  3. In the desktop app, add an SSH connection with Host remote. Leave Identity File empty, or set it to ~/.ssh/id_rsa (nonexistent).
  4. Start a task on that connection.
  5. "SSH password required" dialog appears; any input fails.

Workaround: ssh-add --apple-use-keychain ~/.ssh/id_ed25519, after which the empty-field configuration connects.

Related: #83017 (zero keys offered, Windows), #75990 (IdentitiesOnly/Identity File handling), #46273 (agent/hardware key support), #25661 (identity file ignored), #39752 (all auth methods failed).

Environment

  • Claude Code Version: 2.1.221 (Claude Code)
  • Desktop app: 1.24012.11 (macOS)
  • Operating System: macOS 26.5.2
  • Platform: Anthropic API
  • Terminal/Shell: Desktop app (not terminal)
  • Is this a regression?: I don't know

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗