Configurar um servidor Git é fácil e envolve apenas comandos de shell comuns. Esta postagem mostrará como comecei a hospedar meu primeiro servidor Git auto-hospedado. Encontre um computador extra e configure uma conexão SSH com ele e você está pronto para começar. Aqui, usei meu Raspberry Pi, que está sempre ligado [1].

Para configurar o servidor Git, você deve fazer o seguinte na máquina do servidor:

  1. Criar usuário git
  2. Adicionar chaves sshd
  3. Criar diretório de projetos
  4. Criar repositório git vazio
  5. Usar o shell git

Criar usuário git

Este passo é apenas sudo useradd -m git, sem segredos aqui. Agora faça login neste usuário.

Adicionar chaves sshd

Esta parte é a criação do arquivo authorized_keys, para que você possa acessar o SSH com este usuário. Basicamente, você só precisa adicionar as chaves públicas permitidas aqui. No meu caso, eu apenas copiei do meu usuário principal, mas o ideal é criar outra chave e adicioná-la ao servidor Git.

mkdir .ssh
cat new-key.pub > .ssh/authorized_keys
chmod 600 .ssh/authorized_keys 

Agora você deve ser capaz de acessar o seu servidor git usando a chave que você adicionou.

Criar diretório de projetos

Este passo é opcional, mas gosto de criar uma pasta dedicada para meus projetos, então executei: mkdir git, e entrei nela.

Outra coisa legal a fazer é mudar o ramo git padrão:

git config --global init.defaultBranch main

Criar repositório git vazio

Este é o comando que cria um repositório no servidor, para que você possa enviar dados para ele. Para criá-lo, primeiro crie uma pasta e depois execute o comando init:

mkdir project
cd project
git init --bare

Nesta fase, você tem um repositório git totalmente funcional, para usá-lo, prossiga como faria com novos repositórios.

Usando o novo repositório

Agora, em sua outra máquina, você pode iniciar um repositório e enviar:

cd project
git init
git add .
git commit -m 'Commit inicial'
git remote add origin git@:git/project
git push origin main 

Você pode parar por aqui se quiser, mas neste estado existem algumas coisas irritantes no servidor que podem deixá-lo louco, por exemplo:

A próxima seção lidará com esses problemas usando o git shell e algumas configurações.

Usando o git shell

A primeira coisa a melhorar é remover o encaminhamento de porta, então adicione isto no início de cada entrada no arquivo ~/.ssh/authorized_keys:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty 

Agora, os usuários SSH não podem obter um shell de login, apenas o shell não interativo que vamos configurar estará disponível.

Então, devemos definir o git shell para ser usado no login. Faça login na sua máquina do servidor, verifique se o git-shell está listado no arquivo /etc/shells com: cat /etc/shells, se você não vê git-shell lá, você pode adicioná-lo:

sudo echo "$(which git-shell)" >> /etc/shells 

Mas aconselho você a usar um editor. Agora, defina-o como shell de login para o usuário git:

sudo chsh git -s $(which git-shell) 

Agora, você não poderá obter um shell no login. Então, esse usuário é inútil para qualquer outra coisa que não seja o git. Você só pode executar comandos git como pull, push e clone, além dos comandos que criamos em git-shell-commands.

Configurando saudações e comandos

O git-shell pode ser personalizado criando a pasta git-shell-commands na pasta home do git. A primeira e mais engraçada coisa a fazer é simplesmente mostrar uma mensagem quando um login é tentado.

Você pode apresentar uma saudação aos usuários conectando via SSH criando um arquivo chamado no-interactive-login na pasta que acabamos de criar. É engraçado, por exemplo:

#!/bin/sh
echo "Bem-vindo ao seu servidor git!" 

Então, quando o git tentar fazer login no seu servidor, essa mensagem será exibida.

Adicionando programas a esta pasta permitirá que os usuários os executem. Há alguns comandos convenientes para adicionar, por exemplo, criar um novo repositório, excluindo um e listando todos os repositórios. Para torná-los disponíveis, não se esqueça de permitir que eles sejam executáveis:

chmod +x git-shell-commands/program

Um bom ponto de partida é [2].

conclusão

Eu acredito que esta é uma boa configuração, é segura e permite que você interaja completamente com o git, inclusive criando e excluindo repositórios.

Ao mesmo tempo, esta configuração é flexível, já que você pode continuar adicionando novos comandos. Mas há espaço para melhorias, por exemplo, seus repositórios não têm nenhuma visibilidade, não há colaboração.

Adicionar acesso público pode ser feito usando git-daemon ou configurando o git HTTP. Mas esses são assuntos para outros artigos.