Git is an open source distributed version control system for agile and efficient handling of any small or large project, providing version control and content management. Therefore, it laid the foundation for Git to become a platform gradually, and the code hosting platform was born. The mainstream platforms are GitHub, GitLab, Gitee and so on. To be platformized, the primary task is to add a security authentication mechanism on the basis of Git. Therefore, Git code hosting platform adopts HTTPS and SSH, which provide identity authentication and ensure the security of data.
Git and SSH protocols are used for security authentication. How does Git verify user permissions when using Git for clone and push? What is the principle of account password authentication and secret free authentication? From shallow to deep together to uncover this layer of veil, this paper through a number of rhetorical questions? Combined with many examples to help understand, I also hope that friends in the reading, can make this multi-angle thinking way into their own. Divergent thinking allows you to be more creative, locate problems faster, and many other benefits.
Main contents of this paper:
- What is SSH?
- Basic ARCHITECTURE of SSH
- The advantages of SSH
- SSH key pair
- SSH Security Authentication
- Principles and process of password-based security authentication
- Principles and process of key pair-based security authentication
- Git code hosting platform SSH how to perform security authentication?
- When will the Git code hosting platform be authenticated?
You may also discover a few things you might not know:
- The same public key can be configured for multiple Git platforms, but cannot be configured for multiple accounts on the same platform
- SSH key authentication is not mandatory
~/.ssh/config
PS: There are a lot of things to say. If you can’t understand it after watching it for several times, you can comment and pay attention to it. I will make a video teaching again
SSH is what?
As for Git code hosting platform (generally refers to GitHub, GitLab, Gitee, etc.) why choose SSH protocol? How does SSH implement security authentication? How does Git relate to SSH authentication? To answer these questions, we first need to know what SSH is. What can it do? What are its advantages?
SSH is short for Secure Shell. It is an encrypted network transmission protocol that provides a Secure transmission environment for network services on insecure networks. SSH connects SSH clients and servers by creating secure tunnels on the network to ensure complete and reliable information encryption on insecure networks such as the Internet. The most common use of SSH is to remotely log in to the system. People usually use SSH to transmit command lines and remotely execute commands. In other words, SSH is a security protocol for remote login sessions and other network services, effectively preventing information leakage during remote management.
SSH implements authentication with asymmetric encryption. There are many ways of identity authentication. Usually, we use a pair of manually generated public and private keys to authenticate through the generated key. In this way, we can log in without entering a password. Anyone can generate their own key. The public key must be stored in the computer to be accessed, and the corresponding private key must be kept by the user. The authentication process is based on the generated private key, but the private key itself is not transmitted to the network during the authentication process. SSH only validates that the user has a private key that matches the public key, and the server grants licenses as long as the public key is accepted and the key matches.
What is asymmetric encryption? Asymmetric cryptography, also known as public key cryptography, is an algorithm of cryptography, which requires two keys, one public key and the other private key. The public key is used for encryption and the private key for decryption. If the plaintext is encrypted using a public key, the original plaintext can be decrypted only by using the corresponding private key. The public key used for encryption cannot be used for decryption. Because encryption and decryption need two different keys, it is called asymmetric encryption; The public key can be made public and released freely. The private key can not be public, must be kept by the user strictly secret, never through any way to anyone, will not be disclosed to the trusted to communicate with the other party.
Basic ARCHITECTURE of SSH
The SSH protocol framework consists of three protocols:
- The Transport Layer Protocol: The Transport Layer Protocol provides support for server authentication, data confidentiality, and information integrity.
- The User Authentication Protocol: The User Authentication Protocol provides client identity Authentication for The server.
- The Connection Protocol: The Connection Protocol multiplexes The encrypted information into several logical channels for use by higher-level application protocols.
A large number of extensible items are designed in the SSH framework, such as user-defined algorithms, user-defined key rules, and high-level extended functional application protocols. Various high-level application protocols can be relatively independent of the basic SSH architecture and rely on this basic framework to use SSH security mechanisms through connection protocols. For example, hosting platforms such as GitHub can be based on the basic FRAMEWORK of SSH, and then use SFTP or SCP protocol to securely transfer files, and encrypt or decrypt files.
The advantages of SSH
- Mature technology
- High data security
- Multiple certification paths
- Can expand sex
SSH key pair
SSH public key, private key, and key pair The SSH public key, private key, and key pair are introduced in the following table. They may be boring, but the following examples make it easier to understand:
concept | instructions |
---|---|
The key to | Anyone can use a key generation tool (e.g.ssh-keygen ) Generate a key, which can be divided into private key and public key. The private key is held by the owner and cannot be published, while the public key can be made public and released freely. |
The public key | For data encryption, data encrypted using a public key can only be decrypted using the matching private key. |
The private key | Used for data decryption, only matched public key encrypted data can be successfully decrypted. |
encryption | After the plaintext is encrypted using the public key, the original plaintext can be decrypted only by using the corresponding private key. Even if intercepted by illegal users can not obtain the correct data content, so as to ensure the security of the data. |
Abstract | The text to be transmitted is computed using HASH (generally SHA1 and SHA2). |
The signature | Using the private key to encrypt the desired digest, the resulting ciphertext is called the signature of the transmission. |
Signature verification | The public key is used to decrypt the signature to obtain the digest. The transmitted text is also hashed to obtain the sent digest. The decrypted text is compared with the decrypted digest to verify whether the text is tampered during transmission. |
The above concepts may be boring, but let’s use two examples to understand the encryption process and the signature authentication process respectively.
Example 1: Bob wants to send An encrypted message to Alice:
- User Alice gives Bob her public key,
- The public key provided by Alice is used for encryption, and the ciphertext obtained is sent to Alice
- Alice uses her private key to decrypt and get the plaintext message.
Example 2: Bob uses a signature to reply to Alice with an encrypted message:
User Alice does not have Bob’s public key, and Alice wants to send Bob an encrypted message
- Alice signs the information using her private key
- Send the signature information to Bob
- Bob uses Alice’s public key to decrypt the signature and get the plaintext message.
From the above two examples, we can draw the following conclusions:
- Both encryption and authentication are encrypted and decrypted using the same pair of keys
- The encryption process is public key encryption and private key decryption
- The authentication process is different from the encryption process. The private key is used to sign the information, and the public key is used to decrypt the signature and verify the private key owner information
SSH Security Authentication
The SSH protocol also provides two levels of security authentication, password authentication and key authentication. Different authentication types determine different authentication modes. For details, see the following table:
The authentication type | Certification level | instructions |
---|---|---|
Password authentication | Password-based security authentication | Know the account and password to log in to the remote host. However, there may be another server impersonating the real server, which is not immune to man-in-the-middle attacks. |
Key authentication | Key based security authentication | The authentication is performed by the key and the authentication center. |
SSH password – based security authentication
Is the authentication of the account and password, knowing the account and password, can log in to the remote host, and all transmitted data will be encrypted. However, there may be another server impersonating the real server, which is not immune to man-in-the-middle attacks.
Let’s look at the flow of password-based security authentication:
- The client makes a request to the host service using an account, for example:
ssh user@host
- The server sends the public key of the server to the client
- The client obtains the public key of the server and encrypts the password and sends it to the server
- The server decrypts and verifies the password using the private key and returns the login result
SSH key-based security authentication
Key-based authentication relies on keys, which means you have to create a pair of keys for yourself and place the public key on the server you want to access. The client software sends a request to the server to use your key for security authentication. When the server receives the request, it looks for your public key in the server’s user root directory and compares it with the public key you sent. If the two keys match, the server encrypts the “challenge” with the public key and sends it to the client software. When a client receives a “challenge”, it allows the client to choose whether to trust it. The client selects whether to trust it based on the IP address and domain name to avoid being attacked by the “middle man”.
If the remote host has a public key and the local host has a private key, you do not need to manually enter the password during login. Common scenarios include remote secret-free login and Git secret-free operation. In addition, for extra security, the private key itself can also be password protected, when using the private key for signature or decryption, the private key will be password authentication.
The correct process is:
- The key pair is generated locally
- Sends the locally generated public key to the remote host
- Initiates a request to use the key for security authentication
- When the server receives the request, it returns a summary
- The client uses the private key to sign the digest and send it to the remote host
- The server verifies and decrypts the signature using the public key and returns the result
conclusion
Through the introduction of password authentication and key authentication and the combination of the authentication sequence diagram, we can find the differences between the two authentication types:
- Both can ensure data security, but passwords cannot avoid man-in-the-middle attacks, and keys can avoid man-in-the-middle attacks.
- If the peer party has its public key, it can use encrypted authentication to send messages to the peer party.
- If the peer party has our public key, we can use signature authentication to send messages to the peer party.
The relationship between Git code hosting platform and SSH security authentication
Don’t know if you have found the Git code hosted platforms provide SSH address is Git @ HOST_NAME beginning, such as: [email protected]: chudongvip/awesome_video_player Git. Why is that? First we know that SSH remote login is through the SSH user@host command. User is the user name of a service host, and host is the IP address or domain name of a service host. Is Git a user of the service host on which the code is hosted? Let’s test this with two examples from GitHub (this is just to verify that Git is a sub-account of the host that serves the code hosting platform).
Example 1
SSH Keys GitHub SSH Keys GitHub SSH Keys
$ ssh [email protected]
The authenticity of host 'github.com (13.229.188.59)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'Github.com, 13.229.188.59' (RSA) to the list of known hosts.
[email protected]: Permission denied (publickey).
Copy the code
An authorization failure occurred. Procedure
Example 2
GitHub SSH Keys are configured for an account (generate the key pair locally, then go to GitHub to configure, skip steps here).
$ ssh [email protected]
The authenticity of host 'github.com (13.229.188.59)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'Github.com, 13.229.188.59' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi chudongvip! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
Copy the code
This time, instead of failing, GitHub will tell you that authentication succeeded, but GitHub does not provide shell access. So with these two examples, we can come to our final conclusion, plus a bonus:
- Git code hosting platforms provide a public subaccount
git
- Git code hosting platform can only be authenticated through SSH, not shell access
Git code hosting platform SSH how to perform security authentication?
Before we figure out how to secure Git, we need to know which operations need to be authenticated.
As we all know, Git code hosting platform is divided into two kinds of repositories: public repository and private repository. The different types of repositories mean that the identity authentication of the repository owner’s operation steps is also different. Therefore, security authentication needs to distinguish the types of repositories. Here are two simple examples:
-
Clone the remote repository locally (private repository)
$ git clone [email protected]:chudongvip/xxxx.git Copy the code
This will prompt us that we do not have permission, or start to verify our account password.
-
Local repository associated with remote repository pushes code to branch (public or private repository)
$ git init $ git add . $ git commit -m "first commit" $ git add remote origin [email protected]:chudongvip/xxxx.git $ git push Copy the code
The public repository does not authenticate us when we clone (or when the local repository is associated with the remote repository), but authenticate us when we push.
Based on our understanding of the warehouse and a large number of tests, we can roughly draw the following conclusions:
Warehouse type | Git operations to verify permissions |
---|---|
Public warehouse public | git push |
Private warehouse | git clone ,git pull ,git push |
As mentioned above, Git code hosting platform can be divided into public repository and private repository. The permission verification of private repository is more frequent, so in the following examples, we use private repository as an example. Suppose we now have a GitHub account, ChudongVIP, and a private repository, awesome_video_Player, Warehouse SSH address for [email protected]: chudongvip/awesome_video_player git. Information details are shown in the following table:
platform | account | warehouse | Warehouse SSH address |
---|---|---|---|
GitHub | chudongvip | awesome_video_player | [email protected]:chudongvip/awesome_video_player.git |
First we need to create a local SSH key pair.
Then go to GitHub and add SSH Keys to account ChudongVIP.
Git Clone (SSH) : Git Clone (SSH)
Therefore, the Git code hosting platform SSH is authenticated based on key security.
Things you might not know
Git SSH is a low-frequency operation, so it is easy to ignore some limitations. Git SSH is a low-frequency operation, so it is easy to ignore some limitations. Git SSH is a low-frequency operation, so it is easy to ignore some limitations.
Restrictions on SSH Keys configuration
The key generated by using the key generation tool ssh-keygen can be configured to an account on GitHub, Gitee, or GitLab at the same time, but cannot be configured to multiple accounts on the same platform at the same time. Here is an example to verify the authenticity:
Example steps:
- The local use
ssh-keygen
Generate a key pairgithubA_rsa.pub
和githubA_rsa
- You have two GitHub accounts ([email protected], [email protected])
- Account A is added in SSH Keys
githubA_rsa.pub
(the public) - Add the same public key to the SSH Keys of account B
- GitHub will tell you that the Key is already in use.
Therefore, we can only solve this problem by configuring multiple keys and setting ~/. SSH /config to specify host, as shown in the following table:
Making account | Public warehouse | Local key | Git SSH Keys |
---|---|---|---|
[email protected] referred to as A | Apro | GithubA_rsa. Pub, githubA_rsa | githubA_rsa.pub |
[email protected] referred to as B | Bpro | GithubB_rsa. Pub, githubB_rsa | githubB_rsa.pub |
When should you configure it~/.ssh/config
?
SSH client configuration ~/. SSH /config does not need to be configured, only on one platform (for example: If you have multiple accounts at GitHub, you can configure ~/. SSH /config to specify host, and then change the host in the SSH address of Git repository to tell platform which account is currently used. SSH /known_hosts adds a record (domain name, IP address, public key information, etc.).
Based on when do you need to configure? Why is configuration required? Let’s start with an example:
First, the above two GitHub accounts are configured with SSH Keys respectively.
Then, we use account A to pull one of the repositories under A, we change the readme.md in the project, and commit for the first time.
$ vim README.md
$ git commit -a -m "update README.md"
$ git push
The authenticity of host 'github.com (52.74.223.119)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'Github.com, 52.74.223.119' (RSA) to the list of known hosts.
Copy the code
Since this is the first commit, Git verifies our identity and asks if we are asked to trust github.com (52.74.223.119). Selecting Yes will add a record to known_hosts. We can look at the information in known_hosts:
$cat known_hosts github.com,52.74.223.119 ssh-rsa AAAAB3NzaC1yc2EA******************************************************************************************************** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * can't give you see here * * * * * * * * * * * * * * * = =Copy the code
Nothing’s wrong, isn’t it? Let’s test it out.
We use account B to pull the repository under GitHub account B, change the readme. md in the project, and then submit.
$ vim README.md
$ git commit -a -m "update README.md"
[master b5319ad] update README
1 file changed, 1 insertion(+)
create mode 100644 README.md
$ git push
ERROR: Permission to DyncMark/autoUpdateDEMO.git denied to chudongvip.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Copy the code
From the example above, we can see that no new records will be added to known_hosts when git push is performed. Because the record already exists (the domain name, IP address, and GitHub public key are all the same), Git treats you as user A when you submit B’s project. ~/. SSH /config to customize host, and then change the host in SSH address of Git repository to tell platform which account is currently used. As for how to configure this, you can follow my next article ** how to Maintain Multiple Accounts on Git Platform? 支那
The related documents
- Wikipedia Secure Shell
- How to maintain multiple accounts on Git platform? (To be updated)
[Denver annual essay | 2020 technical way with me The campaign is underway…] (