Estoy trabajando con dos instancias de ubuntu en AWS (que utilizo 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 - jenkins por ejemplo o incluso escribiendo sudo antes 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:
He intentado crear una clave ssh (usando ssh-keygen) mientras estaba conectado como jenkins y la agregué al authorized_keys archivo en /home/ubuntu/.ssh/authorized_keys (desde donde «estoy ejecutando rsync) e incluso en $JENKINS_HOME/.ssh/authorized_keys (donde intenté ejecutar rsync desde allí también).
Incluso intenté usar la tecla pem para hacer lo mismo y tampoco funcionó.
Esto es lo que «Estoy intentando ejecutar
rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins
Y h ere «s con el archivo de 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 ubuntu usuario es porque obtengo failed: Permission denied (13) en muchas cosas (ya que los archivos son propiedad de jenkins).
Objetivo final:
I «Estoy tratando de mantener la copia de seguridad de la instancia de jenkins constantemente respaldada con la instancia principal haciendo un cronjob:
*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins
Comentarios
- ¿Agregó la clave ssh en el archivo de claves autorizadas de hosts remotos o en el servidor donde está ejecutando el comando rsync?
- La pregunta no es ‘ t bastante claro. En cada ejecución de rsync tienes un origen y un destino. ¿Puede aclarar los sistemas de origen y destino? Para fines de resolución de problemas, recomiendo seguir con ssh sobre rsync, porque rsync usará ssh. Intente usar ssh -vvv jenkins @ < target > de la fuente y pegue la salida aquí.
- Me falló: Permiso denegado (13) en muchas cosas (ya que los archivos son propiedad de jenkins) Entonces, ¿por qué no realizar el rsync como » jenkins » usuario?
- Escribiste Yo ‘ he intentado crear una clave ssh (usando ssh-keygen) mientras iniciaste sesión como jenkins y lo agregué al archivo autorizado_keys en /home/ubuntu/.ssh/authorized_keys (donde ‘ estoy ejecutando rsync desde) , pero debe agregar la clave al archivo de claves_autorizadas en el sistema destino .
Respuesta
Sé que es una publicación antigua, pero por si acaso puede ayudar a otras personas …
Tienes que diferenciar 2 cosas:
- quién establece la conexión SSH .
- cuyo usuario remoto posee los archivos que desea copiar.
Descripción general
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser | | sudo su jenkins | v jenkins Digamos que desea sincronizar:
- De:
- Máquina:
srcmachine - Usuario:
srcuser - Directorio:
/var/lib/jenkins
- Máquina:
- Para:
- Máquina:
destmachine - Usuario:
destuserpara establecer la conexión SSH . - Directorio:
/tmp - Propietario de los archivos finales:
jenkins.
- Máquina:
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 decir para ejecutar rsync en la máquina remota con otro usuario (jenkins) que el 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 el destuser
El destuser debe tener el privilegio de hacer sudo -u jenkins rsync.
En general, configuramos destuser como miembro de sudoers. Para hacer esto, en root @ destmachine:
cat > /etc/sudoers.d/destuser << EOF destuser ALL=(ALL) NOPASSWD:ALL EOF Para probarlo antes del rsync, puede iniciar sesión en destuser @ destmachine y ejecutar esto:
sudo su jenkins echo $USER Si devuelve:
jenkins significa que ha iniciado sesión como jenkins usuario, y significa que su comando rsync también funcionará, porque el privilegio escalade para jenkins funciona.
Nota sobre una mala solución: establezca la conexión SSH con el usuario de destino jenkins
Por qué no » ¿No solo hacemos esto?
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> jenkins [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub] porque jenkins es una cuenta de «servicio», lo que significa que ejecuta un servicio que expone un puerto (80 más o menos) para el acceso HTTP externo, y significa que es POSIBLE que haya una brecha de seguridad a través del servicio Jenkins a través de HTTP para obtener acceso.
Es por eso que tenemos www-data usuario y similares para ejecutar los diferentes servicios. En caso de que sean pirateados desde los puertos que exponen, no pueden hacer mucho:
- todo es de solo lectura para ellos.
- excepto escribir en
/var/log/THE_SERVICE.
El acceso SSH para el usuario jenkins expone un ataque superficial (por lo que es para el acceso SSH como root !!).
Además, si desea sincronizar como otro usuario (root, www-data, etc.), tendrá que copiar su Clave SSH clave pública para esas cuentas (problemática).
Buena solución : debe configurar el menor número posible de acceso SSH a las cuentas de usuario (destuser) que PUEDE escalada a la cuenta de «servicio» que desea (jenkins, root, etc.).
Responder
Tuve un problema similar con rsyncing como otro usuario. Se solucionó 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 teclas para poder ejecutar rsync como otro usuario.
Responda
sudo -u jenkins -i rsync ... con sin comillas .
La opción -i hace que el comando sudo se ejecute con el entorno del usuario, incluidas las claves ssh, .profile, .bash_profile etc.
Del sudo hombre:
-i, --loginEjecute 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 los archivos de recursos específicos de inicio de sesión, como
.profile,.bash_profileo.loginser leído por el shell. Si se especifica un comando, se pasa al shell para su ejecución a través de la opción «s-cdel 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 shell para obtener más detalles. La sección del entorno de comandos en el manualsudoers(5)documenta cómo la opción-iafecta el entorno en el que se ejecuta un comando cuando la política de sudoers está en use.
Respuesta
Tengo un problema similar.
I resuelve esto usando cron. Pero cron debe ejecutarse con un usuario específico (por ejemplo: jenkins)
Simplemente haga el trabajo cron:
$ crontab -u jenkins -e luego complete cron con su necesidad.
*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log Comentarios
- Si el
rsynces falló debido a un problema de autenticación, ¿cómo ayudará su sugerencia?