Приватный Git‑сервер на Linux

Кратко: развернуть приватный Git‑сервер на Linux можно за 5 шагов — установить Git, создать пользователя git, настроить SSH‑ключи, выделить папку для репозиториев и инициализировать bare‑репозиторий. В статье есть пошаговые команды, советы по безопасности, резервному копированию и руководство по обслуживанию.

Конфигурация Git‑сервера: терминал и файлы конфигурации

Почему и когда стоит хостить собственный Git‑сервер

Внешние сервисы вроде GitHub, GitLab или Bitbucket удобны, но локальный сервер нужен когда важны приватность, контроль над доступом, соответствие политикам компании или когда требуется тонкая кастомизация рабочего процесса. Локальный сервер полезен для:

частной разработки и закрытых проектов;
работы в локальной сети без интернета;
соответствия требованиям по хранению данных;
обучения и тестирования CI/CD в изолированной среде.

Определение: bare‑репозиторий — это репозиторий без рабочей копии, предназначенный только для обмена (push/pull) между клиентами.

Требования и рекомендации перед установкой

Нужен свободный сервер или виртуальная машина в облаке с Linux.
Рекомендуемые ресурсы: 1 ГБ RAM, 1 vCPU, подходящий объём диска в зависимости от репозиториев. Для командного использования и CI выделите больше ресурсов.
Доступ по SSH к серверу или физический доступ.
Наличие учётной записи администратора или sudo.

Важно: не придумывайте паролей в явном виде для автоматизации. Используйте SSH‑ключи.

Шаг 1: установить Git на сервере

Вывод команды git в терминале

Установите Git через пакетный менеджер вашей системы. Примеры:

# Debian / Ubuntu
sudo apt update
sudo apt install git

# Arch
sudo pacman -Syu
sudo pacman -S git

# RHEL / CentOS / Fedora
sudo dnf install git

Проверьте версию:

git --version

Если у вас строгие политики безопасности, заранее проверьте подписанные пакеты и используйте репозитории провайдера.

Шаг 2: создать отдельного пользователя git

SSH-подключение и создание пользователя git на сервере

Для безопасности создайте системного пользователя, под которым будут храниться все репозитории:

# от пользователя с sudo
sudo adduser --system --shell /usr/bin/git-shell --group --disabled-password --home /home/git git

Пояснение: git-shell ограничит возможности входа и позволит выполнять только git‑команды по SSH.

Если вы предпочитаете оболочку по умолчанию, можно назначить /bin/bash, но это менее безопасно.

Шаг 3: настроить SSH‑ключи и authorized_keys

Добавление публичного SSH‑ключа в authorized_keys

Добавляйте SSH‑ключи клиентов в /home/git/.ssh/authorized_keys. Порядок действий:

# переключиться на пользователя git
sudo -i -u git
cd ~
mkdir -m 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

На клиенте сгенерируйте ключ, если его ещё нет:

# на клиенте
ssh-keygen -t ed25519 -C 'your_email@example.com'
# или rsa для совместимости
ssh-keygen -t rsa -b 4096
cat ~/.ssh/id_ed25519.pub

Скопируйте содержимое публичного ключа и вставьте его в /home/git/.ssh/authorized_keys на сервере. Каждой записи можно предшествовать опциями, ограничивающими команды и время доступа. Пример для ограничения командой git-shell:

command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3... user@example

Совет: используйте менеджер конфигурации или Ansible для централизованного распределения ключей, если много пользователей.

Шаг 4: создать структуру для репозиториев

Выберите корневую папку, где будут храниться все bare‑репозитории. Пример:

sudo -i -u git
mkdir -p /home/git/repos
cd /home/git/repos

Организация: можно хранить проекты по группам, например /home/git/repos/team/project.git

Права и владелец:

sudo chown -R git:git /home/git/repos
sudo chmod -R 770 /home/git/repos

Шаг 5: создать первый bare‑репозиторий и подключиться с клиента

# на сервере от имени git
cd /home/git/repos
mkdir new_project.git
cd new_project.git
git init --bare

На клиенте добавьте remote и запушьте:

# на клиенте в существующем проекте
git remote add origin git@server.example.com:/home/git/repos/new_project.git
# если ещё нет локального коммита
touch README.md
git add README.md
git commit -m 'init project'
git push -u origin master

Проверка: клонируйте репозиторий в другой каталог или устройство:

git clone git@server.example.com:/home/git/repos/new_project.git

Если возникает ошибка permission denied, проверьте authorized_keys, права на .ssh и владельца каталога репозиториев.

Советы по безопасности и жёсткому ограничению доступа

Отключите вход по паролю в /etc/ssh/sshd_config с помощью PasswordAuthentication no и перезапустите sshd.
Отключите вход под root: PermitRootLogin no.
Используйте нестандартный порт SSH, чтобы снизить шум в логах. Это не считается настоящей защитой, но уменьшает автоматический сканер.
Назначьте git‑шелл для пользователя git: /usr/bin/git-shell. Это запретит выполнение произвольных команд.
Фаерволл: разрешайте доступ только на нужный SSH‑порт и IP, если возможно.
Регулярные обновления ОС и пакетов.
Мониторинг входов и логов: настройте лог‑ротирование и оповещения по подозрительным попыткам.
Используйте fail2ban или похожие инструменты для блокировки грубых попыток взлома.

Важно: храните резервные копии ключей и проверяйте список authorized_keys при увольнении сотрудников.

Резервное копирование и восстановление (SOP)

Единый простой план бэкапа:

Остановить кратковременно доступ или ограничить записи (по возможности).
Создать архивацию каталога репозиториев с сохранением прав владельцев.

sudo rsync -aH --delete /home/git/repos/ /mnt/backup/git_repos/
# или tar
sudo tar -C /home/git -czf /mnt/backup/git_repos_$(date +%F).tar.gz repos

Проверить целостность архива, считать список репозиториев и выполнить локальные тесты клонирования.
Хранить несколько точек восстановления вне основного сервера (offsite).

Восстановление: распаковать архив в нужную директорию, восстановить владельца и права, затем протестировать клонирование и пуш.

Роль‑базовый чеклист для администратора

Администратор должен пройти следующие шаги при создании нового репозитория и выдаче доступа:

создать bare‑репозиторий в каталоге repos;
присвоить владельца git и права доступа;
добавить SSH‑ключ пользователя в authorized_keys;
протестировать клонирование от имени пользователя;
добавить запись в документ учёта доступа (кто и когда получил доступ).

Альтернативы и когда их выбрать

Gitolite — инструмент для управления правами доступа на базе SSH; полезен для тонкого контроля прав по веткам и репозиториям.
Gitea / GitLab CE — полноценные веб‑интерфейсы с UI, issue tracking, CI; подходят когда нужна интеграция и удобство для команды.
HTTPS + Basic/Auth или OAuth — используйте если SSH запрещён корпоративной сетью, но HTTPS требует настройки веб‑сервера и сертификатов.

Выбор: если нужна только простая синхронизация по SSH, достаточно подхода описанного в статье. Для бизнеса с задачами управления доступом выбирайте Gitolite или Gitea.

Отладка и распространённые ошибки

permission denied (publickey): проверьте права на ~/.ssh, /home/git/.ssh/authorized_keys и правильность ключа.
fatal: destination path exists: клонируете в непустую папку — используйте пустую директорию.
ssh: connect to host host port 22: Connection refused: сервис sshd не запущен или порт закрыт.

Команда для проверки SSH‑подключения:

ssh -v git@server.example.com

Эта команда покажет, какие ключи предлагаются и где процесс обрывается.

Критерии приёмки

Репозиторий успешно клонируется с другого хоста.
У пользователя есть доступ по SSH без пароля.
Все файлы и теги присутствуют после push и clone.
Бэкап выполнен и проверен на тестовом восстановлении.

План отката при ошибочном удалении репозитория

Если есть локальные копии пользователей, попросите временно не пушить.
Восстановите репозиторий из последнего архива.
Проверьте права и запустите тестовое клонирование.
Сообщите команде о восстановлении и проведите аудит доступа.

Мини‑методика для миграции с внешнего хоста (например GitHub)

На сервере в /home/git/repos создайте target.git и инициализируйте bare.
На локальной машине добавьте remote для нового сервера и запушьте все ветки и теги:

git remote add localgit git@server.example.com:/home/git/repos/target.git
git push --all localgit
git push --tags localgit

Проверьте истории, PR можно экспортировать отдельно средствами внешнего сервиса.

Факт‑бокс: ключевые числа

Рекомендуемая начальная RAM: 1 ГБ
Минимальный порт SSH: 22 (можно менять)
Типичные ключи: ed25519 или rsa 4096
Время базового развёртывания: 10–30 минут

Примеры конфигураций и сниппеты

Пример строки в authorized_keys с ограничением команды:

command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3... user@example

systemd юнит для резервного копирования (примерный):

[Unit]
Description=Daily git repos backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup_git_repos.sh

[Install]
WantedBy=multi-user.target

Ментальные модели при выборе архитектуры

Простая модель: SSH + bare репозитории — минимум компонентов, максимум надежности.
Средний уровень: SSH + Gitolite — контроль прав и централизованное управление.
Полный уровень: Gitea/GitLab — интерфейс, CI, интеграции, но выше сложность поддержки.

Диаграмма принятия решения

flowchart TD
  A[Требуется приватный Git сервер?] -->|Да| B{Нужен UI и CI?}
  B -->|Нет| C[SSH bare репозитории]
  B -->|Да| D{Нужны права на уровне веток?}
  D -->|Да| E[Gitolite или GitLab]
  D -->|Нет| F[Gitea]
  A -->|Нет| G[Использовать GitHub / облачный сервис]

Короткая инструкция для новых пользователей команды

Сгенерировать SSH‑ключ: ssh-keygen -t ed25519
Отправить публичный ключ администратору
Клонировать репозиторий: git clone git@server:/home/git/repos/project.git
Пушить привычным способом: git push

Часто задаваемые вопросы

Как подключиться с Windows

Используйте Git for Windows и SSH ключи через встроенный OpenSSH или PuTTY. В случае PuTTY конвертируйте ключ в формат ppk.

Можно ли использовать HTTPS вместо SSH

Да, но для HTTPS нужно настроить веб‑сервер и аутентификацию, а также сертификаты. HTTPS удобен для пользователей за межсетевыми экранами.

Как быстро восстановить случайно удалённый репозиторий

Если есть бэкап, распакуйте архив в /home/git/repos, восстановите владельца git:git и выполните тестовое клонирование.

Итог и рекомендации

Если вам нужен простой, надежный и приватный Git‑сервер без лишнего функционала, описанный SSH‑подход с пользователем git и bare‑репозиториями — лучший старт. Для командных процессов и расширенных функций рассмотрите Gitolite, Gitea или GitLab. Обязательные элементы: управление SSH‑ключами, резервное копирование и базовые меры безопасности.

Важно

Проверяйте права доступа и регулярно делайте бэкапы. Даже при небольшом объёме репозиториев утрата данных может стоить времени и денег.

Как настроить приватный Git‑сервер на Linux