Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git_clone: error authenticating: failed connecting with agent #335

Closed
pat-s opened this issue Mar 26, 2018 · 9 comments
Closed

git_clone: error authenticating: failed connecting with agent #335

pat-s opened this issue Mar 26, 2018 · 9 comments

Comments

@pat-s
Copy link

@pat-s pat-s commented Mar 26, 2018

OS: Arch Linux

Using git2r in usethis::create_from_github():

Error in git2r::clone(origin_url, normalizePath(repo_path, mustWork = FALSE),  : 
  Error in 'git2r_clone': error authenticating: failed connecting with agent

However, when specifying the credentials explicitly, everything works:

cred <- git2r::cred_ssh_key(
     publickey = "~/.ssh/id_rsa.pub",
     privatekey = "~/.ssh/id_rsa"
usethis::create_from_github("<repo>", destdir = "~/git", credentials = cred)

My ssh-agent is running and I've added the ssh key to the agent.

ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-BAHgeA39uy66/agent.6961; export SSH_AUTH_SOCK;
SSH_AGENT_PID=6962; export SSH_AGENT_PID;
echo Agent pid 6962;
@pat-s

This comment has been minimized.

Copy link
Author

@pat-s pat-s commented Mar 27, 2018

Update:

I specifically set $USERPROFILE as recommended in http://happygitwithr.com/ssh-keys.html#git2r-or-some-other-tool-cant-find-ssh-keys-on-windows. It was empty before.

Now I see:

as.list(Sys.getenv(
+     c("HOME", "USERPROFILE")
+ ))
$HOME
[1] "/home/pjs"

$USERPROFILE
[1] "/home/pjs"

list.files(
+     Sys.getenv("USERPROFILE"),
+     pattern = "ssh|git",
+     include.dirs = TRUE,
+     all.files = TRUE
+ )
[1] ".clusterssh" ".gitconfig"  ".ssh"        "git" 

but it still does not work.

@jennybc

This comment has been minimized.

Copy link
Member

@jennybc jennybc commented Mar 27, 2018

I don't think USERPROFILE will have any effect on Linux.

Is your SSH key protected by a passphrase?

@pat-s

This comment has been minimized.

Copy link
Author

@pat-s pat-s commented Mar 27, 2018

Hi Jenny,
No protection of my keys. They have the standard 600 permission value for ssh keys.

Sent with GitHawk

@pat-s

This comment has been minimized.

Copy link
Author

@pat-s pat-s commented Aug 12, 2018

@jennybc I just tackled this issue again and came across a solution that worked for me on Arch.

So while you propose that credentials = NULL triggers a search for the default running ssh-agent, I found that

cred_ssh_key()
$publickey
[1] "/home/pjs/.ssh/id_rsa.pub"

$privatekey
[1] "/home/pjs/.ssh/id_rsa"

$passphrase
character(0)

attr(,"class")
[1] "cred_ssh_key"

does its job as expected. As you state in #357 we do not really know what lib2git really does in the background? So why not just rely on cred_ssh_key() and if that function returns the correct ssh paths, everythings fine?

If create_from_github() would use credentials = cred_ssh_key() instead of credentials = NULL, everything would work perfectly for me.

Now ofc I do not know if this also helps in Windows or on any other OS but for Arch (maybe Linux in general?) it looks like a valid approach.

@jennybc

This comment has been minimized.

Copy link
Member

@jennybc jennybc commented Aug 12, 2018

So why not just rely on cred_ssh_key() and if that function returns the correct ssh paths, everythings fine?

This aspect of git2r has been changing a lot, as a result of all this credential-finding pain, and what I said in March does not necessarily hold today. And, as you say, it varies by OS. Last I checked, my ssh keys still aren't found on Windows.

@pat-s

This comment has been minimized.

Copy link
Author

@pat-s pat-s commented Aug 12, 2018

But if they will be found one day, cred_ssh_key() will probably also return them correctly.

So for now, cred_ssh_key() seems to work on Arch (maybe other Linux or even UNIX OS) while credentials = NULL does not. So changing from credentials = NULL to credentials = cred_ssh_key() could solve some issues for users, even if behavior may change again.

Is there a point that would speak against this change?

@jennybc

This comment has been minimized.

Copy link
Member

@jennybc jennybc commented Aug 13, 2018

Is there a point that would speak against this change?

I've just tested that on Windows and Mac. I think this will come down to whether people have a passphrase-protected SSH key. On Windows, I do not and the current behaviour of git2r::cred_ssh_key() does seem to find my keys, for the first time ever 🎉. On Mac, though, I do have a passphrase and the ssh agent is configured to manage it. So an explicit call to git2r::cred_ssh_key() results in a passphrase challenge, which is a drag.

We'll also need to think through the workflow for someone using https, i.e. make sure there is no attempt to call git2r::cred_ssh_key(). But I agree that the hope of having the git2r bits of usethis "just work" is looking brighter.

@pat-s

This comment has been minimized.

Copy link
Author

@pat-s pat-s commented Aug 13, 2018

Great! Looking forward to future enhancements. I love create_from_github() and other usethis funtions so much. Thanks!

@pat-s

This comment has been minimized.

Copy link
Author

@pat-s pat-s commented Jul 14, 2019

After all this time, it seems that I finally managed to set up the SSH stuff the right way so the SSH keys are automatically recognized.

For Linux, specifically Arch Linux, I am now using the keychain library.

Surely this more of a niche user group but maybe its worth adding it as a quick link/note somewhere in "Happy Gith with R" or elsewhere.

Setup:

  1. Install keychain
  2. Put the respective line for your shell into .bashrc/fish.config/etc (see below)

From man keychain:

 This snippet should work in most shells to load two ssh keys and one gpg key:

           eval `keychain --eval id_rsa id_dsa 0123ABCD`

       For the fish shell, use the following format:

           if status --is-interactive
               keychain --eval --quiet -Q id_rsa | source
           end

       If you have trouble with that in csh:

           setenv SHELL /bin/csh
           eval `keychain --eval id_rsa id_dsa 0123ABCD`

       This is equivalent for Bourne shells (including bash and zsh) but doesn't use keychain's
       --eval feature:

           keychain id_rsa id_dsa 0123ABCD
           [ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
           [ -f $HOME/.keychain/$HOSTNAME-sh ] && \
                   . $HOME/.keychain/$HOSTNAME-sh
           [ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] && \
                   . $HOME/.keychain/$HOSTNAME-sh-gpg
@pat-s pat-s closed this Jul 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.