Si proporciona un comando remoto para ejecutar, SSH no asigna un tty, por lo que el comando remoto no puede deshabilitar el eco. Puede obligar a SSH a proporcionar un tty usando el -t opción:
ssh -t [email protected] 'mysql -u user -p'
La opción equivalente (para -o o para el archivo de configuración) es RequestTTY . Le advierto que no lo use en la configuración porque puede tener efectos no deseados para los comandos no interactivos.
Almacenamiento de 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 las Pautas para usuarios finales para la seguridad de contraseñas. capítulo del manual, sin necesidad de comunicarse a través de ssh o para escribir cada vez.
Específicamente, puede agregar una línea en la sección [cliente] del archivo .my.cnf en su directorio de inicio:
[client]
password=your_pass
Por supuesto, debe evitar que ese archivo sea accesible para cualquiera que no sea usted mismo, configurando el modo de acceso al archivo en 400 o 600 con, por ejemplo,
chmod 600 ~/.my.cnf
Entonces puedes usar algo como
ssh [email protected] 'mysql -u user110971 --defaults-file=/home/user110971/mysql-opts'
donde user110971 es el nombre de usuario de su cuenta.
Obligar al ssh a asignar un pseudo tty (ssh -t )
Este problema ocurre cada vez que envía un comando a través de ssh y necesita insertar la entrada porque, de forma predeterminada, ssh no asignará un pseudo-tty.
Puede forzar la asignación de tty con la opción -t , (incluso más de uno 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, p. al implementar servicios de menú. Múltiples -t las opciones fuerzan la asignación de tty, incluso si ssh no tiene tty local.
Como puede leer en esta publicación de Debian (11 de julio de 2008) sobre sudo , es un tema viejo que le encanta repetir:
ssh [email protected] "sudo ls" password: passwordY se te muestra la contraseña
La solución es obligar a ssh a asignar un pseudo-tty, con el indicador -t:
ssh -t [email protected] sudo ls
Nota:
Si es posible reiniciar la computadora remota cambiando el sistema operativo o quitar el disco duro, la computadora no puede considerarse completamente segura... pero en ese caso la base de datos en sí no será segura.
La opción de montaje "hidepid" para proc fs 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