clone: SSH clone fails when host key is not in ~/.ssh/known_hosts (no interactive fingerprint verification like git)

[genedna]

Description

When cloning a repository over SSH with libra clone, the command fails immediately if the remote host's key fingerprint is not already present in ~/.ssh/known_hosts:

…/genedna/data ❯ libra clone git@github.com:libra-tools/libra.git
Connecting to git@github.com:libra-tools/libra.git ...
fatal: SSH host key could not be verified

Hint: verify the host fingerprint through a trusted provider console or another trusted channel before manually updating ~/.ssh/known_hosts; alternatively make a separate interactive SSH connection using the repository SSH user, host and port, and compare the displayed fingerprint before accepting it; review ssh.strictHostKeyChecking

The user is forced to fix this outside of libra — either by manually editing ~/.ssh/known_hosts, or by running a separate git clone / ssh command first so that OpenSSH adds the host key. After the host key exists in known_hosts, libra clone works fine.

Steps to Reproduce

1. Ensure github.com is not present in ~/.ssh/known_hosts (e.g. on a fresh machine/container).
2. Run:

   libra clone git@github.com:libra-tools/libra.git
   

3. The command aborts with fatal: SSH host key could not be verified.

Actual Behavior

libra clone refuses to continue and provides only a hint telling the user to verify the fingerprint manually and update known_hosts themselves. There is no interactive verification flow, so first-time use on a new machine is broken out of the box.

Expected Behavior (parity with git)

git clone handles this interactively via OpenSSH, which is the behavior libra should match:

…/genedna/data ✗ git clone git@github.com:libra-tools/libra.git
Cloning into 'libra'...
The authenticity of host 'github.com (198.18.0.10)' can't be established.
ED25519 key fingerprint is: SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
remote: Enumerating objects: 74565, done.
...

That is:

1. Display the host key fingerprint and ask the user to confirm (yes/no/[fingerprint]).
2. On acceptance, persist the key to ~/.ssh/known_hosts ("Permanently added ... to the list of known hosts") and proceed with the clone.
3. On rejection, abort the clone without modifying known_hosts.

Proposed Improvement

Make the SSH host key verification flow in libra clone (and other SSH-based operations such as push/fetch) equivalent to git's interactive behavior:

• When the host key is unknown, prompt the user in the terminal to verify and accept/reject the fingerprint, instead of failing hard.
• On acceptance, write the accepted key to ~/.ssh/known_hosts (TOFU, trust-on-first-use) so subsequent operations succeed non-interactively.
• Respect the standard ssh.strictHostKeyChecking / SSH configuration semantics (yes/no/ask/accept-new) so users who want strict verification or fully non-interactive operation can configure it explicitly.
• Optionally, offer to compare the presented fingerprint against the well-known fingerprints published by the provider (e.g. GitHub's SSH host key fingerprints) to help users verify out-of-band.

With this change, a fresh libra clone git@github.com:libra-tools/libra.git on a new machine would work with a single interactive confirmation, just like git clone.

[genedna]

Related issues

This issue relates to the following open issues (cross-linked):

• remote/fetch/pull/push vs git: remote add doesn't write default fetch refspec, pull <remote>/<branch> resolver misses fetched refs, no unrelated-histories hint on pull, local-path push unsupported, credential requires repo vault, rerere remaining missing #480: SSH host-key verification is a network-transport + credential concern; remote/fetch/pull/push vs git: remote add doesn't write default fetch refspec, pull <remote>/<branch> resolver misses fetched refs, no unrelated-histories hint on pull, local-path push unsupported, credential requires repo vault, rerere remaining missing #480's umbrella scope explicitly lists HTTPS/SSH/git:// transport and credential helper behavior
• clone: local-path clone of a 3,200-commit repository hangs at "Fetching objects" with 0% CPU #496: same clone family; clone: local-path clone of a 3,200-commit repository hangs at "Fetching objects" with 0% CPU #496 is a local-path clone hang while clone: SSH clone fails when host key is not in ~/.ssh/known_hosts (no interactive fingerprint verification like git) #560 is SSH transport — different root cause but both fail under the clone/receive path
• clone: --depth from a local source creates a repo whose HEAD cannot be traversed (log dies, fsck silently passes); bundle sources rejected; --bare still writes a working tree; depth tests don't assert shallowness #474: clone family (clone: --depth from a local source creates a repo whose HEAD cannot be traversed (log dies, fsck silently passes); bundle sources rejected; --bare still writes a working tree; depth tests don't assert shallowness #474 shallow/bundle/bare/mirror); clone: SSH clone fails when host key is not in ~/.ssh/known_hosts (no interactive fingerprint verification like git) #560 is a clone-over-SSH transport gap
• libra clone: fatal: remote branch 'B' not found in upstream origin; rejects the --recurse-submodules option/argument; rejects the --bundle-uri option/argument #530: clone family new 0.23.49 gaps; clone: SSH clone fails when host key is not in ~/.ssh/known_hosts (no interactive fingerprint verification like git) #560 adds another clone/transport failure

Linked to improve discoverability and triage of shared transport/credential root causes.