forma adecuada de sudo sobre ssh


150

Tengo un script que ejecuta otro script a través de SSH en un servidor remoto usando sudo. Sin embargo, cuando escribo la contraseña, aparece en el terminal. (De lo contrario, funciona bien)

ssh user@server "sudo script"

¿Cuál es la forma correcta de hacer esto para que pueda escribir la contraseña de sudo sobre SSH sin que aparezca la contraseña mientras escribo?


2
En cuanto a mí, la razón para buscar una manera de sudoing través de ssh era que no estaba funcionando cuando se trata de algo así ssh <user@server> sudo <script>, ya que llegaba el errorsudo: no tty present and no askpass program specified
knocte

Respuestas:


244

Otra forma es usar el -tinterruptor para ssh:

ssh -t user@server "sudo script"

Ver man ssh:

 -t      Force pseudo-tty allocation.  This can be used to execute arbi-
         trary screen-based programs on a remote machine, which can be
         very useful, e.g., when implementing menu services.  Multiple -t
         options force tty allocation, even if ssh has no local tty.

2
Bien, conocía la opción -t, pero no sabía que funcionaba para las indicaciones de sudo.

3
¿Para qué es la opción -t?
Vince


3
Aquí no funciona: ssh -t localhost <<< "sudo touch file;"EDITAR Aparentemente es importante que proporcione el comando como un parámetro, no a través del estándar en (lo cual tiene sentido en retrospectiva).
Expiación limitada del

el -tmétodo también mostrará resultados coloreados de comandos que normalmente lo hacen.
karmakaze

24

Pude automatizarlo completamente con el siguiente comando:

echo pass | ssh -tt user@server "sudo script"

Ventajas:

  • sin solicitud de contraseña
  • no mostrará la contraseña en el historial de bash de la máquina remota

Con respecto a la seguridad: como dijo Kurt , ejecutar este comando mostrará su contraseña en su historial local de bash, y es mejor guardar la contraseña en un archivo diferente o guardar el comando all en un archivo .sh y ejecutarlo. NOTA: El archivo debe tener los permisos correctos para que solo los usuarios permitidos puedan acceder a él.


8
Aparecerá en el historial de bash del sistema local, incluida la contraseña. Es mejor almacenar la contraseña en un archivo y capturar el archivo.
Kurt Fitzner

44
Hombre, lo sabía -t, ¡pero no había leído el manual lo suficiente como para ver que podía pasarlo dos veces! ¡Esto es lo que he estado buscando durante meses! Como una adición de seguridad, simplemente configuré una variable de contraseña antes de ejecutar read -s -p "Password: " pw, y luego lo hice echo "$pw" | ..... Ahora he convertido esto en un útil script para mí :).
kael

¡Funcionó como un encanto para mí!
MiKr13

¿Por qué no configuras sudo sin contraseña para los usuarios y comandos específicos que necesitas ejecutar? Este no es un problema de SSH ...
nomen

@nomen su solución también es válida, pero requiere pasos adicionales. Si tengo muchos dispositivos sin un usuario de sudo sin contraseña, puedo crear un script de automatización con esta solución. A veces trabaja en un sistema que no es de su propiedad y no desea o no puede hacer cambios, a veces hay otras consideraciones.
Ofirule

6

Suponiendo que no desea solicitar una contraseña :

ssh $HOST 'echo $PASSWORD | sudo -S $COMMMAND'

Ejemplo

ssh me@localhost 'echo secret | sudo -S echo hi' # outputs 'hi'

14
Esto es / muy / peligroso ya que la contraseña de texto sin formato termina en la línea de comando. Las líneas de comando son públicas y pueden ser vistas por cualquier otro usuario y proceso en el sistema. Por ejemplo, "ps auxwwwww" de un usuario sin privilegios mostrará todos los procesos en ejecución y las líneas de comando que los ejecutaron.
Kurt Fitzner

3
Sin mencionar poner su contraseña (en texto plano) en el archivo bash_history.
Layne Bernardo

4

Sudo sobre SSH pasando una contraseña, no se requiere tty:

Puede usar sudo sobre ssh sin forzar a ssh a tener un pseudo-tty (sin el uso del interruptor ssh "-t") diciéndole a sudo que no requiera una contraseña interactiva y simplemente tome la contraseña del stdin. Para ello, utilice el interruptor "-S" en sudo. Esto hace que sudo escuche la contraseña en stdin y deje de escuchar cuando vea una nueva línea.

Ejemplo 1 - Comando remoto simple

En este ejemplo, enviamos un whoamicomando simple :

$ ssh user@server cat \| sudo --prompt="" -S -- whoami << EOF
> <remote_sudo_password>
root

Le estamos diciendo a sudo que no emita un aviso y que tome su entrada de stdin. Esto hace que la contraseña de sudo pase completamente silenciosa, por lo que la única respuesta que obtiene es la salida de whoami.

Esta técnica tiene el beneficio de permitirle ejecutar programas a través de sudo sobre ssh que requieren la entrada de stdin. Esto se debe a que sudo está consumiendo la contraseña en la primera línea de stdin, y luego permite que cualquier programa que ejecute continúe agarrando stdin.

Ejemplo 2: comando remoto que requiere su propio stdin

En el siguiente ejemplo, el comando remoto "cat" se ejecuta a través de sudo, y estamos proporcionando algunas líneas adicionales a través de stdin para que se muestre el gato remoto.

$ ssh user@server cat \| sudo --prompt="" -S -- "cat" << EOF
> <remote_sudo_password>
> Extra line1
> Extra line2
> EOF
Extra line1
Extra line2

La salida demuestra que la <remote_sudo_password>línea está siendo consumida por sudo, y que el gato ejecutado remotamente muestra las líneas adicionales.

Un ejemplo de dónde esto sería beneficioso es si desea usar ssh para pasar una contraseña a un comando privilegiado sin usar la línea de comando. Diga, si desea montar un contenedor cifrado remoto a través de ssh.

Ejemplo 3 - Montaje de un contenedor remoto VeraCrypt

En este script de ejemplo, estamos montando de forma remota un contenedor VeraCrypt a través de sudo sin ningún texto adicional:

#!/bin/sh
ssh user@server cat \| sudo --prompt="" -S -- "veracrypt --non-interactive --stdin --keyfiles=/path/to/test.key /path/to/test.img /mnt/mountpoint" << EOF
SudoPassword
VeraCryptContainerPassword
EOF

Cabe señalar que en todos los ejemplos de línea de comandos anteriores (todo excepto el script), la << EOFconstrucción en la línea de comando hará que todo lo que se escriba, incluida la contraseña, se registre en la máquina local .bash_history. Por lo tanto, se recomienda encarecidamente que, para el uso en el mundo real, lo use completamente a través de un script, como el ejemplo de veracrypt anterior, o, si está en la línea de comando, coloque la contraseña en un archivo y redirija ese archivo a través de ssh.

Ejemplo 1a - Ejemplo 1 sin contraseña de línea de comandos local

El primer ejemplo se convertiría así:

$ cat text_file_with_sudo_password | ssh user@server cat \| sudo --prompt="" -S -- whoami
root

Ejemplo 2a - Ejemplo 2 sin contraseña de línea de comandos local

y el segundo ejemplo sería:

$ cat text_file_with_sudo_password - << EOF | ssh va1der.net cat \| sudo --prompt="" -S -- cat
> Extra line1
> Extra line2
> EOF
Extra line1
Extra line2

Poner la contraseña en un archivo separado es innecesario si está poniendo todo en un script, ya que el contenido de los scripts no termina en su historial. Sin embargo, aún puede ser útil, en caso de que desee permitir que los usuarios que no deberían ver la contraseña ejecuten el script.


En el comando remoto ssh, ¿por qué necesita ejecutar caty canalizar los resultados en sudo? ¿Puedes usarlo sudocomo el comando remoto principal ssh?
joanpau

@joanpau La inicial catse utiliza para canalizar la contraseña del usuario a sudo en el otro lado. Si el usuario puede ejecutar sudo sin una contraseña, entonces no es obligatorio, pero no sugiero esta configuración. La razón por la que se canaliza es para evitar que la contraseña aparezca en la línea de comando del sistema remoto. Las líneas de comando no son seguras, cualquier usuario puede ver cada línea de comando con ps auxwww.
Kurt Fitzner

Estoy pidiendo el caten el comando ssh cat \| sudo --prompt="" -S.... Si las -Sfuerzas sudopara leer la contraseña de stdin, ¿son necesarios el gato y la tubería? ¿Podría ser simplemente el comando ssh sudo --prompt="" -S...?
joanpau

@jonpau Ese comando cat toma stdin y lo pasa por sudo para pasarle la contraseña de sudo. Muestra cómo puede canalizar la contraseña de sudo a través de ssh a través de stdin de forma segura.
Kurt Fitzner

1

La mejor manera es ssh -t user@server "sudo <scriptname>", por ejemplo ssh -t user@server "sudo reboot". Solicitará primero la contraseña para el usuario y luego la raíz (ya que estamos ejecutando el script o comando con privilegio de root.

Espero que haya ayudado y aclarado tu duda.



0
echo $VAR_REMOTEROOTPASS | ssh -tt -i $PATH_TO_KEY/id_mykey $VAR_REMOTEUSER@$varRemoteHost 
echo \"$varCommand\" | sudo bash

2
... y proporcione una explicación para su código.
pppery

-1

Me enfrenté a un problema

user1@server1$ ssh -q user1@server2 sudo -u user2 rm -f /some/file/location.txt

Output:
sudo: no tty present and no askpass program specified

Entonces intenté con

#1
vim /etc/sudoers
Defaults:user1    !requiretty

no funcionó

#2
user1   ALL=(user2)         NOPASSWD: ALL

eso funcionó correctamente!


Esto realmente no logra lo que se le pide. La idea es aún requerir la contraseña, pero permitir que se escriba sobre ssh. Lo que has hecho es solo darle acceso completo a sudo usuario1 al usuario2 sin una contraseña. Esto está bien para aplicaciones específicas, pero no es la mejor idea como solución general.
Possum

-7

Dependiendo de su uso, tuve éxito con lo siguiente:

ssh root@server "script"

Esto solicitará la contraseña de root y luego ejecutará el comando correctamente.


26
Yikes, SSH como root? Esa es una mala idea por todo tipo de razones.
darkfeline

12
Recuerde que ssh no es telnet. No es más peligroso ssh como root de lo que sería ssh como otro usuario y ejecutar sudo. Su contraseña se cifra de la misma manera a través de la conexión ssh.
Stéphane

22
Stéphane es absolutamente correcto en lo que respecta a la seguridad de contraseña. Sin embargo, al usar root en lugar de sudo, pierde la pista de auditoría que acompaña a sudo. Además, el acceso raíz puede no estar disponible.
djeikyb
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.