cargo update demands an ecdsa key for github.com

[intelfx]

Problem

Since recently, cargo update started to complain about an unknown SSH host key for github.com, suggesting that github's ecdsa key be added to known_hosts:

$ cargo update
    Updating crates.io index
error: failed to get `anyhow` as a dependency of package `electrs v0.9.13 (/home/intelfx/devel/ext/electrs)`

Caused by:
  failed to load source for dependency `anyhow`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  error: unknown SSH host key
  The SSH host key for `github.com` is not known and cannot be validated.

  To resolve this issue, add the host key to the `net.ssh.known-hosts` array in your Cargo configuration (such as /home/intelfx/.cargo/config) or in your OpenSSH known_hosts file at /home/intelfx/.ssh/known_hosts

  The key to add is:

  github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=

  The ECDSA key fingerprint is: SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
  This fingerprint should be validated with the server administrator that it is correct.

  See https://doc.rust-lang.org/stable/cargo/appendix/git-authentication.html#ssh-known-hosts for more information.

(I traced this down to my local configuration that disables ECDSA host key algorithms in HostKeysAlgorithm, thus causing regular OpenSSH client to automatically remove any ECDSA keys from known_hosts, together with a configuration that rewrites HTTPS github.com URLs to ssh ones.)

However, I have other perfectly valid keys for github.com in my known_hosts. cargo should use them instead of demanding a host key in a specific cryptographic system and failing if one is not available.

Steps

1. Create an empty ~/.ssh/known_hosts and add GitHub keys to it, skipping the ECDSA key:

   $ ssh-keyscan github.com | grep -v ecdsa > .ssh/known_hosts
   

2. Make any cargo request that contacts GitHub over ssh (e. g. add an insteadOf statement in your .gitconfig, drop the registry index cache and do a search):

   $ cat >>~/.gitconfig <<EOF
   [url "[email protected]:"]
          insteadOf = git://github.com/
          insteadOf = https://github.com/
   EOF
   $ rm -rf ~/.cargo/registry
   $ cargo search syn
   

Possible Solution(s)

Depending on the actual implementation details: either do not force cargo's built-in SSH client to use a specific cryptosystem for verifying host keys, or do not make it a hard error if a specific host key is not available (but others are).

Notes

No response

Version

cargo 1.68.2
release: 1.68.2
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 8.0.1 (sys:0.4.59+curl-7.86.0 system ssl:OpenSSL/3.0.8)
os: Arch Linux Rolling Release [64-bit]

[est31]

The error you are getting is likely since #11556 , but before that PR it probably also just used ECDSA keys, just not verifying them at all. I think the problem is that cargo does not read HostKeysAlgorithm.

[weihanglo]

I guess it's also because libgit2 only gets one remote key type at a time, and the git_transport_certificate_check_cb is also called only once with a single key type. In contrast, git CLI seems to delegate ssh connnection to native ssh command.

It seems a bit difficult to fix in either Cargo or git2-rs. I see it as an issue of upstream libgit2.

[ehuss]

libssh2 does not read OpenSSH config files at all. If you need extra SSH configuration support, I recommend using net.git-fetch-with-cli = true.

[intelfx]

@ehuss The issue is not with OpenSSH config files, but rather with the choice of the host key algorithm by the ssh client embedded in cargo. I do not need any extra SSH configuration support.

@est31 Likewise, the only reason I mentioned HostKeysAlgorithm was the explanation of how I got my system into a state that reproduces the greater issue.

[ehuss]

Ah, I see. This should be fixed when cargo gets updated on nightly (should be within a few days). The SSH handler was not setting the preferred host key algorithm before negotiation, so it was using whatever the server preferred. The next update will use the known_hosts file to determine which algorithms are preferred.

[weihanglo]

The fix is available on nightly since nightly-2023-04-12. Close as fixed. Thanks!