cargo: Support .ssh/config for specifying keys if ssh-agent fails

Update (2018-10-30)

There’s a workaround below for those interested:

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

Original description

When cloning an SSH repository the only currently supported method of authenticating is picking up a key through ssh-agent. This can fail, however, for example if it’s just not running! Cargo should support parsing .ssh/config and/or otherwise having a reasonable fallback in trying to find public/private keys on the filesystem. Currently libssh2 does not support this, so an external library will be required.

As to the rationale for this issue, apparently when using CircleCI with a deploy key it will add this to ~/.gitconfig:

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

Which means that clones of the index will be rewritten to git@github.com (SSH) instead of HTTPS. The ssh-agent apparently also isn’t running, so it relies on ~/.ssh/config to point SSH at the right keys, which Cargo isn’t itself looking at.

About this issue

  • Original URL
  • State: open
  • Created 9 years ago
  • Reactions: 52
  • Comments: 42 (18 by maintainers)

Commits related to this issue

Most upvoted comments

As an update for those following this issue, Cargo now supports global .cargo/config configuration that looks like:

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

which will instruct Cargo to fetch git repositories with the git CLI rather than with libgit2. Using this will read .ssh/config because that’s what git does.

You should be able to set it via an environment variable:

$ env CARGO_NET_GIT_FETCH_WITH_CLI=true cargo install --git ssh://...

It turns out to be pretty nontrivial to emulate ssh’s behavior. We’d need to write a parser for ~/.ssh/config for example.

I think a more promising route is to support fetches by shelling out to the git binary if it’s available. We’d use git2 for everything else and still support git2-based fetches if git isn’t present, but it seems better to just use git rather than trying to emulate its exact authentication behavior.

Is there a reason this is stalled? The current behaviour (ssh-agent being required) is very frustrating.

Please also support custom SSH agents. I use my password manager to handle my SSH keys and as such my SSH config looks like this:

Host *
	IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_github.pub
    IdentitiesOnly yes

What’s more, I use https to ssh rewriting to support private repos in go projects, and my global git config is:

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

This setup absolutely doesn’t work with cargo.

As an update for those following this issue, Cargo now supports global .cargo/config configuration that looks like:

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

Is there any way to do this on the command line?

cargo install --git-fetch-with-cli --git ssh://...

export CARGO_NET_GIT_FETCH_WITH_CLI=true

You need to install git in the docker container.

Using ssh access without the ssh-agent running seems like a fairly unusual setup to be using intentionally; I ran into this issue because I just forgot to start up the agent on OS X. Perhaps the hint message pointing users to net_git_fetch_with_cli could also suggest starting up ssh-agent as an alternative?

@alexcrichton thank you! That works.

@alexcrichton I fetch failed by the following error when using the git client

fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
error: failed to load source for a dependency on `cargo`

Caused by:
  Unable to update https://github.com/rust-lang/cargo

Caused by:
  failed to clone into: /Users/wangsijie/.cargo/git/db/cargo-e7ff1db891893a9e

Caused by:
  process didn't exit successfully: `git fetch --tags --quiet 'https://github.com/rust-lang/cargo' 'refs/heads/*:refs/heads/*'` (exit code: 128)

I just create a new crate dependent on cargo

[dependencies]
cargo = { git = "https://github.com/rust-lang/cargo" }

My rust version is

rustc 1.31.0-nightly (1cf82fd9c 2018-10-30)

Is there something wrong with my git config?