Background description

GitHub repository_URL: GitHub repository_URL: GitHub repository_URL: GitHub repository_URL: GitHub repository_URL:

https://github.com/DJIXY/MobileStore.git
[email protected]:DJIXY/MobileStore.gitCopy the code

Normally, if you have a Git account locally repository_URL, you can go to git Clone repository_URL to get the code.

Recently, however, when I looked at clone code hosted in GitHub’s private Repository on my Macbook Air, I found that remote: Repository was not found in the Clone code, which could not use HTTPS. The error.

➜ git clone https://github.com/DJIXY/MobileStore.git
Cloning into 'MobileStore'...
remote: Repository not found.
fatal: repository 'https://github.com/DJIXY/MobileStore.git/' not foundCopy the code

First of all, the repository does exist, and the address is certainly not a problem, through the URL can also be accessed in the browser to the corresponding GitHub repository page.

Secondly, the local configuration of Git is also no problem, through the SSH protocol address can be normal clone code.

➜ git clone [email protected]: DJIXY/MobileStore. Git Cloning into 'MobileStore'... Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts. Remote: Counting objects: 355, done. remote: Compressing objects: 100% (3/3), done.Copy the code

In addition, if you add the GitHub account to the HTTPS URL, the clone code can be normal.

➜ git clone https://[email protected]/DJIXY/MobileStore.git
Cloning into 'MobileStore'...
remote: Counting objects: 355, done.
remote: Compressing objects: 100% (3/3), done.Copy the code

Even weirder, on my other Mac Mini, I clone the URLS of both protocols using the same account configuration. I carefully compared git configurations on both computers and found that they were the same.

➜ cat ~ /. Git - credentials https://djileolee:[email protected] ➜ cat ~ /. Gitconfig [credential] truehelper = storeCopy the code

So what’s the problem?

Positioning analysis

Remote: Repository not found There are two main reasons for the error, one is the warehouse address error, the other is the permission check does not pass. Obviously, the first reason can be directly excluded, and the problem in Macbook Air should be caused by the failure of account permission verification.

Sort out the phenomena in the background description, focusing on two suspects:

  • throughHTTPSProtocol URL addressgit clone“, the system does not prompt you to enter the user name and password, but directly returns the exception that the permission verification fails.
  • inHTTPSIf the GitHub user name is added to the PROTOCOL URL, the protocol works normallycloneAnd there is no prompt for a password.

This means that somewhere in the system, the GitHub account password should be saved. Therefore, when git Clone is not specified, the system will not ask users to input the account password, but directly read the saved account information. However, there should be a problem with the password of the saved GitHub account, which causes that the GitHub verification fails with the account information, and an exception is returned.

Based on the above speculation, the most urgent task for finding the root of the problem is to find where the GitHub account password is stored.

Git user information is stored in three places:

  • /etc/gitconfig: Stores git configuration information of all users in the current system.
  • ~/.gitconfigor~/.config/git/config: Stores the git configuration information of the current user.
  • The config file in the Git directory of the repository (i.erepo/.git/config) : Stores git configuration information for the current repository.

Gitconfig overwrites ~/. Gitconfig, and ~/. Gitconfig overwrites /etc/gitconfig.

Repo /.git/config is not a repository for Git. Gitconfig = ~/. Gitconfig = ~/. Gitconfig = ~/. Gitconfig = ~/. Then check the system-level Git configuration information, that is, the /etc/gitconfig file, but find that the file does not exist in the current system.

I’ve searched all the places where Git user information might be stored, but I can’t find the account configuration information. Where else could it be stored?

At this time, I basically had no idea, so I could only rely on all kinds of random guesses, and even tried to use Wireshark to capture git clone process on two Macs respectively and compare the difference of communication data, but failed to find the answer.

Finally, the Keychain mechanism of Mac came to mind. Git credentials can be stored in the Keychain of Mac OSX. Git credentials can be stored in the Keychain.

Open the Keychain Access app on the Macbook Air and search Github. Sure enough, there are records.

There are also two records for github.com. One is my personal account debugtalk, and the other is djileolee, my company’s work account.

At this point, the truth is out!!

In my Macbook Air, my GitHub debugtalk is stored in Keychain Access, which does not have Access to the company’s private warehouse. However, when I run the git clone command in Terminal, the system preferentially reads my personal account and sends a verification request to GitHub with this account, resulting ina failure of permission verification when reading the company’s private repository. However, if the djileolee account is added to the HTTPS URL, the account name is specified. Therefore, the corresponding account (including the password) can be found when the account information is read from the Keychain. In addition, it can successfully pass the GitHub permission verification without entering the password, and then successfully clone the code.

Once the reason is clear, the solution is very simple, delete the personal account in Keychain, and then normal.

Summary review

But has the problem really been solved?

No!

I simply deleted my GitHub account from Keychain, and it worked fine when I accessed the company repository again. What should I do then when I accessed the repository again?

I don’t seem to have a clear idea. There are plenty of tutorials available online, but there’s still a lot of confusion about the principles behind the operation.

Back to the previous background description, and the whole process of locating the problem, not from the sadness. GitHub has been around for a few years, but even the most basic concepts are still in the dark, so when things go wrong, you have to guess.

GitHub HTTPS protocol and SSH protocol, which correspond to two sets of completely independent permission verification methods, and I still check SSH protocol in the case of HTTPS protocol is not normal, which is unnecessary.

With the help of this “pit” experience, I reorganized the two ways of Git permission verification, and wrote a separate blog, “Simple Git permission verification”. Although it took some time, it finally cleared the fog lingering for many years, and felt great!

If you don’t have a clear understanding of Git permission verification, you can only “try another way” when you encounter a permission verification error, and you don’t know how to make a computer support multiple GitHub accounts at the same time, then you are also recommended to read this blog.

Enter Git permission verification in the wechat public account debugtalk to obtain The Simple Git Permission Verification.