Forzar rsync a modo no interactivo

8

Me gustaría usar rsync dentro de un script de Python. Lo llamo usando el subprocessmódulo y autenticando usando claves públicas almacenadas en el authorized_keyarchivo en la máquina remota.

El único problema es que cuando uso rsync con un nombre de usuario remoto incorrecto, se me solicita una contraseña, lo que obviamente detiene el script de copia de seguridad para siempre.

¿Puedo forzar la rsyncsalida con error si no se puede autenticar, en lugar de solicitar una contraseña?

Udi

shell rsync

— Adam Matan
fuente

9

Suponiendo que use rsync con un shell remoto SSH (y no, por ejemplo, con un servidor rsync), puede hacer que rsync ejecute SSH de una manera que nunca le pedirá una contraseña. Por ejemplo, una vez puede usar esta llamada:

rsync -e 'ssh -o "NumberOfPasswordPrompts 0"' source user@target:/path

Esto obligará a rsync a usar SSH con 0 posibles intentos de contraseña; si no puede obtener acceso usando algún otro método de autenticación (como clave pública o GSSAPI), fallará con un error. Tenga en cuenta que a rsync no le gustará cuando eso suceda y se quejará en voz alta a STDERR y romperá con el código de salida 255.

— Guss
fuente

5

Aquí están las opciones de línea de comando para ssh que uso para mantenerlo en silencio.

ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null -o batchmode=yes -o passwordauthentication=no

Solo necesita las cosas de la clave de host si no mantiene su archivo known_hosts y le preocupa recibir advertencias de MitM. En lugar de especificar los tipos de autenticación sugeridos por James F, tuve que restringir explícitamente la autenticación de contraseña. Sin embargo, lo uso para golpear a cientos de hosts con algunas versiones diferentes del sistema operativo, por lo que puede ser una incompatibilidad.

— Chad Huneycutt
fuente

1

NO use esta configuración. Consulte la sección 11.5 de "SSH, The Secure Shell: The Definitive Guide, Second Edition" de Oreilly. Según el libro: "Desafortunadamente, omitir efectivamente la autenticación del servidor deshabilita una parte vital de la seguridad SSH: ¡resistencia a la suplantación de host del servidor y ataques de intermediarios! Esta situación también hace que sea poco práctico reemplazar las claves del servidor periódicamente, como debería ser hecho, o para revocar una clave en caso de que se sepa que está comprometida (es decir, decirle a los clientes que ya no confíen en ella) ".

— Mick

1

@Mick: el problema con críticas como estas es que son completamente inapropiadas en algunos contextos. Por ejemplo, trabajo en un entorno donde el objetivo de las operaciones de rsync es generalmente una gran cantidad de sistemas integrados en una red privada enterrada en el interior de un laboratorio. No hay ninguna conectividad con el mundo exterior en absoluto, y el sistema de compilación debe poder enviar el código actualizado hacia los objetivos. Este es un uso completamente legítimo de ssh y rsync, y la solución obvia es desactivar la comprobación del host. Hacer una regla absoluta al respecto no tiene ningún sentido.

— Stabledog

@Stabledog: mi consejo es el correcto para la gran mayoría de los casos de uso. Sin embargo, reconozco que cuando no crees que un mal actor pueda obtener acceso razonable a tu red para realizar un ataque MiTM, puedes elegir una configuración de seguridad débil. La configuración de seguridad requerida para un entorno de laboratorio (como mencionó) obviamente diferirá de un entorno de producción porque el riesgo se reduce naturalmente.

— Mick

Lo suficientemente justo. Sin embargo, aquí está la preocupación filosófica, así como la práctica: ssh se valora por mucho más que su capacidad de ser seguro , y de hecho ... en la mayoría de los entornos que he visto usar, la seguridad es la preocupación menos importante . Es solo la navaja suiza elegida para conexiones remotas de todo tipo. Por lo tanto, existe esta desconexión entre los regaños de los "puristas de la seguridad" y la forma en que las personas reales lo usan todo el tiempo de manera práctica y diaria. No creo que todos seamos tontos casuales y los puristas tengan "razón". Es una cuestión de saber cuándo preocuparse.

— Stabledog

1

re: sugerencia de James (sin darle tty), para el subproceso, intente poner stdin = None como parámetro para Popen.

— Adam Brand
fuente

0

Primero haga que rsync funcione desde el shell, el comando debería verse así.

Si eso falla, depure el comando ssh por sí mismo. Cuando todo funcione, vea qué sucede con el script de Python

Este no es un mal tutorial

— James
fuente

0

Dependiendo de cómo esté iniciando rsync, podría no ser útil darle un TTY o PTY.

Muchos programas verifican si tienen un TTY de control antes de decidir solicitar al usuario que ingrese. El comportamiento predeterminado de system () y llamadas similares es proporcionar un tty a los subprogramas, pero puede deshabilitarlo.

También es posible deshabilitar la autenticación de contraseña por completo en el lado remoto si tiene el control de ambos sistemas y desea alejarse de la autenticación de contraseña para obtener los beneficios de seguridad mientras resuelve este problema.

Si está haciendo rsync a través de SSH, puede agregar lo siguiente a su archivo ssh_config para el host en cuestión, o mediante el interruptor de línea de comando -o:

PreferredAuthentications publickey

En una prueba rápida (de solo ssh, no rsync) que provocó que SSH saliera inmediatamente cuando mi clave pública no fue aceptada sin pedirme una contraseña.

— James F
fuente