Repository navigation
Accept unknown ssh host keys on first connect - #119
Conversation
gliff spawns ssh without a terminal, so the host-key prompt for a host not yet in known_hosts can't be answered and the connection fails until the user has ssh'd in manually once. Pass StrictHostKeyChecking=accept-new: new keys are recorded as if "yes" was typed, changed keys still fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 [High impact] The PR changes host-key trust for Gliff's SSH connections. The PR still needs to preserve explicitly configured SSH trust settings before merging. Findings
SummaryThe PR accepts unknown SSH host keys on first connection.
Reviews (2) · Last reviewed commit: "Respect StrictHostKeyChecking set in ssh..." · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| .arg("-o") | ||
| .arg("StrictHostKeyChecking=accept-new") |
There was a problem hiding this comment.
If a user sets StrictHostKeyChecking=yes in their SSH config, this command-line option overrides it and silently accepts unknown host keys. An attacker intercepting the first connection can then supply a key that the client accepts and saves.
The promised override through ssh_args is unavailable in the app: ssh_endpoint leaves it empty, and the CLI has no SSH-options flag. Preserve explicit SSH trust settings or provide a working user override.
How this was verified: Every app-created SshTarget leaves ssh_args empty, while the command-line StrictHostKeyChecking=accept-new takes precedence over SSH config.
A command-line -o overrides ssh config, so accept-new silently weakened a user's StrictHostKeyChecking=yes. Ask ssh -G for the effective value and only add accept-new when it is still the default "ask". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gliff spawns ssh with no terminal attached, so for a host that isn't in
known_hostsyet the "Are you sure you want to continue connecting?" prompt can't be answered and the connection fails. Until now the workaround was tossh <host>in a terminal once first.This passes
-o StrictHostKeyChecking=accept-newto ssh:known_hostsand the connection goes ahead, the same as typing "yes".ssh -Gfor the host first and only addsaccept-newwhen the effectiveStrictHostKeyCheckingis still the defaultask, so a configuredyes(or anything else) is left alone.scripts/check.shpasses. Not yet tried against a real host that's missing fromknown_hosts.🤖 Generated with Claude Code