default username used for git clones over ssh is not generally correct

[eminence]

This might be a duplicate of #1851 or #2078 but I can't quite tell. My understanding is that cargo is supposed to use ssh-agent for authentication, but I can't get this to work.

I have a dependency with a git-over-ssh path:

[dependencies.sma_utils]
git = "ssh://gitsrvsim/usr/abaqus60/GITrepo/sma_rust.git"

SSH to this machine is password-less (due to ssh-agent, and not due a .ssh/config file):

$ ssh -o BatchMode=yes gitsrvsim hostname
Permission denied (publickey,gssapi-with-mic,password).
$ ssh-add ~/.ssh/sim_internal
Identity added: /u/users/lxd/.ssh/sim_internal (/u/users/lxd/.ssh/sim_internal)
$ ssh -o BatchMode=yes gitsrvsim hostname
gitsrvsim

But cargo build still fails:

cargo build --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `ssh://gitsrvsim/usr/abaqus60/GITrepo/sma_rust.git`
Unable to update ssh://gitsrvsim/usr/abaqus60/GITrepo/sma_rust.git

Caused by:
  failed to fetch into /rd/gen/lxd/do_not_delete/multirust/.cargo/git/db/sma_rust-0fec95efab468a0c

Caused by:
  failed to authenticate when downloading repository

Caused by:
  [7/-1] Config value 'credential.helper' was not found

My quick googling suggests that git's credential-helper is primarily used for HTTPS authentication. No one seems to use it for ssh (likely because git can use ~/.ssh/config). My git is not new enough to have the credential-helper subsystem.

So I can't really tell where the problem lies. Currently running `cargo 0.9.0-nightly (4739ba1 2016-02-16)

Thanks!

[alexcrichton]

Yeah I think that this is a dupe, but I'm not 100% sure. Can you try specifying the full URL instead of just gitsrvsim? That .ssh/config alias definitely won't be read by us (or libgit2) I believe

[eminence]

gitsrvsim is not an alias. It's resolvable when you tack on a suffix from /etc/resolv.conf. So using the fully qualified domain name in Cargo.toml didn't change anything

[alexcrichton]

Note that we actually don't shell out to git at all, we use libgit2 as a bundled library which implements all the git operations we need. We specifically try a number of authentication strategies here, and I wonder if perhaps SSH_KEY isn't coming through somehow?

Unfortunately there's not a lot of debug logging around there, so I'm curious:

• Is there a way for me to reproduce this locally?
• Would you be willing to try out some debug builds of Cargo to see if it works?

[eminence]

I would be happy to try out any and all debug builds!

I do believe this can be reproduced (I don't think there is anything unique about this particular machine). Let me try to put together a repo script. I'll get back to you on this.

[eminence]

• Step 0 (optional) : Configure machine for pubkey authentication only. Actually, disabling keyboard-interactive is not required to reproduce this, but it can be useful to show that your ssh agent is working.

I'm sure you know how to do this, but for anyone else following along at home, the steps are documented here https://gist.github.com/eminence/93aab78611b9279d8b35

• Create a project that will be the dependency. Add a trivial thing to it, so that it'll be git-cloneable

achin@bigbox ~/tmp/01 $ cargo init mydep 
achin@bigbox ~/tmp/01 $ cd mydep/
achin@bigbox ~/tmp/01/mydep $ echo "fn foo() -> u8 { 4 }" > src/lib.rs 
achin@bigbox ~/tmp/01/mydep $ git add Cargo.toml src/lib.rs 
achin@bigbox ~/tmp/01/mydep $ git commit -m "initial commit"
[master (root-commit) 77cfe74] initial commit
 2 files changed, 7 insertions(+)
 create mode 100644 Cargo.toml
 create mode 100644 src/lib.rs

• Create a new project that will depend on mydep.

achin@bigbox ~/tmp/01 $ cargo new --bin myapp
achin@bigbox ~/tmp/01 $ cd myapp/
achin@bigbox ~/tmp/01/myapp $ vim Cargo.toml 
achin@bigbox ~/tmp/01/myapp $ cat Cargo.toml 

[package]
name = "myapp"
version = "0.1.0"
authors = ["Andrew Chin <achin@eminence32.net>"]

[dependencies]

[dependencies.mydep]
git = "ssh://localhost/storage/home/achin/tmp/01/mydep"

• Now try to build:

achin@bigbox ~/tmp/01/myapp $ cargo build --verbose
    Updating git repository `ssh://localhost/storage/home/achin/tmp/01/mydep`
Unable to update ssh://localhost/storage/home/achin/tmp/01/mydep

Caused by:
  failed to fetch into /storage/home/achin/.multirust/toolchains/nightly/cargo/git/db/mydep-f9f860195307f1db

Caused by:
  failed to authenticate when downloading repository

Caused by:
  [7/-1] Config value 'credential.helper' was not found

• Observe that a plain git-clone is successful:

achin@bigbox ~/tmp/01/myapp $ git clone ssh://localhost/storage/home/achin/tmp/01/mydep
Cloning into 'mydep'...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5/5), done.
Checking connectivity... done.

[alexcrichton]

Awesome, thanks @eminence! There's two issues at play here:

• The root cause is the username we attempt to connect with via ssh. Without any extra information we fall back to the username of git, but that's probably the wrong username for you (it was for me)
• The error message here is quite bad! I'm working on a PR to fix that.

[eminence]

Ah ha!

Yes, explicitly specifying a username works! However, this is not ideal, since the username that I need to access "localhost" (or "gitsrvsim") is not the username that you need to access "localhost" or ("gitsrvsim"). Perhaps if no username is specified, default to the OS user name (and if that can't be determined, then fallback to git) ?

[alexcrichton]

Hm unfortunately libgit2 provides a kinda wacky interface to interacting with authorizations, but I think we could track something like that, yeah.