Tengo este comando para hacer una copia de seguridad de una máquina remota. El problema es que necesito derechos de root para leer y copiar todos los archivos. No tengo un usuario root habilitado por razones de seguridad y uso sudo
el modo Ubuntu. ¿Necesitaría alguna tubería genial o algo para hacer esto?
rsync -chavzP --stats [email protected]:/ /media/backupdisk/myserverbackup/
root
cuenta en primer lugar.sudo
, especialmente combinado conNOPASSWD
lo recomendado en los comentarios, realmente no mejora la seguridad de su máquina.Respuestas:
En primer lugar, recomendaría que solo use la cuenta raíz. Si lo configura así:
sshd_config
en la máquina de destino paraPermitRootLogin without-password
.ssh-keygen
en la máquina que extrae la copia de seguridad para crear una clave privada SSH (solo si aún no tiene una clave SSH). No establezca una frase de contraseña. Google un tutorial si necesita detalles para esto, debería haber muchos./root/.ssh/id_rsa.pub
la máquina de respaldo a la/root/.ssh/authorized_keys
de su máquina de destino.entonces la configuración resultante debería ser bastante segura.
sudo
, especialmente combinado conNOPASSWD
lo recomendado en los comentarios, no tiene beneficios de seguridad con solo usar la cuenta raíz. Por ejemplo esta sugerencia:esencialmente da
rsyncuser
permisos de raíz de todos modos. Usted pregunta:Bueno, simple Con la configuración recomendada,
rsyncuser
ahora puede ejecutarsersync
como root sin siquiera solicitar una contraseña.rsync
es una herramienta muy poderosa para manipular archivos, por lo que ahorarsyncuser
tiene una herramienta muy poderosa para manipular archivos con permisos de root. Encontrar una manera de explotar esto me llevó solo unos minutos (probado en Ubuntu 13.04, requieredash
,bash
no funcionó):Como puede ver, me he creado un shell de raíz;
whoami
identifica mi cuenta como root, puedo crear archivos/etc
y puedo leer/etc/shadow
. Mi hazaña era establecer el bit setuid en eldash
binario; hace que Linux siempre ejecute ese binario con los permisos del propietario, en este caso root.No, trabajar torpemente alrededor de la cuenta raíz en situaciones en las que es absolutamente apropiado usarlo no es por buenas razones. Esta es solo otra forma de programación de culto de carga : realmente no entiendes el concepto detrás de sudo vs root, simplemente aplicas ciegamente la creencia "la raíz es mala, sudo es buena" porque lo has leído en alguna parte.
Por un lado, hay situaciones en las
sudo
que definitivamente es la herramienta adecuada para el trabajo. Por ejemplo, cuando trabajas de manera interactiva en un escritorio gráfico de Linux, digamos Ubuntu, entonces tener que usarsudo
está bien en esos raros casos en los que a veces necesitas acceso root. Ubuntu intencionalmente tiene una cuenta raíz deshabilitada y lo obliga a usarsudo
de forma predeterminada para evitar que los usuarios usen siempre la cuenta raíz para iniciar sesión. Cuando el usuario solo quiere usar, por ejemplo, el navegador web, iniciar sesión como root sería algo peligroso y, por lo tanto, no tener una cuenta raíz de forma predeterminada impide que las personas estúpidas hagan esto.Por otro lado, hay situaciones como la suya, en las que un script automatizado requiere permisos de root para algo, por ejemplo, para hacer una copia de seguridad. Ahora, usar
sudo
la cuenta raíz no solo no tiene sentido, también es peligroso: a primera vistarsyncuser
parece una cuenta ordinaria sin privilegios. Pero como ya he explicado, sería muy fácil para un atacante obtener acceso completo a la raíz si ya hubiera obtenidorsyncuser
acceso. Entonces, esencialmente, ahora tiene una cuenta raíz adicional que no se parece en absoluto a una cuenta raíz, lo que no es algo bueno.fuente
/root/.ssh/authorized_keys
, o incluso crear múltiples cuentas raíz con diferentes hogares para que cada usuario pueda tener su propio shell, hogar y.ssh/authorized_keys
:)sshd
generalmente no registra qué clave autorizada se utilizó para conectarse a una cuenta, por lo que si se conecta debob
esa manerasudo
, obtendrá una mejor pista de auditoría que si se conectaroot
directamente conbob
la clave.Utilice la
--rsync-path
opción para hacer que elrsync
comando remoto se ejecute consudo
privilegios. Su comando debería ser, por ejemplo:Si le
sudo
solicita una contraseña, debe evitarla mediante el uso de unNOPASSWD
privilegio con la cuenta de usuario remota (no tiene sentido para root, puede tener sentido en otros casos de uso), o si no desea hacerlo:Asegúrese de que la opción
tty_tickets
esté deshabilitada para el usuario que está utilizando, por ejemplo ejecutandosudo visudo -f /etc/sudoers.d/local-rsync
e ingresando:Asegúrese de que la opción
requiretty
esté deshabilitada para el usuario que está utilizando; podría estar desactivada de manera predeterminada. El método es el mismo que el anterior.Sembrar la
sudo
contraseña en la máquina remota, ejecutando p. Ej.ssh -t [email protected] sudo
fuente
sudo
contraseña, no lassh
contraseñasudo /usr/bin/rsync
sin pedir una frase de contraseña; verificaman sudoers
cómo hacer esto; es posible que desee crear un usuario de respaldo adicional para esto.sudo /usr/bin/rsync
ejecución sin requerir una contraseña, agregue lo siguiente a su/etc/sudoers
archivo:rsyncuser ALL= NOPASSWD:/usr/bin/rsync
Esto permitirá al usuario rsyncuser (como se mencionó anteriormente, sería mejor crear un usuario de respaldo dedicado) con el nombre de usuario que desee.rsync
esencialmente siempre tiene permisos de root; Probablemente sea muy fácil obtener un shell raíz completo en esa cuenta. Creo que es mejor usar la cuenta raíz real en primer lugar.echo "password" | something
que en realidad nunca usé esto y estoy de acuerdo con los problemas de seguridad que vienen al permitir que la ejecución sudoless de rsync (que tampoco se sugiere aquí) sea mala. Lo quetty_tickets
no tengo realmente idea, parece necesario y un problema de seguridad. Esto funcionaría de forma segura sin modificar nada simplemente ejecutando sodo en ssh y luego ejecutando el comando ¿verdad? Pero dado que hice esa pregunta con fines de secuencias de comandos, estoy totalmente de acuerdo en que ssh basado en claves sin pw es lo seguro y correcto. Acepté la respuesta de Martins en su lugar.Una manera simple de hacer esto es usar el
ssh-askpass
programa gráfico consudo
, esto evita el hecho de quesudo
no está conectado al terminal y le permite ingresar la contraseña de manera segura:Por supuesto, el
ssh-askpass
programa debe instalarse en la ubicación dada y debe ejecutar una sesión X en la máquina en la que está trabajando. Hay algunas variaciones en elssh-askpass
programa que también deberían funcionar (versiones de Gnome / KDE). También unsudo
programa de reemplazo gráfico comogksu
okdesudo
también debería funcionar.fuente
rsync --rsh='ssh -X' --rsync-path='gksudo -- rsync' user@host:/ .
no funcionarsync error: syntax or usage error (code 1) at main.c(1634) [server=3.1.1]
. Oh, ubuntu envía gnome-ssh-askpass, pero es/usr/bin/ssh-askpass
, en lugar de/usr/lib/ssh/x11...
. Así que funcionó :)ssh-askpass
. Solo tenía que buscar el significado de-chavzPe
, sería genial explicarlas como opciones largas.xeyes
usando SSH.Si su usuario ya tiene privilegios de sudo que están protegidos con una contraseña, los mantendré como están y solo agregaré una estrofa para usar rsync sin contraseña:
fuente
Me encontré con este problema hoy y lo resolví sin la necesidad de modificar los archivos de configuración o otorgar permisos de nivel raíz a las cuentas de usuario. Mi configuración particular fue que el usuario
A
en la máquinafoo
tenía que copiar todos los directorios de los usuarios de lafoo
máquinabar
en unbackup
directorio que ese usuarioA
poseía. (El usuarioA
tiene privilegios de sudofoo
).El comando que utilicé está debajo. Fue invocado por el usuario
A
en el/home
directorio enfoo
.Esto ejecuta rsync como sudo para que
foo
se pueda acceder a todos los directorios de usuarios pero le dice a rsync que use ssh para acceder a la máquinabar
usando lasA
credenciales del usuario . Mis necesidades eran ligeramente diferentes a las de la pregunta anterior, pero esto me permitió obtener rápidamente una copia de seguridad de todos los directorios de usuarios en una máquina en particular que administro sin interferir con la configuración del sistema.fuente
-i
opción dessh
. Puedes usarlo--rsync-path="sudo /usr/bin/rsync"
si tienes sudo en la máquinabar
. Esto luego leeroot@foo
y escribe comoroot@bar
, pero transfiere a través deA@foo
->B@bar
. ¡Gracias!Ejecutar rsync como daemon en la máquina de destino te permite hacer lo que quieras.
fuente
Mi solución es usar
--rsync-path="sudo rsync"
pero pide contraseña, solución alternativa:fuente
$( cat my_password.txt )
cual es un poco mejor, pero generalmente se prefiere configurar los permisos en cualquiera de los extremos, y / o usar claves SSH, de tal manera que no se requieran contraseñas en la CLI