SSH no permite el uso de una clave con permisos de lectura grupal

9

Tengo un servidor git de desarrollo que se implementa en un servidor en vivo cuando livese empuja la rama. Cada usuario tiene su propio inicio de sesión y, por lo tanto, el post-receiveenlace que realiza la implementación en vivo se ejecuta bajo su propio usuario.

Como no quiero tener que mantener las claves públicas de los usuarios como claves autorizadas en el servidor remoto activo, he creado un conjunto de claves que 'pertenecen al sistema git para agregar a servidores remotos en vivo (en el post-receivegancho que estoy usando $GIT_SSHconfigurar la clave privada con la -iopción).


Mi problema es que, debido a que todos los usuarios pueden querer implementar para vivir, la clave privada del sistema git debe ser al menos legible en grupo y a SSH realmente no le gusta esto.

Aquí hay una muestra del error:

XXXX@XXXX /srv/git/identity % ssh -i id_rsa XXXXX@XXXXX
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

He mirado a mi alrededor esperando encontrar algo que obligue a ssh a seguir adelante con la conexión, pero no he encontrado nada más que personas que dicen ciegamente que no debes permitir el acceso a nada más que a un solo usuario.

Jessie Ross
fuente

Respuestas:

5

Aquí hay una buena manera simple y segura.

Crea un nuevo usuario para la transferencia ssh, lo llamaré git-sync. Cree un usuario similar en el servidor con membresía de grupo para el repositorio git. Agregue la clave pública para sync-user en el archivo de ese usuario users_keys2. Supongo que los usuarios de git son todos miembros del grupo git. Asegúrese de que el usuario git-sync también sea miembro de este grupo.

Ahora edite su archivo / etc / sudoers para incluir una línea como:

%gitgroup ALL=(git-sync) NOPASSWD: /usr/bin/git

Esto permitirá que cualquier miembro del grupo gitgroup ejecute el comando / usr / bin / bit como git-sync sin contraseña.

Ahora ponga algo como esto en su gancho posterior a la recepción:

sudo -u git-sync /usr/bin/git push origin
Kent Hulick
fuente
Esto es mejor de lo que estaba buscando, ¡gracias!
Jessie Ross
11

Usted PUEDE utilizar archivos de identidad legibles grupo, a menos que usted es el propietario de la clave. Entonces, simplemente configure el archivo de identidad para que sea propiedad, por ejemplo, del usuario raíz y luego todos los usuarios de su repositorio git estén listos para funcionar.

Una buena ventaja de esto es que no necesita sudo: la solución será más simple.

Tenga en cuenta que esto se encontrará nuevamente con el problema original si está utilizando root para enviarlo a su repositorio de git.

Linus Swälas
fuente
2
Esto es increíble, y mucho mejor que las respuestas de "no hagas eso". ¡Gracias!
Ian McGowan
2
Permissions 0640 for 'id_rsa' are too open.

La clave privada debe permanecer privada. No debe permitir que nadie lo lea.

Como no quiero tener que mantener las claves públicas de los usuarios como claves autorizadas en el servidor remoto activo, he creado un conjunto de claves que 'pertenecen al sistema git para agregar a servidores remotos en vivo (en el post-receivegancho que estoy usando $GIT_SSHconfigurar la clave privada con la -iopción).

  1. configurar un par de claves para ssh desde el desarrollador hasta el servidor de producción
  2. en el post-receivescript de gancho, intente algo como esto:

    if [ "live" == "$branch" ]; then
        ssh -t user@prod "git --work-tree=... --git-dir=... checkout -f"
    fi
    
quanta
fuente
¿Cómo puedo "configurar un par de claves para ssh desde el desarrollador al servidor de producción"? Esto es con lo que tengo un problema. Ya tengo 2 en su lugar.
Jessie Ross
1
En el desarrollador: ssh-keygen, ssh-copy-id user@prod. En el producto: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys.
quanta
1
El problema es que hay usuarios múltiples, por lo tanto, tengo que repetir eso para cada usuario que quiera editar tiempos por cada proyecto que exista en el servidor.
Jessie Ross
No. Solo necesita configurar dos usuarios más: uno para ssh del desarrollador al producto y otro para ejecutar el git checkout...(en el producto).
quanta
El post-receivegancho (máquina de desarrollo) es ejecutado por el usuario que está presionando un cambio (por lo tanto, con el permiso de los usuarios) para que todos tengan claves diferentes, no puedo evitar qué usuario será. Hay dos post-receiveganchos en dos servidores diferentes en acción.
Jessie Ross