On Fri, 29 Nov 2013 01:19:48 -0800 (PST) David Ingledow <[email protected]> wrote:
[...] > I've installed Git and got my ssh keys authenticated with GitHub. [...] > fatal: could not create work tree dir 'example.com'.: Permission > denied This means Git failed to create a directory on your filesystem because the used which credentials Git process has (yours, most probably) did not possess the necessary permissions. [...] > I then tried running sudo git clone [email protected]:exam .... etc. and > got the error: > > Permission denied (publickey). > > fatal: The remote end hung up unexpectedly This is a completely separate issue: here, "permission denied" comes from the SSH client spawned by your Git process to access the server. It told you it failed to authenticate at the server using the "publickey" mechanism -- that one where you use your private SSH key to access the server. What do to there -- it depends. If you do not have any funky custom SSH configuration (say, it's possible to make SSH client use different keys to authenticate on different server), try to follow this checklist: 1. Get the fingerprint of your public key: $ ssh-keygen -l -f ~/.ssh/id_rsa.pub (it's that series of pairs of hexadecimal numbers separated by colons), and verify it matches the fingerprint of the key you've authorized for your github repository -- you can see them in the key management part of the web interface. If they do not match, it means you did not deploy your private SSH key to the box on which you run `git clone`. If so, securely transfer that ~/.ssh/id_rsa file to that box. Note that the file should be owned by you and have 0600 permission bits. 2. If fingerprints do match, you supposedly have some problem with the SSH client finding or loading your private key, or you have only deployed the public part of your key but not the key itself (and the public part of an SSH key, or just "public key", as it's customarily named, is not used for the authentication process -- it's sole purpose it to authorize its matching private key for accessing other systems, just what you did for your github repos). If so, again make sure you have your private key available to the SSH client as the ~/.ssh/id_rsa file, with the owner/permissions set as explained above. If all this fails, try running SSH by hand in verbose mode: $ ssh -vvvv [email protected] and try to figure out why it fails to authenticate. If you fail to figure this out, post the output here (*not* the screenshot, please, -- copy the text). -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
