cargo: failed to authenticate when downloading repository

Leave it here to help somebody… I had a similar issue with ssh: dependency, but fixed it by starting ssh agent:

eval `ssh-agent -s`
ssh-add
cargo build

I had the same setup in a global ~/.gitconfig

[url "ssh://git@github.com/"]
	insteadOf = https://github.com/

This is a somewhat common for few reasons. One is to deal with git submodules in a unified way: so you don’t need to handle https::/ vs git@ differently.

Running ssh-agent as @DenisKolodin suggested, didn’t work for me. The only way to workaround it was to remove this global config.

Just in case, somebody will land here from google with the same errors (https://github.com/rust-lang/crates.io-index), and above ☝️ approaches didn’t work, cause you have complicated auth to git from your machine, for example 🤷
add to your cargo config.toml:

[net]
git-fetch-with-cli = true

The following links from the docs saved my days: https://doc.rust-lang.org/cargo/appendix/git-authentication.html?highlight=auth#git-authentication https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Workaround from https://github.com/rust-lang/cargo/issues/2078#issuecomment-434388584:

To apply globally, add this to ~/.cargo/config:

[net]
git-fetch-with-cli = true

For future travellers this is what I use:

# force authentication to use SSH rather than HTTPS.
# be aware this affects everything that tries to use git.
# for example, vim (and other tools) will try to clone plugins using SSH.
#
# git config --global --add url."git@github.com:".insteadOf "https://github.com/"
[url "git@github.com:"]
  insteadOf = https://github.com/

# avoid issues where the cargo-edit tool tries to clone from a repo you do not have WRITE access to.
# we already use SSH for every github repo, and so this puts the clone back to using HTTPS.
[url "https://github.com/rust-lang/crates.io-index"]
  insteadOf = https://github.com/rust-lang/crates.io-index

# avoid issues where the `cargo audit` command tries to clone from a repo you do not have WRITE access to.
# we already use SSH for every github repo, and so this puts the clone back to using HTTPS.
[url "https://github.com/RustSec/advisory-db"]
  insteadOf = https://github.com/RustSec/advisory-db

I had the same setup in a global ~/.gitconfig

[url "ssh://git@github.com/"]
	insteadOf = https://github.com/

This is a somewhat common for few reasons. One is to deal with git submodules in a unified way: so you don’t need to handle https::/ vs git@ differently.

Running ssh-agent as @DenisKolodin suggested, didn’t work for me. The only way to workaround it was to remove this global config.

I think part of your problem was that your ~/.gitconfig has the wrong replacement, as @DenisKolodin has mentioned, it is:

[url "git@github.com:"]
  insteadOf = https://github.com/

Not:

[url "ssh://git@github.com/"]
	insteadOf = https://github.com/

With the @DenisKolodin replacement rule, eval ssh-agent -sandssh-add` work.

it seems work after i comment

[url "git@github.com:"]
        insteadOf = https://github.com/

@HaoZeke it didn’t fix my issue even if I use

[url "git@github.com:"]
        insteadOf = https://github.com/

Leave it here to help somebody… I had a similar issue with ssh: dependency, but fixed it by starting ssh agent:

eval `ssh-agent -s`
ssh-add
cargo ...

The problem appear when I set a dependencies and run cargo build, so，after run ssh-add，you shou run cargo build to instead of cargo ...

export CARGO_NET_GIT_FETCH_WITH_CLI=true

Just leaving another thing that helped me after none of the other things worked - I had multiple SSH keys saved in rsa and ed25519 files named id_rsa, id_ed25519 along with their public files in the .ssh folder. By making .ssh use the ed25519 key explicitely, I was able to solve the problem. This is how my .ssh/config file looks like -

Host github.com
 HostName github.com
 IdentityFile ~/.ssh/id_ed25519

Not a great experience for Rust newcomers… It took a while to find this seemingly hacky solution while following the documentation.

Leave it here to help somebody… I had a similar issue with ssh: dependency, but fixed it by starting ssh agent:

eval `ssh-agent -s`
ssh-add
cargo build

Lifesaver! phew

Leave it here to help somebody… I had a similar issue with ssh: dependency, but fixed it by starting ssh agent:

eval `ssh-agent -s`
ssh-add
cargo ...

Mark

oh good point, I was not aware of this difference.

FWIW, there is some work happening in libgit2 that would allow to avoid all such problems all together https://github.com/libgit2/libgit2/pull/4667