## Bug: Authentication fails for any passphrase-protected private key

[devdracon]

Summary
Connecting to a host fails with "authentication failed" whenever the configured
private key is passphrase-protected — regardless of key type (tested with both
RSA and Ed25519). Keys without a passphrase work correctly.

Environment

• OmnySSH: Desktop app (macOS, Apple Silicon)
• macOS version: Tahoe 26.6.2
• OmnySSH version: 1.1.2

Steps to reproduce

1. Generate an Ed25519 key with a passphrase:
   ssh-keygen -t ed25519 -f ~/.ssh/test_key
2. Add the public key to a host's authorized_keys.
3. Add the host in OmnySSH with identity_file pointing to ~/.ssh/test_key.
4. Attempt to connect → authentication fails.
5. Run ssh-keygen -p -f ~/.ssh/test_key and remove the passphrase (empty).
6. Attempt to connect again with the same host config → connection succeeds.

Additional isolation performed

• Confirmed this is not specific to RSA: an RSA key without a passphrase also
  works, and converting an old-format RSA key
  (-----BEGIN RSA PRIVATE KEY-----) to the new OpenSSH format did not change
  the outcome.
• Confirmed the same passphrase works fine with the system ssh binary
  (ssh -i ~/.ssh/test_key user@host), so the passphrase itself is correct.
• File permissions on the private key are 600, owned by the current user.
• macOS system ssh-agent had zero identities loaded during testing
  (ssh-add -l → "The agent has no identities."), ruling out agent
  key-offer-order issues.
• hosts.toml also contains a password field alongside identity_file;
  unclear whether this is intended to hold the key passphrase or a separate
  login password, and whether having both set contributes to the failure.

Expected behavior
OmnySSH should either prompt for / accept the key passphrase interactively
(as the README implies for the desktop app), or clearly document that
passphrase-protected keys are unsupported outside an SSH agent — and ideally
surface a specific error message (e.g. "key requires passphrase") instead of
a generic authentication failure.

Workaround found
Using an unencrypted private key (no passphrase) resolves the issue.