Segurança: servidor git com autenticação ssh

Segurança: servidor git com autenticação ssh
  1. Criei o usuário 'git-server'
  2. Instaladoopenssh-server
  3. Modificado /etc/ssh/sshd_configadicionadoPasswordAuthentication no
  4. Adicionado ao .ssh/authorized_keyscaso público dos meus colegas

Questões:

  • O usuário 'git-server' é seguro para meu sistema? Qual é o pior cenário para o sistema se o malfeitor obtiver acesso ao 'servidor git', desde que o 'servidor git' sejasudoer
  • Como posso proibir 'git-server' todas as operações além gitdos comandos?

Responder1

Você deve alterar o shell padrão do usuário git-server para git-shell.

https://git-scm.com/docs/git-shell.html

Este é um shell de login para contas SSH para fornecer acesso restrito ao Git. Ele permite a execução apenas de comandos Git do lado do servidor que implementam a funcionalidade pull/push, além de comandos personalizados presentes em um subdiretório chamado git-shell-commands no diretório inicial do usuário.

Responder2

Bem, vamos ver como você configura essa conta do servidor git no sistema.

Modificado /etc/ssh/sshd_config adicionado PasswordAuthentication não

como você definiu a autenticação por senha como não, tentar fazer login remotamente no sistema com esse nome é virtualmente impossível sem uma chave SSH válida. Até onde eu sei, não acho que as chaves ssh tenham sido quebradas, pois isso depende da cifra e da complexidade da cifra que você está usando para determinar isso.

Então agora esse fato está fora de questão, se alguém conseguiu acessar essa conta. Provavelmente significaria que alguém que já tinha acesso ao seu sistema e que recebeu privilégios para usar su teria feito isso, ou de alguma forma, se você bloqueasse seu sistema corretamente, alguém obteve acesso ao root, o que é mais impossível do que obter acesso ao conta do servidor git. Mas se esse não for o caso e eles fizerem login nessa conta remotamente usando SSH, então todos que usam SSH estarão em apuros, pois isso significaria que qualquer sistema que usa ssh estaria vulnerável. Agora, o maior dano que pode ser causado é a mesma quantidade de dano que você pode causar com sua conta normal com privilégios sudo.

Responder3

Algumas variáveis ​​para definir se houver necessidade de seguir com sugestões...

_git_user='git-user'
_git_group='git-devs'
_git_home_base="/srv/${_git_group}"
_client_certs_root='/home/admin/client-certs'

... que será escrito da perspectiva da sua conta de administrador do servidor.


  1. Criei o usuário 'git-server'

Por acaso você o bloqueou e tornou uma conta do sistema?

sudo adduser\
 --system\
 --disabled-password\
 --gecos ''\
 --shell "$(which git-shell)"\
 --home "${_git_home_base,,}/${_git_user,,}"\
 --ingroup "${_git_group}"\
 "${_git_user}"

Observe que se $(which git-shell)resolver um caminho de arquivo, mas --shella opção exibir erros, então...

if [ -e "$(which git-shell)" ] && ! grep -q -- "$(which git-shell)" /etc/shells; then
    sudo tee -a /etc/shells 1>/dev/null <<<"$(which git-shell)"
fi

... pode ser útil para anexar o git-shellcaminho ao /etc/shellsarquivo



  1. Instaladoopenssh-server
  2. Modificado /etc/ssh/sshd_configadicionadoPasswordAuthentication no

Você desativourootautenticação de senha por SSH?

/etc/ssh/sshd_configdetalhes que podem ser úteis...

permitrootlogin without-password


## Additionally consider locking-down other unneeded features
Match Group git-devs
  AllowTcpForwarding no
  AllowStreamLocalForwarding no
  PermitOpen none

  1. Adicionado ao .ssh/authorized_keyscaso público dos meus colegas

Onde exatamente você adicionou suas chaves públicas?

Aqui estão alguns exemplos de comandos para configurar três contas Git...

declare -a _accounts_keys=(
    ["name-one"]="${_client_certs_root}/${_git_group}/name-one/ssh.pub"
    ["name-two"]="${_client_certs_root}/${_git_group}/name-two/ssh.pub"
    ["name-three"]="${_client_certs_root}/${_git_group}/name-three/ssh.pub"
)



for _name in "${!_accounts_keys[@]}"; do
    sudo su --login "${_name}" --shell /bin/bash <<EOF
mkdir .ssh
tee -a .ssh/authorized_keys 1>/dev/null <<<"$(<"${_accounts_keys[${_name}]}")"
chmod 600 .ssh/authorized_keys
EOF
done

O usuário 'git-server' é seguro para meu sistema? Qual é o pior cenário para o sistema se o malfeitor obtiver acesso ao 'servidor git', desde que o 'servidor git' sejasudoer

Não, e se você adicionou as chaves de todos à mesma conta e essa conta for um sudoer, então a quantidade decombustível de pesadeloEu poderia apagar esta situação com algo quase ilimitado...


Como posso proibir todas as operações do 'git-server' além dos comandos git?

Adicione git-shell-commands/no-interactive-loginscript a cada conta Git...

for _name in "${!_accounts_keys[@]}"; do
    sudo su --login "${_name}" --shell /bin/bash <<EOC
tee 'git-shell-commands/no-interactive-login' 1>/dev/null <<'EOF'
#!/usr/bin/env bash
printf 'Hi %s, you have successfully authenticated!\n' "${USER}"
printf 'However, there is not an interactive shell here.\n'
exit 128
EOF

chmod u+x 'git-shell-commands/no-interactive-login'
EOC
done

... contanto que não haja outros arquivos executáveis ​​no git-shell-commanddiretório, a conta estará limitada a comandos git não interativos; desde que o shell da conta também esteja configurado corretamente.


O que foi dito acima não é o mais seguro, mas equilibrado com conveniência;

  • git-devsO grupo deve ser diferente para cada conta se a clonagem cruzada não for desejada, por exemplo, name-onepoderia (quando o grupo primário é compartilhado entre contas), git clone name-two@server:/srv/git-devs/name-two/project-namese eles soubessem como as coisas estavam estruturadas no lado do servidor.

Observe que se as permissões 600pudessem ser desabilitadas por projeto em uma conta individual, e se as permissões 660permitissem o grupo compartilhado, pushbem como pullpara um repositório ... pessoalmente, acho 640que é omelhorde ambas as opções, pois isso permite que um grupo compartilhe códigos entre si sem muito medo de que alguém git push -fde outra conta estrague tudo.

  • Para exemplos em outros git-shell-commandsscripts, considere verificar ogit-utilities/git-shell-commandsrepositório, de onde as dicas acima foram adaptadas, embora issodicaas coisas ainda mais voltadas para a conveniência.

Resumidamentenãoadicione os scripts vinculados acima se você não puder confiar nos clientes para não tentar epop-ah-conchaporque tais coisas são projetadas para que oprecisarpara um shell interativo não é tão predominante.

Pontos bônus

  • confira man --pager='less -p "ChrootDirectory"' sshd_configdicas sobre o que pode ser feito para proteger ainda mais o servidor SSH

  • verificar man git-shelle man git-daemonobter documentação relacionada; existem algumas opções úteis para bloquear coisas e/ou tornar a comunicação com o servidor um pouco mais fácil, por exemplo. --strict-paths, --base-path=<path>, e --listen=<host_or_ipaddr>pode valer a pena investigar mais


Se houver algo questionável sobre o que foi dito acima, considere comentar para que esta resposta possa ser melhorada.

informação relacionada