00. Table of Contents
Article directory
01. Overview
By now there are ways to use Git to get your daily work done. However, in order to use the Git collaboration feature, you also need a remote Git repository. Although it is technically possible to push and pull from a personal repository to modify content, this method is discouraged because it is easy to confuse other people's progress if you are not careful. Additionally, you want your collaborators to be able to access the repository even when your computer is not online - having a more reliable public repository is useful. Therefore, the best way to collaborate with others is to create a shared repository that you and your collaborators have access to and can push and pull data from there.
Setting up a Git server is not difficult. First, select the communication protocol you want the server to use. In this chapter we will introduce the available protocols and their respective advantages and disadvantages. The following section explains a typical setup using those protocols and how to run them on your server. Finally, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server, you can try one of the warehouse hosting services we introduced.
A remote repository is usually just a bare repository - that is, a repository without a current working directory. Because the repository only serves as a collaboration medium, there is no need to check the snapshot from disk; only Git data is stored. To put it simply, the bare warehouse is .gitthe content of the subdirectory in your project directory and does not contain other data.
02. Agreement
Git can use four different protocols to transmit data: Local protocol (Local), HTTP protocol, SSH (Secure Shell) protocol and Git protocol. Here, we'll discuss those protocols and the situations in which they should be used (or avoided).
2.1 Local protocols
The most basic one is the Local protocol , in which the remote version library is another directory on the same host. This is common when every member of the team has access to a shared file system (such as an NFS mount), or less commonly when multiple people share the same computer. The latter is not ideal, because if all your code repositories live on the same computer for a long time, catastrophic loss is more likely to occur.
If you use a shared file system, you can clone, push, and pull from the local repository. To clone a repository or add a remote to an existing project like this, use the repository path as the URL. For example, to clone a local repository, you can execute the following command:
$ git clone /srv/git/project.git
or
$ git clone file:///srv/git/project.git
file://Git behaves slightly differently if specified explicitly at the beginning of the URL . If you just specify a path, Git will try to use a hard link or copy the required file directly. If specified file://, Git will trigger the process usually used to transmit data over the network, so the transmission efficiency will be lower. The main purpose of specifying file://is to get a clean copy of the repository without extraneous references or objects - usually after importing from another version control system or some similar situation. We'll use the normal path here because it's usually faster.
To add a local repository to an existing Git project, execute the following command:
$ git remote add local_proj /srv/git/project.git
local_projThen, you can push and pull updates from the remote repository through the new remote repository name just like on the network.
advantage
The advantage of a file system-based repository is that it is simple and directly uses existing file permissions and network access permissions. If your team already has a shared file system, setting up a repository is easy. Just like setting up other shared directories, put a copy of the bare version library in a path that everyone can access, and set the read/write permissions. We will discuss how to export a Git on the server. Naked repository.
This is also a quick way to pull updates from someone else's working directory. If you are working on a project with someone else and they want you to pull updates from the repository, it is git pull /home/john/projectmuch easier to run a similar command than to push it to the server and then fetch it back.
shortcoming
The disadvantage of this approach is that generally shared file systems are more difficult to configure and are less convenient to access from multiple locations than basic network connection access. If you want to push content from home, you must first mount a remote disk. Compared with the access method of network connection, the configuration is inconvenient and the speed is also slow.
It is worth mentioning that this method is not necessarily the fastest if you are using a file system similar to a shared mount. The speed of accessing the local repository is the same as the speed of accessing the data. On the same server, if Git is allowed to access the local hard disk, generally accessing the repository through NFS is slower than accessing through SSH.
Ultimately, this agreement does not protect the warehouse from accidental damage. Every user has full shell permissions on the "remote" directory, and there is no way to prevent them from modifying or deleting internal Git files and corrupting the repository.
2.2 HTTP protocol
Git has two modes for communicating over HTTP. Prior to Git 1.6.6, only one method was available, which was very simple and usually in read-only mode. Git version 1.6.6 introduces a new, smarter protocol that allows Git to negotiate and transfer data as intelligently as through SSH. In the following years, this new HTTP protocol became very popular because of its simplicity and intelligence. The new version of the HTTP protocol is generally called the smart HTTP protocol, and the old version is generally called the dumb HTTP protocol. Let's first take a look at the new smart HTTP protocol.
Smart HTTP protocol
Smart HTTP operates similarly to SSH and Git protocols, except that it runs on the standard HTTP/S port and can use various HTTP authentication mechanisms, which means that it is much simpler to use than the SSH protocol. For example, the HTTP protocol can be used Username/password authorization eliminates the need to set up an SSH public key.
The Smart HTTP protocol is perhaps the most popular way to use Git. It not only supports git://setting up anonymous services like the HTTP protocol, but also provides authorization and encryption during transmission like the SSH protocol. And you can do it all with just one URL, eliminating the need to set different URLs for different needs. If you want to push to a server that requires authorization (usually it does), the server will prompt you to enter your username and password. The same goes for when getting data from the server.
In fact, for services like GitHub, the URL you see on the web page (such as https://github.com/schacon/simplegit) is the same one you use when cloning and pushing (if you have permission).
Dumb HTTP protocol
If the server does not provide services for the smart HTTP protocol, the Git client will try to use the simpler "dumb" HTTP protocol. In the dumb HTTP protocol, the web server only treats the bare version library as an ordinary file and provides file services. The beauty of the dumb HTTP protocol is that it's easy to set up. Basically, you just need to put a bare repository in the HTTP root directory and set up a hook called post-update (see Git hooks). At this point, as long as you can access your repository on the web server, you can clone your repository. Here's how to set up access to the repository over HTTP:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
that's it. Git's own post-updatehook will execute the appropriate command ( git update-server-info) by default to ensure that fetching and cloning operations through HTTP work properly. This command will be executed after you push to the repository via SSH; others can then clone it with a command similar to the following:
$ git clone https://example.com/gitproject.git
Here we used the usual path /var/www/htdocs set up in Apache, but you can use any static web server - just put the bare version library in the correct directory. Git's data is provided in the form of basic static files (see Git internals for details).
Typically, the choice is between a smart HTTP service that provides read/write and a simple read-only dumb HTTP service. Rarely do services mix the two.
advantage
We will only focus on the advantages of the smart HTTP protocol.
Different access methods only require one URL and the server only prompts for authorization information when authorization is required. These two simplicity make it very simple for end users to use Git. Compared with the SSH protocol, the ability to use username/password authorization is a great advantage, so that users do not have to generate an SSH key pair locally and then upload the public key to the server before using Git. For non-experienced users, or those who lack SSH-related programs on their systems, the availability of the HTTP protocol is a major advantage. Similar to the SSH protocol, the HTTP protocol is also very fast and efficient.
You can also serve a read-only repository over HTTPS, so that you can encrypt the data during transmission; or, you can even let the client use a designated SSL certificate.
Another benefit is that the HTTPS protocol is widely used, and general corporate firewalls will allow data through these ports.
shortcoming
On some servers, setting up a server using the HTTPS protocol is more difficult than using the SSH protocol. Beyond this point, there are few advantages to using other protocols to serve Git over the smart HTTP protocol.
If you're using authorized push over HTTP, managing credentials can be a bit more cumbersome than using SSH key authentication. However, you can choose to use a credential storage tool, such as Keychain for macOS or Credential Manager for Windows. See how the credential store securely stores HTTP passwords.
2.3 SSH protocol
When setting up a Git server, the SSH protocol is commonly used as the transmission protocol. Because in most environments the server already supports access via SSH - even if it doesn't it's easy to set up. The SSH protocol is also a network protocol for authenticating authorization; and, because of its ubiquity, it is easy to set up and use.
To clone a repository via SSH protocol, you can specify a ssh://URL:
$ git clone ssh://[user@]server/project.git
Or use a short scp-style notation:
$ git clone [user@]server:project.git
In both cases, if you don't specify an optional username, Git will use the name you're currently logged in with.
Advantage
There are many advantages to using the SSH protocol. First, setting up SSH is relatively simple - the SSH daemon is common, most administrators have experience using it, and most operating systems include it and related management tools. Second, access via SSH is secure - all transmitted data is authorized and encrypted. Finally, like the HTTPS protocol, Git protocol, and local protocols, the SSH protocol is very efficient and compresses data as much as possible before transmission.
shortcoming
The disadvantage of the SSH protocol is that it does not support anonymous access to Git repositories. If you use SSH, then even if you are just reading data, users must access your host through SSH, which makes the SSH protocol not conducive to open source projects. After all, people may just want to clone your warehouse and view it. If you only use it on a corporate network, the SSH protocol may be the only protocol you use. If you want to provide anonymous read-only access and the SSH protocol at the same time, then in addition to setting up an SSH service for your own push, you must also set up a service that can be accessed by others.
2.4 Git protocol
Finally, there is the Git protocol. This is a special daemon included in Git; it listens on a specific port (9418), similar to the SSH service, but does not require any authorization for access. To make the repository support the Git protocol, you need to create a git-daemon-export-okfile first - it is a necessary condition for the Git protocol daemon to provide services for this repository - but there are no security measures other than that. Either anyone can clone this repository, or no one can. This means that pushing via the Git protocol is generally not possible. Since there is no authorization mechanism, once you open the push operation, it means that anyone on the network who knows the URL of the project can push data to the project. Needless to say, very few people do this.
advantage
Currently, the Git protocol is the fastest network transmission protocol used by Git. If your project has a large number of visits, or your project is very large and does not require user authorization for writing, setting up a Git daemon to provide services is a good choice. It uses the same data transfer mechanism as SSH, but eliminates the overhead of encryption and authorization.
shortcoming
The disadvantage of the Git protocol is the lack of authorization mechanism. It is not advisable to use the Git protocol as the only means of accessing the project repository. In general practice, SSH or HTTPS protocol access services are provided at the same time, so that only a few developers have push (write) permissions, and others only have git://read permissions through access. The Git protocol is also perhaps the most difficult to set up. It requires its own daemon process, which requires configuration xinetdor systemdother programs. These tasks are not simple. It also requires the firewall to open port 9418, but enterprise firewalls generally do not open this non-standard port. Large enterprise firewalls usually block this port.
03. Set up git on the server
Before you start setting up a Git server, you need to export the existing warehouse as a bare warehouse - that is, a warehouse that does not contain the current working directory. This is usually very simple. In order to create a new bare repository by cloning your repository, you need to add --barethe option after the clone command. By convention, the directory name of a bare repository ends with .git, like this:
deng@local:~/test/project$ git init
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/deng/test/project/.git/
deng@local:~/test/project$ git add *
deng@local:~/test/project$ git commit -m "初始化项目"
[master （根提交） 09caa6d] 初始化项目
215 files changed, 33668 insertions(+)
deng@local:~/test$ git clone --bare project project.git
克隆到纯仓库 'project.git'...
完成。
deng@local:~/test$
You should now project.githave a copy of the Git directory in your directory.
The overall effect is roughly equivalent to
$ cp -Rf project/.git project.git
Although there are several differences in the configuration files, for your purposes both methods are the same. It only takes out the Git repository itself, not the working directory, and then creates a separate directory specifically for it.
04. Put the bare warehouse on the server
Now that you have a copy of the bare repository, all that's left to do is put the bare repository on the server and set up your protocol. Assume that a deng.comserver with the domain name has been set up and can be connected through SSH. You want to put all Git repositories in the /home/deng/git/directory. Assuming the directory exists on the server /home/deng/git/, you can create a new repository by copying your bare repository with the following command:
deng@local:~/test$ scp -r project.git [email protected]:/home/deng/git
The authenticity of host 'deng.com (10.36.100.57)' can't be established.
ED25519 key fingerprint is SHA256:/nUDhkdz+kuI350kWGwCt0rv4HvTjjlKDtgLO2WjvvI.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:1: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'deng.com' (ED25519) to the list of known hosts.
[email protected]'s password:
At this point, other users who can read /srv/gitthe directory on this server via SSH can run the following command to clone your repository.
deng@local:~/tmp$ git clone [email protected]:/home/deng/git/project.git
正克隆到 'project'...
[email protected]'s password:
remote: 枚举对象中: 241, 完成.
remote: 对象计数中: 100% (241/241), 完成.
remote: 压缩对象中: 100% (235/235), 完成.
remote: 总共 241（差异 55），复用 0（差异 0），包复用 0
接收对象中: 100% (241/241), 382.87 KiB | 7.36 MiB/s, 完成.
处理 delta 中: 100% (55/55), 完成.
deng@local:~/tmp$
If a user connects to a server using SSH and /home/deng/git/my_project.githas writable permissions on the directory, they will automatically have push permissions.
If you run git initthe command in the project directory and add --sharedthe option, Git will automatically modify the group permissions of the warehouse directory to be writable. Note that running this command will not destroy any commits, references, etc. in the project.
deng@local:~/tmp$ ssh [email protected]
[email protected]'s password:
Last login: Tue Sep 12 20:01:49 2023 from 10.36.100.56
deng@local:~$ cd /home/deng/git/project.git/
deng@local:~/git/project.git$ git init --bare --shared
重新初始化已存在的共享 Git 仓库于 /home/deng/git/project.git/
deng@local:~/git/project.git$
This shows how easy it is to create a bare repository based on an existing Git repository, and then put it on a server where you and your collaborators have SSH access. Now you're ready to collaborate on the same project.
It's worth noting that this is really all it takes to set up a Git service that several people have access to - just add an account on the server that can log in with SSH, and then put the bare repository somewhere where everyone has read and write permissions. You've got it all, no more needed.
Small installation
If you have fewer devices or you just want to try Git with a small development team, it's easy. The most complex aspect of setting up a Git service is user management. If you need the warehouse to be readable by specific users, but give read and write permissions to another group of users, then access and permission arrangements will be difficult.
SSH connection
If you have a server that all developers can connect to using SSH, setting up your first repository is very simple because you barely have to do anything (as we said in the previous section). If you want to set up more complex access control permissions on your repository, just use the normal file system permissions of the server operating system.
If everyone in the team needs to have write permissions to the warehouse, but it is not possible to create an account on the server for everyone, then providing an SSH connection is the only option. We assume that the server used to share the repository has the SSH service installed and that you access the server through it.
There are several ways you can provide access to each member of your team. The first one is to create an account for everyone in the team. This method is very straightforward but also very troublesome. Maybe you won't want to run it once for everyone adduser(either useradd) and set temporary passwords.
The second method is to create a 'git' account on the host, have everyone who needs write permissions send an SSH public key, and then add it to the git account's ~/.ssh/authorized_keysfile. This way, everyone will have access to the host through the 'git' account. This does not affect the submitted data at all - the identity used to access the host does not affect the submitter information of the submitted object.
Another way is to have the SSH server perform authorization through an LDAP service or other centralized authorization mechanism that has been set up. As long as each user can gain shell access to the host, you can consider any SSH authorization mechanism to be valid.
05. Generate SSH public key
As mentioned earlier, many Git servers use SSH public keys for authentication. In order to provide an SSH public key to the Git server, a system user must generate one in advance if he or she does not already have the key. The process is similar on all operating systems. First, you need to confirm that you already have the key. By default, a user's SSH keys are stored in their ~/.sshdirectory. You can quickly confirm that you have the key by going into the directory and listing its contents:
deng@local:~/.ssh$ ssh-keygen -o
Generating public/private rsa key pair.
Enter file in which to save the key (/home/deng/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/deng/.ssh/id_rsa
Your public key has been saved in /home/deng/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:7Jo/oxphIEXxRhwJImFBxJBoniGEMj4lKdKAq2W8SD4 deng@local
The key's randomart image is:
+---[RSA 3072]----+
|/%B+oo |
|&O.+o |
|X+* o |
|.B+o . |
|++..o S |
|oE.. . . |
| . . . |
| . oo |
| ..+o.o |
+----[SHA256]-----+
deng@local:~/.ssh$
We need to look for a pair of files named with id_dsaor id_rsa, one of which has .puban extension. .pubThe file is your public key, and the other is the corresponding private key. If no such files are found (or there is no .sshdirectory at all), you can ssh-keygencreate them by running the program. On Linux/macOS systems, ssh-keygenprovided with the SSH package.
deng@local:~/.ssh$ ls
id_rsa id_rsa.pub known_hosts known_hosts.old
deng@local:~/.ssh$
First ssh-keygenit will confirm where the key is stored (default is .ssh/id_rsa), then it will ask you to enter the key password twice. If you don't want to enter a password when using the key, just leave it blank. However, if you are using a password, then make sure to add -othe option, which will save the private key in a format that is more brute-force resistant than the default format. You can also use ssh-agenttools to avoid having to enter your password every time.
Now, the users who did the above need to send their public keys to any Git server administrator (assuming the server is set up with public key-based SSH authentication). All they have to do is copy the contents of their respective .pubfiles and send them via email. The public key looks like this:
deng@local:~/.ssh$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCpeZghbilXBoaqnvU8RF7tWr/RT9NyYZDEuZSOeCPThPq8Y17XA/Kq2lgmHQ9YjZWvw0TxeBSA7YxuntXiw+8oGBw789LXRXxPsZI2FCi6oJPwtm6VCzVEt+t2QXPpg7t9l0l3y2ZXvgL2g5oUpfrrBd/mXuR5XoBdLOi2JobIdaUT02sn1y7kLJeigLitMPK0RloQ9znELTvmbzLBbS+07eiErcerYcavPrDQzOenvraA8md9G+JuKlNBJ9WoxfkCdLPS8TVuO5xlEinFxZB3fu18LefNiuHmhuhKKO+503nwr76/d/V26Sx519/s/5JyjNlskoCWJ/uKUxkGSviwBQS9CoR8nnatZfM5OVgVtoizgX9zFJrg3NUCKC5Y+HWiRv1WWGzO20fXy9JKAkiIAJbSUv3sgfUOFlUzzkTWa0KBZk5DSf3oLKpgZK0hwKYyCYIQsynTfpLfIk9GXtp7/HW5TodYjZl7yLyby/qUpzuV3AHoqomXzYKkghomTpE= deng@local
deng@local:~/.ssh$
For a more in-depth tutorial on generating SSH keys across a variety of operating systems, see GitHub's SSH keys guide https://docs.github.com/cn/authentication/connecting-to-github-with-ssh/generating- a-new-ssh-key-and-adding-it-to-the-ssh-agent.
06. Configure the server
Let's take a look at how to configure server-side SSH access. In this example, we will use authorized_keysthe method to authenticate the user. At the same time, we assume that the operating system you are using is a standard Linux distribution, such as Ubuntu. First, create an operating system user gitand create a .sshdirectory for it.
First, create an operating system user gitand create a .sshdirectory for it.
deng@local:~/tmp$ sudo adduser git
adduser：用户"git"已经存在。
deng@local:~/tmp$ su - git
密码：
git@local:~$ cd
git@local:~$ mkdir .ssh && chmod 700 .ssh
git@local:~$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
git@local:~$
Add these public keys to the end of the file in the system user git's directory :.sshauthorized_keys
git@local:~$ cat /tmp/id_rsa_deng.pub >> ~/.ssh/authorized_keys
git@local:~$
Now let's create a new empty repository for developers. This can be done with the help --bareof the command with the option , which does not create a working directory when initializing the repository:git init
git@local:~$ mkdir project.git
git@local:~$ cd project.git/
git@local:~/project.git$ git init --bare
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/git/project.git/
git@local:~/project.git$
They can then push the initial version of their project to this repository by simply setting this repository as the project's remote repository and pushing branches to it. Please note that every time you add a new project, someone needs to log in to the server to obtain a shell and create a bare warehouse. We assume this is set up with gita user and a Git repository server using git repository gitserveras the hostname. Also, assume that the server is running on the intranet and you have pointed to this server in the DNS configuration gitserver. Then we can run the following command (assuming myprojectit is an existing project and contains files):
deng@local:~/test$ cd project
deng@local:~/test/project$ ls
appveyor.yml cJSON_Utils.c fuzzing README.md
CHANGELOG.md cJSON_Utils.h library_config test.c
cJSON.c CMakeLists.txt LICENSE tests
cJSON.h CONTRIBUTORS.md Makefile valgrind.supp
deng@local:~/test/project$ git init
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/deng/test/project/.git/
deng@local:~/test/project$ git add *
deng@local:~/test/project$ git commit -m "初始化项目"
[master （根提交） 66842fc] 初始化项目
215 files changed, 33668 insertions(+)
deng@local:~/test/project$ git remote add origin [email protected]:/home/git/project.git
deng@local:~/test/project$ git push origin master
The authenticity of host 'git.com (10.36.100.57)' can't be established.
ED25519 key fingerprint is SHA256:/nUDhkdz+kuI350kWGwCt0rv4HvTjjlKDtgLO2WjvvI.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:1: [hashed name]
~/.ssh/known_hosts:14: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'git.com' (ED25519) to the list of known hosts.
枚举对象中: 241, 完成.
对象计数中: 100% (241/241), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (235/235), 完成.
写入对象中: 100% (241/241), 384.45 KiB | 6.63 MiB/s, 完成.
总共 241（差异 53），复用 0（差异 0），包复用 0
remote: 处理 delta 中: 100% (53/53), 完成.
To git.com:/home/git/project.git
* [new branch] master -> master
deng@local:~/test/project$
At this point, other developers can clone this repository and push back their changes. The steps are simple:
deng@local:~/test/tmp$ git clone [email protected]:/home/git/project.git
正克隆到 'project'...
remote: 枚举对象中: 241, 完成.
remote: 对象计数中: 100% (241/241), 完成.
remote: 压缩对象中: 100% (182/182), 完成.
remote: 总共 241（差异 53），复用 241（差异 53），包复用 0
接收对象中: 100% (241/241), 384.45 KiB | 7.25 MiB/s, 完成.
处理 delta 中: 100% (53/53), 完成.
deng@local:~/test/tmp$ cd project/
deng@local:~/test/tmp/project$ ls
appveyor.yml cJSON_Utils.c fuzzing README.md
CHANGELOG.md cJSON_Utils.h library_config test.c
cJSON.c CMakeLists.txt LICENSE tests
cJSON.h CONTRIBUTORS.md Makefile valgrind.supp
deng@local:~/test/tmp/project$ vim README.md
deng@local:~/test/tmp/project$ git commit -a -m "fix the bug"
[master 7e444e8] fix the bug
1 file changed, 1 insertion(+)
deng@local:~/test/tmp/project$ git push origin master
枚举对象中: 5, 完成.
对象计数中: 100% (5/5), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (3/3), 283 字节 | 283.00 KiB/s, 完成.
总共 3（差异 2），复用 0（差异 0），包复用 0
To git.com:/home/git/project.git
66842fc..7e444e8 master -> master
deng@local:~/test/tmp/project$
Through this method, you can quickly build a Git server with read and write permissions for multiple developers.
It should be noted that currently all (authorized) developer users can gitlog in to the server as the system user and obtain a normal shell. If you want to restrict this, you need to modify the shell value /etc/passwdin the file ( gitcorresponding to the user).
With the help of a git-shellrestricted shell tool called , you can easily limit user gitactivities to those related to Git. This tool is provided with the Git package. If is git-shellset to gitthe login shell of user , then that user cannot gain normal shell access to this server. To use it git-shell, you need to replace bash or csh with it to make it the user's login shell. In order to do the above, first you must ensure git-shellthat the full pathname of exists in /etc/shellsthe file:
$ cat /etc/shells # see if git-shell is already in there. If not...
$ which git-shell # make sure git-shell is installed on your system.
$ sudo -e /etc/shells # and add the path to git-shell from last command
Now you can chsh <username> -s <shell>modify the shell of any system user using the command:
$ sudo chsh git -s $(which git-shell)
In this way, users gitcan only use SSH connections to push and pull Git repositories, but cannot log in to the machine and obtain a normal shell. If you try to log in, you will find that the attempt is denied, like this:
$ ssh [email protected]
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
At this point, users can still access any reachable git server through SSH port forwarding. If you want to avoid it, edit authorized_keysthe file and add the following option before all public keys you want to restrict:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
The result is as follows:
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
Now, network-related Git commands can still work normally, but developer users no longer have access to a normal shell. As the output suggests, you can also gitcreate a directory under the user's home directory to git-shellcustomize the command to a certain extent. For example, you can restrict certain Git commands that should be accepted by the server, or customize the SSH rejection login information just now, so that when a developer user tries to log in in a similar way, they will see your information. . To learn more about custom shells, run git help shell.