Свой Git‑сервер: настройка и безопасность

Логотип Git

Quick Links

Why Run Your Own Server?
Git Remotes Are Just Someone Else’s Repository

Зачем запускать собственный сервер?

С учётом множества бесплатных хостингов (GitHub, GitLab, Bitbucket) самостоятельный сервер на первый взгляд не обязателен. Но у собственного сервера есть преимущества:

Приватность: репозитории размещены под вашим контролем и не зависят от чужой «облака». Это важно для конфиденциальных проектов.
Отсутствие ограничений по размеру файлов: общие сервисы вводят лимиты (например, GitHub не принимает файлы >100 МБ). Собственный сервер ограничен только объёмом жёсткого диска.
Простота и скорость управления: для небольшого проекта bare‑репозитория достаточно, и вы экономите ресурсы по сравнению с полной платформой.
Гибкость интеграции: можно выбирать CI, бэкапы и сетевые правила по своему усмотрению.

Когда стоит выбрать готовую платформу: если вам нужна веб‑панель, интегрированный CI/CD, управление правами на уровне пользователей и пул‑реквесты «из коробки», лучше установить GitLab CE или использовать хостинг. GitLab Community Edition — бесплатен, даёт веб‑интерфейс и инструменты CI/CD и обычно требует около ~3 ГБ ОЗУ.

Важно: bare‑репозиторий — это не «копия с рабочей областью», а только внутренние данные Git. Он оптимален для сервера‑мастера.

Как работают удалённые репозитории Git

Git использует распределённую модель контроля версий. Ваш локальный клон не подключается ко всем коллегам напрямую, а работает с удалённым «remote», обычно центральным сервером. Когда вы push/пull, вы меняете официальный мастер‑репозиторий на сервере. Когда коллеги fetch, они получают ваши коммиты.

Технически можно устроить полностью децентрализованную схему, где каждый пуллит у каждого. Это трудно в практике: потребуется статический IP и постоянное соединение у всех участников. Поэтому обычно выбирают модель «сервер — клиенты».

Иначе говоря, Git‑сервер — это обычный репозиторий, настроенный как мастер и доступный по сети. Настройка довольно простая.

Быстрая настройка простого сервера (пошагово)

Создайте сервисного пользователя для Git (под ним будут приходить SSH‑поды):

sudo useradd git

Переключитесь на этого пользователя для дальнейшей настройки:

su git

Добавьте публичные SSH‑ключи разработчиков в файл authorized_keys:

nano ~/.ssh/authorized_keys

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

Создайте bare‑репозиторий в домашней директории пользователя git:

git init --bare repository.git

Пояснение: опция –bare создаёт репозиторий без рабочей директории. В папке находятся только внутренние данные Git (то, что обычно лежит в .git). Это экономит место и предотвращает конфликты с текущей веткой.

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

git remote add origin git@example.com:repository.git

Адрес начинается с git@, потому что соединение идёт по SSH под пользователем git. Суффикс :repository.git — это путь относительно домашней папки пользователя git, если вы разместили репозиторий в другом месте, укажите полный путь.

После подключения вы можете push/pull как обычно. Помните: базовый Git не реализует детальных прав, поэтому любой, кто попал под ключ в authorized_keys, получает полный контроль над репозиторием.

Управление доступом и безопасность

Важно не оставлять репозиторий открытым без ограничений. Рекомендуемые практики:

Используйте отдельные SSH‑ключи для каждого пользователя. Никогда не делайте общий личный аккаунт и не раздавайте один ключ.
В authorized_keys можно указывать опции для каждой строки. Примеры опций: no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command=”git-shell -c \”$SSH_ORIGINAL_COMMAND\”\””. Это ограничит действия ключа только Git‑операциями.
Вместо полного shell разрешите git‑shell для сервисного пользователя: смените shell на /usr/bin/git-shell, чтобы запретить выполнение произвольных команд.
Если нужен более детальный контроль, рассматривайте установку GitLab CE, Gitea или Gogs — они дают управление учётными записями и разрешениями.
Настройте брандмауэр, разрешающий только SSH (и веб‑порт, если у вас интерфейс) и закрывающий все лишние порты.
Ограничьте доступ по IP, если у вас стабильные адреса разработчиков.
Включайте двухфакторную аутентификацию на панели управления, если используете веб‑интерфейс.

Важно: простой authorized_keys‑подход удобен, но при росте команды превращается в адовый ручной процесс — подумайте о системе управления учётными записями.

Резервное копирование и хранение

Правила резервного копирования:

Регулярно создавайте бэкапы папки с bare‑репозиториями. Репозиторий можно копировать как обычную папку и хранить копии на другом сервере или в облаке.
Для больших репозиториев используйте инкрементальные бэкапы или зеркальные репозитории (git clone –mirror).
Тестируйте восстановление: периодически восстанавливайте репозиторий из резервной копии на тестовой машине.
Храните резервные копии вне основного сервера — например, на другом хосте или в объектном хранилище.

Альтернативные подходы

Если вам нужно не только bare‑репозиторий, рассмотрите:

GitLab CE — полнофункциональная платформа с веб‑интерфейсом, управлением прав, CI/CD и пул‑реквестами. Требует больше ресурсов, но даёт готовую инфраструктуру.
Gitea/Gogs — лёгкие, простые, самохостящиеся интерфейсы с управлением пользователями; занимают мало ресурсов.
Хостинг у провайдера — экономит время на поддержку сервера и бэкапы.
NAS с поддержкой Git — удобен для локальных команд.

Совет: если у вас есть неограниченное свободное место и вы не хотите настраивать UI и CI, bare‑репозиторий остаётся самым простым и надёжным вариантом.

Безопасность: жёсткая конфигурация (рекомендации)

Используйте ключи с сильной защитой (ed25519/ecdsa) вместо устаревших RSA при возможности.
Отключите пароли для SSH; разрешите только ключи.
Включите fail2ban или аналог для защиты от перебора паролей и атак на SSH.
Разделяйте привилегии: системный пользователь git не должен иметь sudo.
Минимизируйте доступ к логам и бэкапам.

Чек‑лист по ролям

Администратор:

Создать пользователя git и директорию репозиториев.
Настроить SSH и проверить вход по ключу.
Ограничить shell до git‑shell.
Установить бэкапы и периодические тесты восстановления.
Настроить брандмауэр и fail2ban.

Разработчик:

Сгенерировать личный SSH‑ключ (без пароля храните только на локальной машине при соответствующих рисках).
Передать публичный ключ администратору.
Настроить имя и email в git config.

План действий при инциденте и откат (Runbook)

Обнаружение: кто и когда сделал нежелательный push.
Изолировать доступ: временно удалить соответствующий ключ из authorized_keys и заблокировать SSH‑доступ.
Откат изменений: если нужно вернуть состояние — использовать git reflog или восстановленный бэкап; для экстренного отката можно force‑push из проверенной копии.
Анализ: проверить журналы SSH, определить, как произошёл инцидент.
Восстановление доступа: заменить скомпрометированные ключи и потребовать от пользователей регенерации ключей.
Документирование и улучшение процедур безопасности.

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

Удалённый репозиторий доступен по SSH и принимает push/pull.
Права доступа ограничены ключами, shell пользователя git — git‑shell.
Работают регулярные бэкапы и проверка восстановления.
Журналы атак собираются и анализируются.

Миграция и совместимость

Если переносите репозитории с GitHub/GitLab: используйте git clone –mirror на исходной платформе и затем git push –mirror на ваш сервер.
Для больших бинарных файлов рассмотрите Git LFS или внешние хранилища; bare‑репозиторий сам по себе не решит проблемы с большими двоичными файлами.
Обратите внимание на хуки и интеграции: если у вас были CI‑скрипты в облаке, их нужно адаптировать.

Пример зеркального клонирования и загрузки:

git clone --mirror git@github.com:example/project.git
cd project.git
git remote set-url --push origin git@yourserver.com:project.git
git push --mirror origin

Тесты и критерии приёмки

Простейшие тесты после настройки:

Тест SSH‑подключения: ssh -T git@yourserver.com (ожидается ответ без приглашения shell).
Клонирование: git clone git@yourserver.com:repository.git
Push новой ветки и fetch с другого клиента.
Восстановление из бэкапа на другом хосте.

Маленький глоссарий (1 строка для каждого термина)

bare‑репозиторий: репозиторий без рабочей директории, содержащий только внутренние объекты Git.
git‑shell: ограниченный shell для выполнения только git‑команд через SSH.
mirror: полная зеркальная копия репозитория, включая все refs и теги.

Частые вопросы

Q: Можно ли дать разным людям разные права на один bare‑репозиторий? A: В базовом подходе с единым пользователем git — нет. Для прав на уровне пользователей используйте GitLab, Gitea или настройте отдельные сервисные учётные записи и межсерверные хуки.

Q: Что лучше для небольшого офлайн‑проекта — bare‑репозиторий или GitLab? A: Для минимализма достаточно bare‑репозитория. Для удобства командной работы и веб‑интерфейса — GitLab CE или Gitea.

Q: Как защитить ключи разработчиков? A: Настройте политику хранения ключей, не храните приватные ключи на общих машинах, периодически меняйте ключи и используйте passphrase при необходимости.

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

Запуск собственного Git‑сервера — разумный выбор, если вам нужен контроль, приватность или отсутствие ограничений по размеру файлов. Для одного‑двух репозиториев достаточно bare‑репозитория и авторизации по SSH‑ключам. При росте команды и потребности в управлении правами переходите на GitLab CE, Gitea или другой самохостящийся сервис. Не забывайте про безопасность: ограничьте shell, используйте ключи, настраивайте бэкапы и мониторинг.

Важно: простая настройка работает быстро, но растущей команде будет нужен более надёжный процесс управления доступом и резервирования.

Примечание: если вы планируете использовать веб‑интерфейс и CI, заложите дополнительные ресурсы (оперативную память и диск) и время на настройку.