Любой начинающий DevOps начинает своё знакомство с Git. Этот инструмент стал неотъемлемой частью рабочего процесса разработчиков по всему миру. Во многих курсах и руководствах по DevOps описывается настройка серверов через популярные платформы, такие как GitLab, изредка через Gitea. Однако мне стало интересно рассмотреть другой путь — использование встроенного в Git инструмента под названием GitWeb.

В данной статье я подробно опишу процесс настройки системы управления репозиториями, используя лишь возможности самого Git. Этот подход может показаться необычным, но он позволяет лучше понять внутренние механизмы работы Git и получить новые навыки, которые могут оказаться полезными в вашей карьере DevOps.

В этом руководстве мы рассмотрим, как настроить собственный Git сервер на базе Debian 12. Весь процесс настройки Git сервера поделен на следующие задачи:

  1. настройка SSH;

  2. создание пользователей;

  3. инициализация проекта;

  4. конфигурация Git‑демона;

  5. настройка веб‑интерфейса для просмотра репозиториев;

  6. настройка дополнительных аспектов безопасности.

Настройка SSH на сервере

Первым шагом является установка и настройка SSH сервера, который обеспечит безопасный доступ к нашему серверу.

Установка пакета openssh-server

Для установки пакетаopenssh-server выполните следующие команды:

apt update
apt install openssh-server

Настройка SSH сервера

Для начала надо открыть файл конфигурации SSH:

nano /etc/ssh/sshd_config

Рекомендуется изменить следующие параметры для повышения безопасности:

  • Port: измените стандартный порт на другой, чтобы уменьшить числа автоматических атак;

  • PermitRootLogin: отключите вход по пользователю root, исключительно после настройки отдельного пользователя для работы с сервером;

  • PasswordAuthentification: отключите вход по паролю, исключительно после настройки ключей;

  • PermitEmptyPasswords: отключите пустые пароли;

  • PubkeyAuthentification: включите аутентификацию по ключам. Обычно данный параметр включен по‑умолчанию.

После внесения изменений перезапустите SSH службу:

systemctl restart sshd

Создание пользователя admin

Зачем использовать отдельного пользователя с sudo?

На это есть ряд причин:

  1. Пользователь root минует все ограничения системы, можно случайно исполнить критические команды, которые могут повредить систему;

  2. Учетная запись root будет в первую очередь атакована злоумышленниками;

  3. sudo позволяет отслеживать действия пользователей, все команды могут быть записаны в журнал.

Естественно, что существует гораздо больше причин почему стоит использовать отдельного пользователя, но моя статья не об этом, поэтому ограничимся этими пунктами.

Настройка пользователя admin

Для управления сервером создайте пользователя admin с правами sudo:

adduser admin
apt install sudo
usermod -aG sudo admin
su admin
cd
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

После установите в конфигурации SSH PermitRootLogin на отрицательное значение и отключите доступ к пользователю root:

sudo nano /etc/passwd
# Меняем root:x:0:0:root:/root:/bin/bash на root:x:0:0:root:/root:/sbin/nologin

Если попробовать зайти в root, то выведется следующие сообщение: This account is currently not available.

Создание пользователя git

Для работы с Git создадим отдельного пользователя git:

adduser git
su git
cd 
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

Ограничение доступа к системе через git-shell

На данный момент пусть пользователь git и не имеет доступа к root правам, он все равно в той или иной мере взаимодействует с системой. Данный пользователь нужен исключительно для работы с репозиториями, однако он все еще имеет доступ к системным командам.

Данное поведение можно исправить используя специальную командную оболочку - git-shell.

git-shell - это ограниченная оболочка, предназначенная для пользователей Git, которые не должны иметь доступ к полноценной командной строке.

Мы можем задействовать данную оболочку следующим образом:

  1. Добавим git-shell к другим оболочкам:

    nano /etc/shells
  2. Внесем следующее содержимое:

    /bin/git-shell
    /usr/bin/git-shell
  3. Cоздадим директорию git-shell-commands:

    mkdir /home/git/git-shell-commands
  4. Теперь изменим командную оболочку по-умолчанию для пользователя git:

    chsh -s $(command -v git-shell) git

Теперь если мы войдем в пользователя git по SSH, то мы ничего не сможем сделать, так как там нету зарегистрированных команд. Если надо создать репозиторий, то мы будем использовать пользователя admin, а затем менять права доступа на директорию через chown.

Однако если нам понадобятся какие-то команды у пользователя git, то мы можем добавить свои собственные команды в директорию git-shell-commands.

Для чего нужна директория git-shell-commands

Данная директория используется для настройки ограниченной среды, когда Git используется через SSH в режиме git-shell. Если данной директории не будет существовать, то мы не сможем использовать пользователя git в интерактивном режиме.

Как добавить команду в git-shell

Для того, чтобы добавить команду для пользователя git, мы должны создать скрипт внутри директории git-shell-commands. Например, создадим скрипт для вывода существующих репозиториев:

  1. Создадим скрипт:

    touch /home/git/git-shell-commands/list-repos
  2. Впишем следующее содержимое:

    #!/bin/bash
    ls /srv/git/
  3. Сделаем его исполняемым:

    chmod +x /home/git/git-shell-commands/list-repos

Теперь мы можем выполнить команду list-repos и она выведет все репозитории.

Настройка SSH клиента для подключения к серверу

Генерация ключей на клиенте

Создайте необходимые SSH ключи на клиенте:

ssh-keygen -t ed25519 -f ~/.ssh/key_for_git -C "Arthur Lokhov <arthurlokhov@gmail.com>"
ssh-keygen -t ed25519 -f ~/.ssh/key_for_admin -C "Arthur Lokhov <arthurlokhov@gmail.com>"

Далее необходимо настроить клиент SSH для работы с только что созданными ключами. Для этого выполним команду:

nano ~/.ssh/config

И запишем следующее содержимое, также не забудем поменять HostName и Port:

Host server_git
  HostName <hostname>
  StrictHostKeyChecking no
  User git
  Port <port>
  ForwardAgent yes
  IdentityFile /home/username/.ssh/key_for_git
  IdentitiesOnly yes
  UserKnownHostsFile=/dev/null
  AddKeysToAgent yes
  ServerAliveInterval 60
  ServerAliveCountMax 1200

Host server_admin
  HostName <hostname>
  StrictHostKeyChecking no
  User admin
  Port <port>
  ForwardAgent yes
  IdentityFile /home/username/.ssh/key_for_admin
  IdentitiesOnly yes
  UserKnownHostsFile=/dev/null
  AddKeysToAgent yes
  ServerAliveInterval 60
  ServerAliveCountMax 1200

Последним шагом будет добавление публичных ключей на сервер. Ключи добавляются в соответствующие пользователям authorized_keys. Если вход через SSH проходит успешно, то отключите вход по паролю для SSH.

Создание "голого" репозитория

После настройки пользователей и SSH, следующий шаг — это инициализация проекта на сервере. В этом разделе рассмотрим как создать «голый» репозиторий, сделать первый коммит и настроить удаленный репозиторий для работы.

Но перед тем как перейти к практической части, я считаю нужным немного погрузиться в теорию.

Что такое "голый" репозиторий?

«Голый» репозиторий(‑bare) используется на сервере, чтобы хранить центральное хранилище кода. Он не содержит рабочей копии файлов и предназначен исключительно для обмена данными между разработчиками, то есть «голый» репозиторий представляет содержимое директории .git.

Как устроена директория .git?

Внутри директории .git находятся различные файлы и директории, которые Git использует для хранения информации о репозитории, включая историю изменений, настройки, ссылки и метаданные.

Данная директория состоит из следующих компонентов:

  1. HEAD: Этот файл содержит ссылку на текущий коммит или ветку, с которой вы работаете;

  2. branches/: данная директория используется для устаревшей механики управления ветками, которая фактически уже не используется в современных версиях Git. Директория обычная пуста и не играет никакой роли в управления ветками;

  3. config: файл конфигурации репозитория, содержащий настройки, такие как информация о пользователе, удаленные репозитории, алиасы команд и другие параметры, специфичные для этого репозитория;

  4. description: файл, который обычно используется в bare репозиториях для описания их назначения. В рабочих репозиториях он не имеет особого значения;

  5. hooks/: директория для хранения скриптов, которые запускаются при определенных действиях Git, таких как коммиты, слияния, получение изменений и другие. Эти скрипты могут быть использованы для автоматизации задач и проверки;

  6. info/: Содержит дополнительные файлы конфигурации, например, файл exclude, который используется для указания шаблонов, игнорируемых только в этом репозитории (локальный аналог .gitignore);

  7. objects/: директория, в которой хранятся все объекты данных, такие как коммиты, деревья, блобы(бинарные файлы) и теги. Эти объекты идентифицируются по их SHA-1 хэшам и являются основой для хранения истории и содержимого репозитория;

  8. refs/: содержит ссылки на коммиты для веток(heads/), тегов(tags/) и удаленных веток(remotes/). Эти ссылки помогают Git отслеживать, где находятся ветки и теги;

  9. logs/: содержит историю изменений ссылок (refs). Например, файл logs/HEAD хранит историю изменений, указывающих на коммиты, на которые ссылался HEAD, что позволяет отслеживать изменения веток.

Взаимодействие Git с директорией .git

Мы разобрали из чего данная директория состоит. Но не разобрали как Git взаимодействует с этими данными. Есть несколько взаимодействий Git с файлами в этой директории:

  1. Коммит(commit): когда вы делаете коммит, Git берет файлы из индекса(index), создает новые объекты в objects/, и обновляет ссылки в refs/heads/ для текущей ветки;

  2. Чекаут(checkout): когда вы переключаетесь между ветками, Git читает ссылки из refs/heads/ и обновляет рабочую директорию до состояния, соответствующего коммиту, на который указывает ссылка;

  3. Пуш(push) и пул(pull): при обмене данными с удаленными репозиториями Git обновляет ссылки в refs/remotes/ и перемещает объекты в objects/;

  4. Управления конфигурацией(config): Git читает файл config для применения настроек, таких как параметры пользователя и удаленные репозитории.

Инициализация проекта

ВАЖНО: Все команды на сервере с этого момента выполняются через пользователя admin

  1. Установим Git, если он еще не установлен:

sudo apt install git
  1. Создадим директорию для хранения проектов и настроим права доступа:

sudo mkdir -p /srv/git
sudo chown git:git /srv/git/
  1. Создадим "голый" репозиторий:

cd /srv/git
sudo mkdir my_project.git
cd my_project.git
sudo git init --bare
cd ..
sudo chown git:git /srv/git/my_project.git/

Настройка локального репозитория и первый коммит

Теперь настроим локальный репозиторий, сделаем первый коммит и отправим его на сервер. Для этого выполним данные команды:

mkdir my_project
cd my_project
git init
echo "# My Project" > README.md
git add README.md
git commit -m "Initial commit"
git remote add origin git@hostname:/srv/git/my_project.git
git push -u origin main

Теперь в файле /srv/git/my_project/refs/heads/main будет хранится указатель HEAD(указатель на последний коммит, сделанный в текущей ветке) на текущий коммит. Он должен быть таким же как и указатель вашего коммита в локальном репозитории. Это будет доказательством того, что процесс прошел успешно.

Настройка демона Git

Git-демон позволяет предоставлять доступ к репозиториям через протокол git://, что обеспечивает быструю и легкую настройку для анонимного чтения.

Про команду git daemon

Данная команда, используется для управления Git-демоном, что можно понять из названия. С помощью этой команды мы и будет взаимодействовать с нашим демоном. С этой командой мы будем использовать следующие флаги:

  1. reuseaddr означает, что сервер будет перезапускаться без ожидания тайм-аута существующих подключений;

  2. export-all означает, что будут экспортированы все проекты из репозитория, иначе для каждого проекта надо создавать файл git-daemon-export-ok;

  3. base-path означает, что данный путь будет автоматически подставляться. То есть вместо git://hostname/srv/git/my_project.git можно будет использовать git://hostname/my_project.git.

Создание службы для systemd.

Так как systemd является самой распространенной системой инициализации, то и примеры я буду приводить для нее. Сам же я использую Devuan с OpenRC, но смысла приводить настройки для другой системы инициализации я не вижу.

Теперь же перейдем к самому процессу.

  1. Создадим файл службы для Git-демона:

sudo nano /etc/systemd/system/git-daemon.service
  1. Пропишем следующее содержимое:

[Unit]
Description=Git daemon

[Service]
ExecStart=/usr/bin/git daemon --reuseaddr --export-all --base-path=/srv/git/ /srv/git/
Restart=always
RestartSec=500ms

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=git-daemon

User=git
Group=git

[Install]
WantedBy=multi-user.target
  1. Запустим и активируем службу.

sudo systemctl enable git-daemon
sudo systemctl start git-daemon
sudo systemctl status git-daemon

Настройка GitWeb

GitWeb предоставляет веб-интерфейс для просмотра репозиториев Git. Мы рассмотрим два способы настройки:

  • с использованием встроенной в Git команды - git instaweb;

  • с использованием CGI(Common Gateway Interface) и веб-сервера Nginx.

Использование git instaweb

git instaweb позволяет быстро развернуть веб-интерфейс отдельно для каждого репозитория.

  1. Установим lighttpd, если он еще не установлен:

sudo apt install lighttpd
  1. Перейдем в директорию проекта и запустим git instaweb:

cd /srv/git/my_project.git
git instaweb
  1. Перейдем в браузер и введем адрес http://hostname:1234, чтобы увидеть интерфейс GitWeb.

gitweb with libhttpd
GitWeb, запущенный через команду git instaweb
  1. Завершим работу сервера:

git instaweb --stop

Настройка GitWeb через Nginx

  1. Установим необходимые пакеты:

sudo apt install nginx gitweb fcgiwrap
  1. Настроим Nginx для работы с GitWeb. Создадим конфигурационный файл для работы сайта:

sudo nano /etc/nginx/sites-available/gitweb
  1. Пропишем следующее содержимое:

server {
    listen 80;
    server_name example.com;

    location /index.cgi {
        root /usr/share/gitweb/;
        include fastcgi_params;
        gzip off;
        fastcgi_param SCRIPT_NAME $uri;
        fastcgi_param GITWEB_CONFIG /etc/gitweb.conf;
        fastcgi_pass unix:/var/run/fcgiwrap.socket;
    }

    location / {
        root /usr/share/gitweb/;
        index index.cgi;
    }
}
  1. Активируем конфигурацию:

sudo ln -s /etc/nginx/sites-available/gitweb /etc/nginx/sites-enabled/gitweb
sudo rm /etc/nginx/sites-enabled/default
sudo systemctl restart nginx
  1. Перейдем в браузер и введем адрес нашего сервера, чтобы увидеть интерфейс GitWeb:

nginx with gitweb
GitWeb, запущенный через Nginx
  1. Обновим конфигурацию GitWeb для правильного отображения наших репозиториев:

sudo nano /etc/gitweb.conf
  1. Изменим путь к репозиториям:

$projectroot = "/srv/git";

Теперь наш Git сервер настроен, и у нас есть доступ к репозиториям через SSH, Git-демон и веб-интерфейс GitWeb.

Эта конфигурация обеспечивает как безопасность, так и удобство использования, а также поддержку анонимного и аутентифицированного доступа к репозиториям.

nginx gitweb final
GitWeb, после изменения конфигурации

Дополнительные аспекты безопасности и оптимизации

Защита от brute-force атак

Для дополнительной защиты нашего сервера можно установить и настроить такие инструменты, как fail2ban, которые будут блокировать IP(Internet Protocol)-адреса, совершившие слишком много неудачных попыток входа.

  1. Установим пакет fail2ban:

sudo apt install fail2ban
  1. Настроим fail2ban для защиты SSH:

sudo nano /etc/fail2ban/jail.local
  1. Добавим следующие строки:

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
  1. Создадим файл, необходимый для логов, если он не создан, и перезапустим fail2ban:

sudo touch /var/log/auth.log
sudo systemctl restart fail2ban
sudo systemctl status fail2ban

Настройка брандмауэра

Для ограничения доступа к нашему серверу настроим брандмауэр, например, ufw:

sudo apt install ufw
sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw allow 20/tcp
# Также не забудьте открыть порт, через который у вас работает SSH

Командами выше мы установили ufw и разрешили запросы к портам 443, 20 и 80.

Теперь включим ufw:

sudo ufw enable

Вы можете попробовать закрыть 80-ый порт и открыть GitWeb в браузере, он не откроется.

Автоматическое обновление пакетов

Для обеспечения безопасности системы рекомендуется настроить автоматическое обновление пакетов.

Установим пакет unattended-upgrades и настроим его:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Теперь у нас автоматически будут скачиваться обновления безопасности.

Создание резервных копий

Для предотвращения потери данных важно настроить регулярное создание резервных копий. Мы можем использовать rsync или специализированные инструменты для создания резервных копий репозиториев и конфигураций сервера.

  1. Установим rsync:

sudo apt install rsync
  1. Настроим cron для автоматизации резервного копирования:

crontab -e
  1. Добавим следующее задание, чтобы оно выполнялось ежедневно в 2 часа ночи:

0 2 * * * rsync -avz /srv/git/ /srv/git-backup/

Синтаксис crontab

Параметры идут в следующем порядке:

  1. Минута

  2. Час

  3. День месяца

  4. Месяц

  5. День недели

  6. Команда

Итог

В этом руководстве мы рассмотрели, как настроить собственный Git сервер на базе Debian 12, обеспечив при этом высокий уровень безопасности и функциональности. Мы прошли через установку и настройку SSH, создание пользователей, инициализацию проектов, настройку веб-интерфейса и рассмотрели дополнительные аспекты безопасности, такие как защита от brute-force атак, настройка брандмауэра и автоматическое обновления пакетов. Также мы настроили резервное копирование данных.

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

Что планируется улучшить?

На данный момент у меня в планах изменить или добавить следующие вещи:

  1. Резервной копирование не в другую директорию, а на другой сервер;

  2. Мониторинг через Prometheus и Grafana;

  3. Настроенный CI/CD пайплайн для работы с нашими репозиториями.

На данный момент я обдумываю то, как лучше всего реализовать указанные выше вещи и что еще можно(или даже нужно) было бы добавить. Скорее всего мною будет сделана либо еще одна статья, посвящённая более глубокой настройки работы с репозиторием, либо будет дополнена эта.

P.S

Всем привет, меня зовут Артур Лохов и это моя первая статья на хабре. На выбор такой темы меня сподвигло то, что во многих курсах рассматривается настройка работы с репозиториями исключительно через GitLab, за редкими исключениями в виде Gitea. Я считаю, что любой DevOps должен знать как Git работает изнутри и как его настраивать с нуля, чтобы понимать что скрывается под тем же Gitlab и как он работает.

Одно дело уметь работать с инструментами, а другое дело уметь работать с инструментами и знать как он работает изнутри.

Если вы нашли какую-либо ошибку, пожалуйста дайте мне знать об этом, чтобы я мог ее исправить, ведь я мог забыть указать, что-либо важное. Также приветствуются советы потому, как можно улучшить сервер с Git. Идеи для улучшение, приведенные выше, скорее всего будут мною реализованы, когда я перейду к данным тематикам(CI/CD и мониторинг), и будут оформлены в виде цикла статей, которые будут являться логическим продолжением.

Комментарии (21)


  1. randomsimplenumber
    25.06.2024 07:07
    +4

    А теперь самое интересное. Администрирование. Как добавить пользователя в систему? Как добавить репозиторий? Как раздавать права? Как просматривать, у кого куда есть доступ? Как удалить пользователя? Как делегировать права на администрирование?


  1. mirv
    25.06.2024 07:07
    +5

    Зачем это все, когда есть готовые решения типа gitea? Администрирование таких решений проще в разы, не требуется лепить костыли для работы через вебклиент.


    1. gudvinr
      25.06.2024 07:07
      +3

      Затем, что gitea и gitlab - это не git сервер, а хостинг проектов

      Если нужен git без свистелок, то нет никакого смысла ставить то, что использоваться не будет

      Почему-то многие забывают, что git - это распределённая система контроля версий прежде всего, и уже потом основа для hub/lab/ea и т.д.


  1. Thomas_Hanniball
    25.06.2024 07:07
    +3

    Судя по картинкам интерфейса GitWeb из статьи, сейчас у нас где-то 2007 год. А в качестве тикетной системы автор, видимо, используется Redmine, вместо Jira.

    В 2014 году, когда есть Gitlab, Gitea, GitHub, никто подобные велосипеды из 2007 года не изобретает, т.к. изначально принято пользоваться нормальными и популярными инструментами.


    1. Kil1J0y
      25.06.2024 07:07

      Gitlab и другие инструменты в отличии от простого git+ssh+web из примера будет по производительности быстрее, да и зачем разработчикам все эти gitlab'ы с их красивым интерфейсом, когда основная работа идёт в консоли и репозиторий нужен для синхронизации кода между разработчиками и хранения этого кода. Зачем городить тяжёлые комбайны в виде того же gitlab...


      1. randomsimplenumber
        25.06.2024 07:07
        +1

        Производительность, как правило, пофиг. Узкое место - программист.

        основная работа идёт в консоли

        Хм. Может всё же в IDE? В консоли неудобно код писать.

        Зачем городить тяжёлые комбайны в виде того же gitlab..

        А в чем проблема? Ну, тяжелый. Но его же на raspberry запускают.Зато даёт кучу очень удобных и полезных плюшек.


        1. Dolios
          25.06.2024 07:07
          +1

          Хм. Может всё же в IDE? В консоли неудобно код писать.

          Основная работа с git.


          1. randomsimplenumber
            25.06.2024 07:07

            Если вся работа заключается в git pull/commit -a/push - пожалуй да . Но это не точно. А остальное.. Навигация по коммитам удобнее через gui. конфликты решать удобнее через gui.


            1. Dolios
              25.06.2024 07:07
              +2

              Только всё ровно наоборот. В консоли ты вызываешь команду и знаешь, что она сделает. Что сделает гуй по нажатию на кнопку, неизвестно. А "решать конфликты", это работа с кодом, а не с гитом.


              1. randomsimplenumber
                25.06.2024 07:07

                Что сделает гуй по нажатию на кнопку, неизвестно

                Ох уж этот магический GUI , написанный рептилойдами... Невозможно постичь ихнюю логику.. Нажимаешь кнопку commit - получается commit. У вас не так разве?

                Что программист накодил - то и делает.


                1. Dolios
                  25.06.2024 07:07
                  +1

                  Если вся работа заключается в git pull/commit -a/push - пожалуй да . (c)


                  1. randomsimplenumber
                    25.06.2024 07:07

                    Жаль, что мы так и не услышали начальника транспортного цеха что за работа в git, которая в консоли выполняется в 10 раз быстрее чем в gui. И что за GUI , неизвестно что делающее.


      1. GBR-613
        25.06.2024 07:07
        +1

        B GitWeb есть работа с pull requests? Я слышал, что нет.

        А GitLab не такой уж и тяжёлый, чтобы заморачиваться со всеми этими настройками.

        Если же речь идёт о Git в чистом виде, то понятие Git server это nonsense. Весь смысл распределение системы в том и заключается в том, что нет единого сервера.


    1. feelamee
      25.06.2024 07:07

      ну а в 2024 людям снова нравятся велосипеды)

      вам пора идти вперёд, а то остановились на github, gitlab в своем 14м

      /s


  1. VenbergV
    25.06.2024 07:07
    +4

    Уж простите за занудство. Но sshd_config предназначен для системы и он может измениться при обновлении системы. Для пользовательских настроек предназначена папка sshd_config.d.
    В нее и нужно добавить свой .conf файл со своими настройками.
    И уж из полного занудства, ставить ufw в 2024 году... Хорошо хоть не iptables. Простые правила для nftables не так ужасны в прочтении.


    1. 13werwolf13
      25.06.2024 07:07
      +3

      первый полезный и адекватный коммент.. моё почтение.

      а комментаторам выше могу порекомендовать перестать покупать мерседес ради того чтобы было где посидеть за пределами дома.


    1. ArthurLokhov Автор
      25.06.2024 07:07
      +1

      Привет, спасибо за критику. Про sshd_config.d ты прав, позже исправлю.


  1. ALexhha
    25.06.2024 07:07
    +1

    Я правильно понял, что при таком сетапе у нас все могут писать во все репозитарии ?


    1. ArthurLokhov Автор
      25.06.2024 07:07

      Привет. В моем случае да, но это было сделано ради упрощения. В реальности же, если брать в пример тот же GitHub, все работают по SSH через одного и того же пользователя - пользователя git, но на сервере идет проверка кому принадлежит SSH-ключ(мы его отдельно указываем в настройках GitHub) и считывает его права на чтение, запись и администрирование. То есть для каждого человека создается собственный пользователь с определенными правами, а сервер во время соединения по SSH к пользователю git ищет нужного нам пользователя с тем же ключом и использует его права. Я подумаю как это можно реализовать и может быть добавлю в статью.

      P.S: Поправьте если я не прав.


      1. randomsimplenumber
        25.06.2024 07:07
        +1

        Немного не так. Никаких пользователей не создается. При соединии по ключу запускается враппер, который сопоставляет ключ и репозиторий и решает, достаточно ли прав. В учебных целях можно запилить, но лучше взять готовое.


      1. ALexhha
        25.06.2024 07:07
        +1

        Привет. В моем случае да, но это было сделано ради упрощения.

        я понимаю, но без полноценной авторизации, такой сетап чуть более чем полностью бесполезен. Ну только если вас не два человека