In layman's git permissions check "Go"

When the local computer communicates with GitHub (or Gitlab), the transmission is primarily based on two protocols, HTTPS and the SSH corresponding warehouse address is the HTTPS URLs and SSH URLs .

First of all, it is necessary to emphasize that, HTTPS URLs and corresponding to the SSH URLs two sets of completely independent permission check mode, the main difference is HTTPS URLs to use the account password for verification, SSH URLs using the SSH key pair to verify. Usually used when we can according to the actual situation, choose one can.

HTTPS URLs

GitHub is officially recommended in a way that is more HTTPS URLs convenient (and simpler to configure), because it's a wider application (even if it works with firewalls or proxies).

With HTTPS URLs address clone / fetch / pull / push Warehouse, no configuration of the local system is required beforehand, just enter GitHub's account number and password. But if you have to manually enter the account password every time, it is also a very tedious matter.

Fortunately, there are several mechanisms that can make the operation less cumbersome.

In the Mac system, with the Enable Keychain mechanism, the first time you enter the GitHub account password, the authentication information will be automatically saved to the system Keychain , the next time you visit the warehouse will automatically read the Keychain saved authentication information.

In non-MAC systems, there is no Keychain mechanism, but git provides a credential helper mechanism to cache the account password in memory for a period of time (default 15 minutes), or to store it as a file ( ~/.git-credentials ). Of course, the Mac system Keychain can be used this way if the mechanism is not enabled.

# cache credential in memory$ git config --global credential.helper cache# store credential in ~/.git-credential$ git config --global credential.helper store

When credential.helper set to store , the first time the GitHub account password is entered, it is automatically saved to the ~/.git-credentials file, and the https://user:[email protected] authentication information is automatically read in the next time the repository is accessed ~/.git-credentials .

Another case to note is that if it is turned on in GitHub, 2FA（two-factor authentication） then when you enter the GitHub account password on the local system, you cannot enter the original password (that is, the GitHub website login password), but you need to create one on the GitHub site beforehand, Personal access token Subsequent access to the Code warehouse requires a permission check, the use access token as a password to enter.

SSH URLs

In addition HTTPS URLs to this, you can SSH URLs access the GitHub code warehouse in a way.

Prior to adoption SSH URLs , a SSH keypair key pair, including the private key and public key, is generated on the local computer. By default, the generated keys are located $HOME/.ssh/ in the directory, and the file names are the same id_rsa id_rsa.pub , usually without modification, and remain the default. However, if there is more than one key pair in a computer, you need to modify the secret key file name, there is no mandatory naming specification, so that you can easily identify.

The following is the procedure for creating a key pair.

 ? ssh-keygen-t rsa-b 4096-c  "[email protected]" generating public /private RSA key pair. Enter file in which to save the key  (/users/leo/.ssh/id_rsa):/users/ Leo/.ssh/debugtalk_id_rsaenter passphrase  (empty for no Passphrase) : <mypassphrase>enter same passphrase again: <mypassphrase>your identification has been saved in/users/leo/.ssh/debugtalk_id_rsa. Your public key have been saved in/users/leo/.ssh/debugtalk_id_rsa.pub.the key fingerprint is:sha256: Jcyeekjlcu1klronubg+uh08gj1u252rqmaddd9kymo [email protected]the key s Randomart image is:+-- -[rsa 4096]----+|+*bobo+. || o=oo=** | | ++e.*+o. | | +ooo +o+ | |. O... +os. . || . O.. O | | . . || . . || .. |+----[SHA256]-----+            

In the process of creating a secret key, the system also suggests creating passphrase something called, what is it for?

First, it's definitely not safe to use passwords alone. If the password is too simple, then it is easy to brute force, if the password is too complex, then the user is difficult to remember, recorded in the small book is more unsafe.

Therefore, SSH keys was born. SSHthe reliability of the key pair is very high, the likelihood of being violently cracked is basically not. However, this requires the user to take good care of the private key, if someone else uses your computer secretly copy your private key away, then it is like someone else has the key to your home, you can open your door at any time.

Based on the above situation, the solution is to SSH keys add another password, i.e. passphrase . Only in the case of the same SSH private key and passphrase can pass SSH the permission check, which greatly increases the security. Of course, this is passphrase not required, and it is not set when you create a key pair passphrase .

Also, passphrase this is a hassle if you want to enter it every time you check the permissions. Fortunately we do not have to worry about this problem, because ssh-agent can help us remember passphrase that the MAC system keychain can also remember passphrase , so that we do not have to re-enter the password on the same computer.

After the key pair is created, the private key is stored on the local computer ( ~/.ssh/id_rsa ) and the ~/.ssh/id_rsa.pub contents of the public key () are added to the GitHub account.

# copy the contents of id_rsa.pub to the clipboard? pbcopy < ~/.ssh/id_rsa.pub# paste to GitHub# Login GitHub, 【Settings】->【SSH and GPG keys】->【New SSH Key】

However, if the connection status between the local computer and GitHub is detected at this point, the system still prompts for permission validation to fail.

(publickey).

This is because when the local computer connects to GitHub, it is actually a native computer that ssh-agent communicates with the GitHub server. Although the local computer has a private key, it ssh-agent does not know where the private key is stored. Therefore, to use the key pair properly, you need to first add the private key to the local computer (you will need to enter it during the ssh-agent addition process passphrase ).

# start ssh-agent in the background? eval "$(ssh-agent -s)"Agent pid 78370? ssh-add ~/.ssh/id_rsaEnter passphrase for /Users/Leo/.ssh/id_rsa: <myPassphrase>Identity added: /Users/Leo/.ssh/id_rsa (/Users/Leo/.ssh/id_rsa)

Once added, you can view the keys stored in the current computer.

? ssh-add -l                (RSA)

Once again, the connection status between the local computer and GitHub is detected and the checksum is passed normally.

? ssh -T [email protected]Hi djileolee! You‘ve successfully authenticated, but GitHub does not provide shell access.

After the subsequent clone / fetch / pull / push operation, the GitHub code repository can be accessed normally, and no re-entry of the account password is required.

Also, after joining the private key ssh-agent , the local computer still has normal access to the GitHub code repository, even if the private key file is deleted.

? rm -rf ~/.ssh? ssh-add -l    (RSA)? ssh -T [email protected]The authenticity of host ‘github.com (192.30.252.130)‘ can‘t be established.RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added ‘github.com,192.30.252.130‘ (RSA) to the list of known hosts.Hi djileolee! You‘ve successfully authenticated, but GitHub does not provide shell access.

The ssh-add -D authentication information is invalidated only after the execution or ssh-add -d pub_key command has been removed from the private key ssh-agent .

([email protected])? ssh-add -lThe agent has no identities.? ssh -T [email protected]Permission denied (publickey).

Use multiple GitHub accounts simultaneously

Once we are familiar with HTTPS URLs SSH URLs these two kinds of calibration methods, we will look at the problems we encountered before. What do you need to do if you want to use multiple github accounts on a single computer to access different warehouses?

To better demonstrate, we now assume that there are two GitHub accounts, debugtalk and djileolee that each has a warehouse in two accounts, debugtalk/DroidMeter and (the DJIXY/MobileStore company's private library).

As already mentioned, HTTPS URLs and SSH URLs corresponding to two sets of independent check mode, so these two sets of methods should be able to achieve our needs alone.

But before we go into the details of the Git permissions check, let's review the priority of the GIT configuration file.

GIT Configuration Storage location and its priority

Unix-likeIn the system, there are 3 main places to save Git user information (Mac system One more Keychain ):

• /etc/gitconfig : Stores git configuration information for all users of the current system, using a --system option git config , the configuration information is written to the file ;
• ~/.gitconfig or ~/.config/git/ Config : Stores the current user's Git configuration information, using the --global option. git config , the configuration information is written to the file;
• keychain Access : When the keychain mechanism is turned on, the account password is automatically saved to keychain Access . The config file in the git directory of the
• warehouse (that is, repo/.git/config ): Stores the GIT configuration information for the current repository, using the When code class= "Highlighter-rouge" >--local option git config , the configuration information is written to the file;

In terms of priority, the priority of the above 4 configuration items rises from top to bottom, that is, repo/.git/config the highest priority, and then overwrites the configuration in the configuration Keychain Access ~/.gitconfig ~/.gitconfig /etc/gitconfig .

Based on SSHProtocol for multi-account coexistence

Let's take a look SSH URLs at how to implement our needs.

Before dealing with multi-account coexistence issues, two accounts were created with SSH key pairs, and both were SSH-key joined to the local computer ssh-agent .

(RSA)4096 SHA256:II2O9vZutdQr8xxxxxxxxxxD7EYvxxxxxxbynx2hHtg /Users/Leo/.ssh/id_rsa (RSA)

Before we elaborate on the problem of multi-account coexistence, let's recall the scenario where we usually interact with GitHub repositories in terminal.

? Droidmeter git: (master (master (master (master "add README"? Droidmeter git: (master) git pushcounting objects:3, done. Delta compression using up to 4 threads. Compressing objects:100% done. Writing objects:100%  (3/3done. Total 3             

During the operation, the local computer is ssh-agent connected to the GitHub server and the account permissions are verified.

This behavior is not difficult to understand when the local computer has only one GitHub account, and the system should operate with this unique GitHub account. If there are multiple github accounts on the local computer, what does the system determine which account to choose?

The reality is that the system cannot be judged. The system will only have a default account, and then use this default account to operate all the code warehouse, when the account and the warehouse does not match, will be reported the right to check the failure error.

How do you get the system to differentiate the account correctly? This requires us to configure it manually, which is the configuration file ~/.ssh/config .

Create ~/.ssh/config a file in which to fill in the following content.

# debugtalkHost debugtalk    HostName github.com    User git    IdentityFile ~/.ssh/id_rsa# DJIHost djileolee    HostName github.com    User git    IdentityFile ~/.ssh/dji_id_rsa

To understand the meaning of the above configuration file is not difficult, we can compare to see the next two items SSH URLs :

[email protected]:debugtalk/DroidMeter.git[email protected]:DJISZ/Store_Android.git

The git ssh-agent SSH user name (i.e.), which is the local connection to the GitHub server User , github.com is the host (ie) of the GitHub server HostName .

As can be seen, if the original SSH URLs , because User and the HostName same, the local computer does not know which SSH-key to use to establish the connection.

Therefore, by creating a ~/.ssh/config file, the distinction is made in, Host and then CNAME mapped to HostName , and then pointed to differently SSH-key , that is IdentityFile . Because HostName it is the field that really specifies the GitHub server host, this configuration does not affect the local connection to the ssh-agent GitHub host, and the Host alias points to a different SSH-key one, thus enabling the separation of two github accounts.

Once configured, two github accounts can be Host distinguished by aliases. When you later communicate with the GitHub server, you can use Host aliases instead of the original github.com . For example, ssh-agent when testing the connectivity of local and GitHub servers, you can use the following methods:

? ssh -T [email protected]Hi debugtalk! You have successfully authenticated, but GitHub does not provide shell access.? ssh -T [email protected]Hi djileolee! You have successfully authenticated, but GitHub does not provide shell access.

As you can see, at this point two accounts do their jobs and there will be no more confusion.

However, we have missed a very important point. The push command does not contain information when it executes//in the local code repository, how does the pull fetch Host system know which GitHub account we are going to operate with?

The answer is, the system is still unable to judge, we need to make configuration designation.

Obviously, different repositories may correspond to different GitHub accounts, so this configuration cannot be configured as a global, but can only be configured separately in each project, that is, repo/.git/config files.

This is configured in the following way:

In the debugtalk/DroidMeter warehouse:

? git remote add origin [email protected]:debugtalk/DroidMeter.git

In the DJIXY/MobileStore.git warehouse:

? git remote add origin [email protected]:DJIXY/MobileStore.git

The principle of configuration is also easy to understand, is to replace the warehouse with the Host previous set of aliases. Once added, the git system can choose to SSH-key interact with the GitHub server correctly when performing any of the operations in the two warehouses at a later time.

Based on HTTPSProtocol for multi-account coexistence

Take a look at how to HTTPS URLs implement our needs.

With the previous experience, our thinking is much clearer. HTTPS URLsafter the git permissions are checked, the GitHub account password is stored in the system Keychain (MAC System) or stored in a ~/.git-credentials file ( Git credential helper ).

Regardless of where it is stored, the problem we face is the same: how to differentiate which GitHub account to use in the Code warehouse.

The way you configure it is actually simple:

In the debugtalk/DroidMeter warehouse:

? git remote add origin https://[email protected]/debugtalk/DroidMeter.git

In the DJIXY/MobileStore.git warehouse:

? git remote add origin https://[email protected]/DJIXY/MobileStore.git

The principle of configuration is also easy to understand, add GitHub username to the git address of the warehouse, so when executing the git command, the system will use the specified github user name to go to Keychain or ~/.git-credentials search for the corresponding authentication information, the problem of account use confusion will no longer exist.

In layman's git permissions check "Go"