☰

Seguridad: servidor git con autenticación ssh

tag-icon • tag-icon linux ssh security unix
Seguridad: servidor git con autenticación ssh
  1. Creé el usuario 'git-server'
  2. Instaladoopenssh-server
  3. Modificado /etc/ssh/sshd_configagregadoPasswordAuthentication no
  4. Agregado al .ssh/authorized_keyscaso público de mis colegas.

Preguntas:

  • ¿El usuario 'git-server' es seguro para mi sistema? ¿Cuál es el peor escenario para el sistema si el malhechor obtiene acceso a 'git-server', siempre que 'git-server' seasudoer
  • ¿Cómo puedo prohibir 'git-server' todas las operaciones aparte de gitlos comandos?

Respuesta1

Debe cambiar el shell predeterminado del usuario git-server a git-shell.

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

Este es un shell de inicio de sesión para cuentas SSH para proporcionar acceso restringido a Git. Permite la ejecución solo de comandos Git del lado del servidor que implementan la funcionalidad pull/push, además de comandos personalizados presentes en un subdirectorio llamado git-shell-commands en el directorio de inicio del usuario.

Respuesta2

Bueno, veamos cómo configuras esa cuenta de git-server en el sistema.

Modificado /etc/ssh/sshd_config agregado ContraseñaAuthentication no

Debido a que configura la autenticación de contraseña en no, intentar iniciar sesión en el sistema con ese nombre de forma remota es prácticamente imposible sin una clave SSH válida. Hasta donde yo sé, no creo que las claves ssh hayan sido descifradas, ya que depende del cifrado y la complejidad del cifrado que esté utilizando para determinarlo.

Así que ahora ese hecho queda fuera del camino, si alguien logró obtener acceso a esa cuenta. Lo más probable es que signifique que alguien que ya tenía acceso a su sistema y al que se le otorgaron privilegios para usar su lo habría hecho, o de alguna manera, si bloqueó su sistema correctamente, alguien obtuvo acceso a la raíz, lo cual es más imposible que obtener acceso al cuenta del servidor git. Pero si ese no es el caso e iniciaron sesión en esa cuenta de forma remota usando SSH, entonces todos los que usan SSH están en problemas, ya que eso significaría que cualquier sistema que use ssh sería vulnerable. Ahora el mayor daño que se puede hacer es la misma cantidad de daño que puedes causar con tu cuenta normal con privilegios de sudo.

Respuesta3

Algunas variables para configurar si es necesario seguirlas junto con sugerencias...

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

... que se escribirá desde la perspectiva de su cuenta de administrador del servidor.

  1. Creé el usuario 'git-server'

¿Por casualidad lo bloqueaste y lo convertiste en una cuenta del sistema?

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

Tenga en cuenta que si $(which git-shell)se resuelve en una ruta de archivo pero --shellla opción muestra errores, entonces...

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

... puede ser útil agregar la git-shellruta al /etc/shellsarchivo

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

¿Tienes inhabilitado?root¿Autenticación de contraseña a través de SSH?

/etc/ssh/sshd_configcosas que pueden ser de ayuda...

permitrootlogin without-password


## Additionally consider locking-down other unneeded features
Match Group git-devs
  AllowTcpForwarding no
  AllowStreamLocalForwarding no
  PermitOpen none
  1. Agregado al .ssh/authorized_keyscaso público de mis colegas.

¿Dónde exactamente agregaste sus claves públicas?

Aquí hay algunos comandos de ejemplo para configurar tres cuentas de 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

¿El usuario 'git-server' es seguro para mi sistema? ¿Cuál es el peor escenario para el sistema si el malhechor obtiene acceso a 'git-server', siempre que 'git-server' seasudoer

No, y si ha agregado las claves de todos a la misma cuenta y esa cuenta es sudoer, entonces la cantidad decombustible de pesadillaPodría apagar esta situación con casi ilimitado...

¿Cómo puedo prohibir 'git-server' todas las operaciones aparte de los comandos git?

Agregue git-shell-commands/no-interactive-loginscript a cada cuenta de 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

... siempre que no haya otros archivos ejecutables dentro del git-shell-commanddirectorio, la cuenta se limitará a comandos git no interactivos; siempre que el shell de la cuenta también esté configurado correctamente.

Lo anterior no es lo más seguro pero está equilibrado con la conveniencia;

  • git-devsEl grupo debe ser diferente para cada cuenta si no se desea la clonación cruzada, por ejemplo, name-onepodría (cuando el grupo principal se comparte entre cuentas), git clone name-two@server:/srv/git-devs/name-two/project-namesi supieran cómo estaban estructuradas las cosas en el lado del servidor.

Tenga en cuenta que si los permisos 600podrían deshabilitarse por proyecto dentro de una cuenta individual, y si los permisos 660permitirían al grupo compartido pushasí como pulla un repositorio... personalmente creo 640que es elmejorde ambas opciones, ya que esto permite que un grupo comparta código entre sí sin mucho temor de que un extraviado git push -fde otra cuenta arruine las cosas.

  • Para ver ejemplos de otros git-shell-commandsscripts, considere consultar elgit-utilities/git-shell-commandsrepositorio, de donde se adaptaron los consejos anteriores, aunque eso seríaconsejolas cosas aún más hacia la conveniencia.

En brevenoagregue los scripts vinculados anteriormente si no puede confiar en que los clientes no lo intentenpop-ah-shellporque tales cosas están diseñadas para que elnecesidadpara un shell interactivo no es tan frecuente.

Puntos extra

  • Consulte man --pager='less -p "ChrootDirectory"' sshd_configlas sugerencias sobre lo que se puede hacer para proteger aún más el servidor SSH.

  • verificar man git-shelly man git-daemonobtener documentación relacionada; Habrá algunas opciones útiles para bloquear cosas y/o hacer que sea un poco más fácil comunicarse con el servidor, por ejemplo. --strict-paths, --base-path=<path>y --listen=<host_or_ipaddr>podría valer la pena investigar más

Si hay algo cuestionable sobre lo anterior, considere comentar para que se pueda mejorar esta respuesta.

información relacionada