Create a bare repository on a Linux server and access it through SSH to share Git history with a small group. The server repository has no working tree. Understanding this arrangement provides a baseline for deciding whether a web service such as Gitea is needed.
On a separate Rocky Linux 9 or Ubuntu 24.04 lab VM. The example address is 192.168.56.40 and replace it with your environment. Windows PCs run client commands in Git Bash. An existing service server such as WordPress will not be used for this exercise.
Git · GitOps All Series · 14 / 24
On this page
1. Prepare Git and SSH services on the server
Run from an administrator account on Rocky Linux. If SSH is already running, maintain the access policy.
sudo dnf install -y git openssh-server
sudo systemctl enable --now sshd
command -v git-shellIn Ubuntu, package names and service names are different. The block below is not the Rocky command and the steps to run both, but is an alternative for Ubuntu.
sudo apt update
sudo apt install -y git openssh-server
sudo systemctl enable --now ssh
command -v git-shellThe server’s SSH port restricts access to only those users who need it from the management network or VPN. After securing the existing management access path, change the firewall rules. There is no need to allow new password logins or root remote logins because of Git.
2. Create a Git-specific account and repository
git Assumes a new lab VM without an account. If you already have an account used by Gitea, etc., you will not be able to change it. Below is a case where git-shell was resolved to /usr/bin/git-shell in both distributions.
sudo useradd --create-home --shell /usr/bin/git-shell git
sudo install -d -o git -g git -m 0700 /home/git/.ssh
sudo install -o git -g git -m 0600 /dev/null /home/git/.ssh/authorized_keys
sudo install -d -o git -g git -m 0750 /srv/git
sudo -u git git init --bare -b main /srv/git/gitops-demo.gitgit-shell limits shell usage to permitted operations, such as Git transfer commands. A bare repository has no working files to edit like a normal project. This is not a place to directly modify code on the server, but a place to receive pushes and fetches from clients.
3. Register only the public key and compare fingerprints
Create a dedicated SSH key on the client using method 10. The server administrator registers the received public key line in /home/git/.ssh/authorized_keys. You can add restriction options in front of the key as shown below. Replace the description part of the example with the actual public key and save it.
restrict ssh-ed25519 REPLACE_WITH_PUBLIC_KEY client-labelrestrict limits SSH features such as port forwarding and PTY. Keep the key file’s owner git:git, directory permissions 700, and file permissions 600. If multiple users use the same account, managing and retrieving keys and granting permissions for each storage becomes cumbersome, so consider web services when scale increases.
Verifies the fingerprint of the host public key on the server console and passes it to the client user by the trusted path.
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubThe client compares the fingerprint with the fingerprint on the initial connection screen. ssh git@서버 may exit with a message not allowing interactive shells, which is the intended behavior for git-shell accounts. Distinguish from failure of authentication itself.
4. Push the client repository
cd ~/git-lab/gitops-demo
git remote add local ssh://git@192.168.56.40/srv/git/gitops-demo.git
git push -u local main
git ls-remote localIf you already have an alias local, check the URL and rename it. Also check that upstream is changed to local/main with -u. On the server, administrators can view the status with the query command below.
sudo -u git git --git-dir=/srv/git/gitops-demo.git log --oneline -5
sudo -u git git --git-dir=/srv/git/gitops-demo.git fsck --fullfsck verifies the connection and validity of an object, but it does not mean that there is a backup. Include Git repositories, SSH key properties, server host keys, permissions, and settings in your recovery plan. Local bare remote push/clone was confirmed through actual practice, and the entire SSH service/firewall configuration of this VM was not verified.
The account and bare configuration were based on Git on the Server, the shell scope was git-shell, and the key restrictions were OpenSSH authorized_keys. If you need a review and detailed permissions, continue to the next part, Gitea.
Previous · [Git and GitOps 13] Review gitignore, Line Endings, LFS and Secrets · Next · [Git and GitOps 15] Run a Local Gitea Server with Docker Compose · Series list and example files
