Authentication failed: cloning a private repository — Permission denied (publickey)
See original GitHub issueDescription
Using a new laptop, with a fresh install of GitHub Desktop, authentication fails when I try to clone my own private repository — after passing Checking out files: 100% (1053/1053), done.
and attempting Cloning into
.
From the logs:
Cloning into '/Users/morgan/Documents/GitHub/repository'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I have cycled through the log-out-log-in routine suggested by hequ on #4451, revoking then reinstating GitHub Desktop’s OAuth permissions, but to no avail.
I have tried initiating the clone both within GitHub Desktop, and directly from GitHub using both HTTPS and SSH, but both fail at the same point for similar authentication issues (logs attached below).
I am able to create, and push to, new private repositories on the same account using GitHub Desktop.
The repository is forked from a separate private repository I do not own, if that makes a difference (I guess it shouldn’t).
The help article ‘Error: Permission denied (publickey)’ seems relevant, though it is written for command line users, not GitHub Desktop users.
Do I need to generate a new key pair, and associate them with my GitHub Account? — for HTTPS and SSH?
Version
-
GitHub Desktop: 1.5.1
-
Operating system: macOS 10.14.1
Steps to Reproduce
First Attempt: browser sign in
- Sign in to github.com
- Install GitHub Desktop
- Use ‘Sign in using your browser’ to authenticate GitHub Desktop
- Select ‘Clone Repository’ and choose the private repository at issue listed under ‘Your Repositories’, then ‘Clone’
- The clone process starts, almost completes, then authentication fails on completion
Second Attempt: manual sign in
As First, except:
- Sign in using GitHub Desktop, entering my credentials manually
Third Attempt: HTTPS via browser
As First, except:
- Select ‘Clone or Download’ from the repository on github.com —> ‘Clone with HTTPS’ —> ‘Open in Desktop’
Fourth Attempt: SSH via browser
As First, except:
- Select ‘Clone or Download’ from the repository on github.com —> ‘Use SSH’ —> ‘Open in Desktop’
Notes
- Between each attempt, I delete the repository folder from my local GitHub directory
- After the fourth attempt, I signed out of my account on GitHub Desktop, then revoked its OAuth permissions in the browser; I then signed out of my account in the browser and signed back in again on both, attempting the above steps again
Expected Behavior
I expect step 5. to complete without an authentication failure: I am logged in with the correct username and password, both on GitHub Desktop and the browser, and have full ownership and access privileges for this repository.
Actual Behavior
Using HTTPS: Authentication fails after Checking out files
has completed, on Cloning into
.
The key line (er, pun) seems to be:
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Using SSH: ssh: Authentication fails after Checking out files
has completed, on Cloning into
.
ssh: connect to host github.com port 22: Operation timed out
fatal: Could not read from remote repository.
Additional Information
Other possibly related things I did when setting up the new laptop for this purpose:
- Installed Docker Desktop, built a Docker image, and ran a server locally
- Installed the AWS CLI
- Troubleshooting a problem with the local server led me to attempt a fresh clone of the site repository, which is how I ran into this authentication problem
I installed GitHub Desktop on a different new laptop a month ago, and had no issues.
Logs
HTTPS attempt: 2019-01-10.desktop.production.log SSH attempt: 2019-01-09.desktop.production.log
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
If you’re not able to get to port 22, you might be able to workaround it by rewriting the URLs from config.
These two entries in your
~/.gitconfig
global config should do the trick [source]:@morqon I think you’re seeing the ongoing SSH failures because your submodules are configured with SSH (these are not affected by whether the initial clone is HTTP or SSH):