Offer every default key, not just the first

[ralyodio]

seed1 was my bug, not the host's

Reported as "still can't connect to seed1", after I had told the user it was the host refusing our credentials. It was not. ssh seed1 from a terminal connects as ubuntu, and the reason DiskPush could not is that it never offered the key that host accepts:

ssh -i ~/.ssh/id_ed25519 seed1  ->  Permission denied (publickey,password)
ssh -i ~/.ssh/id_rsa     seed1  ->  RSA OK

The default-key fallback added in 0.2.5 took the first identity that exists, and ssh2's privateKey holds exactly one. On a machine with both keys that is always id_ed25519, so a host accepting only id_rsa was shown one key, refused it, and the connection ended — while ssh(1), which offers each identity in turn, walked straight in.

The fix

Agent authentication now hands ssh2 an ordered authHandler: the agent first when one is found, then every default identity that exists, in ssh's order (id_ed25519, id_ecdsa, id_rsa, id_dsa). ssh2 tries them in sequence, which is what "the way ssh does it" was supposed to mean in the first place.

An explicitly configured key path is untouched — that is a deliberate choice by the user and stays a single key.

Verified against the host that reported it

Before:

=== seed1  ubuntu@seed1.h4kr.com:22  auth=agent
  connect -> [auth] SSH authentication was rejected by seed1.h4kr.com.

After:

=== seed1  ubuntu@seed1.h4kr.com:22  auth=agent
  home: 23 entries

seed2 still lists 51 entries and still resolves data -> /mnt/vdb as a directory, so the 0.2.6 symlink work is intact.

• pnpm test — 327 passed (4 new)
• pnpm typecheck — clean

🤖 Generated with Claude Code

https://claude.ai/code/session_01GTQ3RzTAey9nT6r1kbGBCd