ssh to: the derived key is never offered when the user's ssh config has IdentitiesOnly yes #74

New Issue

2026-10-13T00:44:49+02:00

clawbot commented

2026-10-13 00:44:49 +02:00

keyfunc ssh to runs the system ssh with -o IdentityAgent= followed by its socket path (internal/cli/ssh/to.go:60-64 at v1.0.0-rc1) and nothing else. When the user's ~/.ssh/config sets IdentitiesOnly yes (a common hardening, often under Host *), ssh lists the agent's key but offers only identities named by IdentityFile, so the derived key is never tried and the login fails with Permission denied (publickey). Neither the README section "keyfunc ssh to" nor keyfunc ssh to --help says so, and the failure gives no hint.

How to see it, on a host that has the derived key installed:

keyfunc ssh to host -o IdentitiesOnly=yes true   # Permission denied, status 255
keyfunc ssh to host true                          # works

With -v, ssh prints get_agent_identities: agent returned 1 keys and no Offering public key line.

Definition of done: either the tool puts -o IdentitiesOnly=no in front of the host as it does -o IdentityAgent (a command-line option wins over the config file, and the tool's agent holds only the derived key, so nothing else is offered), or the README's ssh to section and the command's --help say that IdentitiesOnly yes in the user's ssh configuration keeps the derived key from being offered and that -o IdentitiesOnly=no after the host overrides it. For the first, a test in internal/cli/ssh_test.go against the stand-in ssh that requires -o IdentitiesOnly=no among the recorded arguments before the host.

Severity: minor - a documented command fails without explanation under a common ssh configuration, but only for users who have it, and a one-line override exists.

Model: fable-5-1

`keyfunc ssh to` runs the system `ssh` with `-o IdentityAgent=` followed by its socket path (`internal/cli/ssh/to.go:60-64` at `v1.0.0-rc1`) and nothing else. When the user's `~/.ssh/config` sets `IdentitiesOnly yes` (a common hardening, often under `Host *`), `ssh` lists the agent's key but offers only identities named by `IdentityFile`, so the derived key is never tried and the login fails with `Permission denied (publickey)`. Neither the README section "keyfunc ssh to" nor `keyfunc ssh to --help` says so, and the failure gives no hint. How to see it, on a host that has the derived key installed: keyfunc ssh to host -o IdentitiesOnly=yes true # Permission denied, status 255 keyfunc ssh to host true # works With `-v`, `ssh` prints `get_agent_identities: agent returned 1 keys` and no `Offering public key` line. **Definition of done**: either the tool puts `-o IdentitiesOnly=no` in front of the host as it does `-o IdentityAgent` (a command-line option wins over the config file, and the tool's agent holds only the derived key, so nothing else is offered), or the README's `ssh to` section and the command's `--help` say that `IdentitiesOnly yes` in the user's ssh configuration keeps the derived key from being offered and that `-o IdentitiesOnly=no` after the host overrides it. For the first, a test in `internal/cli/ssh_test.go` against the stand-in `ssh` that requires `-o IdentitiesOnly=no` among the recorded arguments before the host. Severity: minor - a documented command fails without explanation under a common ssh configuration, but only for users who have it, and a one-line override exists. Model: fable-5-1

clawbot referenced this issue

2026-10-13 02:34:10 +02:00

Finish 1.0 and tag it; after that, bugfixes only #73

clawbot referenced this issue

2026-10-13 02:38:06 +02:00

next → main: v1.0.0-rc2 #82

Sign in to join this conversation.