SSH hace visibles todas las contraseñas escritas cuando el comando se proporciona como argumento para el comando SSH

Si ejecuto esto:

ssh user@server 'mysql -u user -p'

Cuando me pide la contraseña de MySQL y empiezo a escribir, la contraseña está visible en la pantalla. ¿Cómo puedo prevenir esto? Si inicio sesión sshy luego ejecuto el comando MySQL, todo funciona bien.

— usuario110971
fuente

¿No crees que el título no está claro? Se podría decir que hace que todo el texto, incluidas las contraseñas, sean visibles. ¿Y cómo se supone que ssh sabe lo que está escribiendo es una contraseña frente a algún otro comando o dato?

— barlop

@barlop Estoy abierto a sugerencias.

— user110971

@barlop funciona bien cuando ejecutas el comando una vez que ssh al servidor. Estoy buscando alguna forma de hacer que el comportamiento ssh sea el mismo cuando los comandos se proporcionan como argumento.

— user110971

probablemente no sea tan necesario, pero ¿puede incluir un ejemplo completo de copia / pegado de la consola, por ejemplo, que muestre no solo el comando ssh sino la respuesta y el mensaje mysql que sigue? Puede cambiar la contraseña a suiza para no ponerla en el sitio. No puedo probarla en este momento

— Barlop

@barlop Son los mismos mensajes que esperaría, es decir, contraseña ssh seguida de indicaciones de contraseña de MySQL

— usuario110971,

Respuestas:

100

Si proporciona un comando remoto para ejecutar, SSH no asigna un tty, por lo que el comando remoto no puede deshabilitar echo. Puede forzar a SSH a proporcionar un tty usando la -topción:

ssh -t user@server 'mysql -u user -p'

La opción equivalente (para -oo para el archivo de configuración) es RequestTTY. Advierto contra usarlo en la configuración porque puede tener efectos no deseados para comandos no interactivos .

— Toby Speight
fuente

O puede editar ~ / .ssh / config para configurar ese host específico para que siempre solicite un TTY. Ver RequestTTYen man 5 ssh_config.

— un CVn

@ MichaelKjörling (y Toby): quizás agregue un poco de advertencia de que agregar "-t" debe reservarse solo para uso interactivo, ya que tiene efectos secundarios. Para una buena visión de algunos de esos efectos secundarios: unix.stackexchange.com/a/122624/27616 (de StephaneChazelas)

— Olivier Dulac

De acuerdo: iba a sugerir que es una pena que no pueda agregar configuraciones (como esta) de acuerdo con el comando remoto (en lugar de por Host).

— Toby Speight

Almacenar la contraseña en un archivo de opciones protegido

Si puede confiar en ^[*] la seguridad de la computadora remota, puede almacenar la contraseña en un archivo de opciones debidamente protegido, como se sugiere en el capítulo Pautas para el usuario final para la seguridad de la contraseña del manual, sin la necesidad de comunicarse ssho escribir hora.

Específicamente, puede agregar una línea en la sección [cliente] del archivo .my.cnfen su directorio de inicio:

[client]
password=your_pass

Por supuesto, tiene que evitar que ese archivo sea accesible para nadie más que para usted, configurando el modo de acceso a archivos a 400 o 600 con, por ejemplo,

chmod 600 ~/.my.cnf

Entonces puedes usar algo como

ssh user@server 'mysql -u user110971 --defaults-file=/home/user110971/mysql-opts'

¿Dónde user110971está el nombre de usuario de su cuenta?

Obligar a ssh a asignar un pseudo tty ( `ssh -t`)

Este problema ocurre cada vez que envía un comando sshy necesita insertar la entrada porque, por defecto, sshno asignará un pseudo-tty.

Puede forzar la asignación de tty con la opción -t(incluso más de una si es necesario):

-t

Forzar asignación de pseudo-tty. Esto se puede usar para ejecutar programas arbitrarios basados en pantalla en una máquina remota, lo que puede ser muy útil, por ejemplo, al implementar servicios de menú. Múltiples -topciones fuerzan la asignación de tty, incluso si ssh no tiene tty local.

Como puede leer en esta publicación de Debian (Jul_11_2008) sobre sudo, es un viejo problema que le encanta volver a aparecer:

ssh user@server "sudo ls"  
password: password  
Y se te muestra la contraseña
La solución es forzar a ssh a asignar un pseudo-tty, con el indicador -t:
ssh -t user@server sudo ls

Nota:

^[*] Si puedes confiar en dejar la contraseña en un archivo accesible solo para ti y rootear en elcliente en funcionamiento .
Si es posible reiniciar la computadora remota cambiando el sistema operativo o eliminar el HDD, la computadora no puede considerarse completamente segura ... pero en ese caso la base de datos en sí misma no será segura.

— Hastur
fuente

quizás agregue un poco de advertencia de que agregar "-t" debe reservarse solo para uso interactivo, ya que tiene efectos secundarios. Para una buena visión de algunos de esos efectos secundarios: unix.stackexchange.com/a/122624/27616 (de StephaneChazelas)

— Olivier Dulac

La opción de montaje "hidepid" para procesos también es valiosa. Hace que sus líneas de comando sean invisibles en la lista de procesos para otros usuarios. Ejemplo de fstab:

proc /proc proc hidepid=1 0 0

— bandolera
fuente

SSH hace visibles todas las contraseñas escritas cuando el comando se proporciona como argumento para el comando SSH

Almacenar la contraseña en un archivo de opciones protegido

Obligar a ssh a asignar un pseudo tty ( ssh -t)

-t

Nota:

Obligar a ssh a asignar un pseudo tty ( `ssh -t`)

`-t`