☰

Descripción general

tag-icon • tag-icon ubuntu ssh rsync aws
Descripción general

Estoy trabajando con dos instancias de ubuntu en AWS (que uso una clave pem para acceder a ellas).

Configuré rsync para ambas instancias y funciona si uso el usuario predeterminado que es ubuntu@ipaddress. Sin embargo, si intento usar rsync con otro usuario (estoy escribiendo, sudo su - jenkinspor ejemplo, o incluso escribiendo sudoantes del comando rsync), aparece el siguiente error.

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.0]

Pasos que he tomado:

Intenté crear una clave ssh (usando ssh-keygen) mientras estaba conectado jenkinsy la agregué al authorized_keysarchivo tanto en /home/ubuntu/.ssh/authorized_keys(desde donde estoy ejecutando rsync) como incluso $JENKINS_HOME/.ssh/authorized_keys(donde también intenté ejecutar rsync desde allí).

Incluso intenté usar la tecla pem para hacer lo mismo y tampoco funcionó.

Esto es lo que estoy tratando de ejecutar

rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins

Y aquí está el archivo clave.

rsync -avuh --delete -e 'ssh -i path/to/key.pem' [email protected]:/var/lib/jenkins/* /var/lib/jenkins

PD: La única razón por la que no quiero ejecutarlo con el usuario de ubuntu es porque me meto failed: Permission denied (13)en muchas cosas (ya que los archivos son propiedad de jenkins).

Objetivo final:

Estoy tratando de mantener una copia de seguridad constante de la instancia de jenkins de respaldo con la instancia principal haciendo un cronjob:

*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins

Respuesta1

Hay que diferenciar 2 cosas:

  • OMSestablece la conexión SSH.
  • cualel usuario remoto es propietario de los archivosque quieres copiar.

Descripción general

(srcmachine)  (rsync)   (destmachine)
  srcuser    -- SSH -->   destuser
                             |
                             | sudo su jenkins
                             |
                             v
                          jenkins

Digamos que quieres rsync:

  • De:
    • Máquina:srcmachine
    • Usuario:srcuser
    • Directorio:/var/lib/jenkins
  • A:
    • Máquina:destmachine
    • Usuario: destuseraestablecer la conexión SSH.
    • Directorio:/tmp
    • Propietario de los archivos finales: jenkins.

Solución

rsync --rsync-path 'sudo -u jenkins rsync' -avP --delete /var/lib/jenkins destuser@destmachine:/tmp

Explicaciones

     --rsync-path=PROGRAM    specify the rsync to run on the remote machine

El truco consiste en decirle que se ejecute rsyncen la máquina remota con otro usuario ( jenkins) distinto al que establece la conexión SSH ( destuser).

Requisitos

Acceso SSH

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->   destuser

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

No olvide restringir los permisos en ~/.ssh:

chmod 700 ~/.ssh

sudoer para eldestuser

Deben destusertener el privilegio de hacerlo sudo -u jenkins rsync.

En general, configuramos el destusercomo miembro de sudoers. Para hacer esto, en el root@ destmachine:

cat > /etc/sudoers.d/destuser << EOF
destuser ALL=(ALL) NOPASSWD:ALL
EOF

Para probarlo antes rsync, puede iniciar sesión en destuser@ destmachiney ejecutar esto:

sudo su jenkins
echo $USER

Si regresa:

jenkins

significa que ha iniciado sesión como jenkinsusuario y que su rsynccomando también funcionará, porque el privilegio de escalada jenkinsfunciona.

Nota sobre una mala solución: establezca la conexión SSH con el usuario de destinojenkins

¿Por qué no hacemos esto?

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->    jenkins

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

porque jenkinses una cuenta de "servicio", lo que significa que ejecuta un servicio que expone un puerto ( 80más o menos) para acceso HTTP externo, y significa que es POSIBLE que haya una violación de seguridad a través del servicio Jenkins a través de HTTP para obtener acceso .

Es por eso que tenemos www-datausuarios y similares para ejecutar los diferentes servicios. En caso de que sean pirateados desde los puertos que exponen, no podrán hacer mucho:

  • todo es de sólo lectura para ellos.
  • excepto escribir en /var/log/THE_SERVICE.

Por lo tanto, permitir el acceso SSH al jenkinsusuario expone un ataque superficial (¡y lo mismo ocurre con el acceso SSH root!).

Además, si desea realizar rsync como otro usuario ( root,, www-dataetc.), deberá copiar su clave pública SSH a esas cuentas (problemático).

Buena solución: Deberías configurarAcceso SSH al menor número posible de cuentas de usuario( destuser) esoPUEDE escalara la cuenta de "servicio" que desee ( jenkins, root, etc.).

Respuesta2

Tuve un problema similar con rsyncing como otro usuario. Lo resolvió ejecutando el siguiente comando:

rsync -avu -e "ssh -i my-key -o StrictHostKeyChecking=no -l user-i-want-to-use-in-rsync" ./local_dir remote_host:remote-host-dir

Tenga en cuenta que tal vez necesite jugar con las claves para poder ejecutar rsync como otro usuario.

Respuesta3

sudo -u jenkins -i rsync ...

consin comillas.

La -iopción hace que el sudocomando se ejecute con el entorno del usuario, incluidas las claves ssh .profile, .bash_profileetc.

Del sudohombre:

-i, --login

Ejecute el shell especificado por la entrada de la base de datos de contraseñas del usuario de destino como shell de inicio de sesión. Esto significa que el shell leerá los archivos de recursos específicos de inicio de sesión, como .profile, .bash_profileo . .loginSi se especifica un comando, se pasa al shell para su ejecución mediante la -copción del shell. Si no se especifica ningún comando, se ejecuta un shell interactivo. sudointenta cambiar al directorio de inicio de ese usuario antes de ejecutar el shell. El comando se ejecuta en un entorno similar al que recibiría un usuario al iniciar sesión. Tenga en cuenta que la mayoría de los shells se comportan de manera diferente cuando se especifica un comando en comparación con una sesión interactiva; consulte el manual del caparazón para obtener más detalles. La sección Entorno de comando del sudoers(5)manual documenta cómo la -iopción afecta el entorno en el que se ejecuta un comando cuando se utiliza la política sudoers.

Respuesta4

Tengo un problema similar.
Resuelvo esto usando cron. Pero cron debe ejecutarse con un usuario específico (por ejemplo, jenkins)

Simplemente haz el trabajo cron:

$ crontab -u jenkins -e

luego llene cron con su necesidad.

*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log

información relacionada