Let's see how to configure ssh access on the server side. In this case, we will use the authorized_keys method to authenticate the user. At the same time, we assume that the operating system you use is a standard Linux distribution, such as Ubuntu. First, create an operating system user git and create a. ssh directory for it.
$ sudo adduser git $ su git $ cd $ mkdir .ssh && chmod 700 .ssh $ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
Next, we need to add some developer SSH public keys to the authorized keys file of git, the system user. Suppose we have obtained several trusted public keys and saved them in a temporary file. Like before, these public keys look like this:
$ cat /tmp/id_rsa.john.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair
Add these public keys to the end of the authorized keys file in git's.ssh Directory:
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
Now let's create a new empty warehouse for developers. You can do this with the git init command with the – bare option, which does not create a working directory when initializing the warehouse:
$ cd /opt/git $ mkdir project.git $ cd project.git $ git init --bare Initialized empty Git repository in /opt/git/project.git/
Then, any one of John, Josie, or Jessica can push the original version of their project to the warehouse. He only needs to set the warehouse as the remote warehouse of the project and push branches to it. Note that for every new project added, someone needs to log in to the server to get the shell and create a bare warehouse. Let's assume that the server with git users and git warehouse set uses gitserver as the host name. At the same time, suppose the server is running on the intranet, and you have pointed gitserver to this server in the DNS configuration. Then we can run the following command (assuming myproject is an existing project and contains files):
# on John's computer $ cd myproject $ git init $ git add . $ git commit -m 'initial commit' $ git remote add origin git@gitserver:/opt/git/project.git $ git push origin master
At this time, other developers can clone the warehouse and push back their changes. The steps are simple:
$ git clone git@gitserver:/opt/git/project.git $ cd project $ vim README $ git commit -am 'fix for the README file' $ git push origin master
In this way, you can quickly build a Git server with read and write permissions for multiple developers.
It should be noted that at present, all (authorized) developers can log in to the server as git user of the system to obtain a common shell. If you want to limit this, you need to modify the shell value in the passwd file (corresponding to git users).
With a limited shell tool called git shell, you can easily restrict users' git activities to git related areas. The tool comes with the GIT package. If the GIT shell is set as the login shell of user git, then user git cannot obtain the normal shell access of this server. To use git shell, you need to replace bash or csh with it to make it the login shell of the system user. To do this, first you must make sure that the GIT shell already exists in the / etc/shells 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 vim /etc/shells # and add the path to git-shell from last command
Now you can use the Chsh < username > command to modify the shell of any system user:
$ sudo chsh git # and enter the path to git-shell, usually: /usr/bin/git-shell
In this way, users git can only use SSH connection to push and pull git warehouse, instead of logging in to the machine and getting a normal shell. If you try to log in, you'll find that the attempt is denied, like this:
$ ssh git@gitserver fatal: Interactive git shell is not enabled. hint: ~/git-shell-commands should exist and have read and execute access. Connection to gitserver closed.
Now, GIT commands related to the network can still work normally, but developers and users can't get a normal shell. As the output indicates, you can also create a directory under git user's home directory to customize git shell commands to a certain extent. For example, you can restrict some git commands that should be accepted by the server, or customize the login rejection information of SSH just now, so that when a developer user tries to login in a similar way, he will see your information. To learn more about customizing the shell, run git help shell.
ShaCoder 19 original articles published, praised 0, and 537 visitors Private letter follow