If you provide a remote command to run, SSH doesn’t allocate a tty, so the remote command is unable to disable echo. You can force SSH to provide a tty using the
ssh -t [email protected] 'mysql -u user -p'
The equivalent option (for
-o or for config file) is
RequestTTY. I’d caution against using it in config because it can have unwanted effects for non-interactive commands.
Storing the password in a protected option file
If you can trust [*] the remote computer’s security, you can store the password in a properly protected option file, as suggested in the End-User Guidelines for Password Security chapter of the manual, without the need to communicate through
ssh or to type each time.
Specifically you can add a line in the [client] section of the file
.my.cnf in your home directory:
Of course you have to keep that file from being accessible to anyone but yourself, by setting the file access mode to 400 or 600 with, e.g.
chmod 600 ~/.my.cnf
Then you can use something like
ssh [email protected] 'mysql -u user110971 --defaults-file=/home/user110971/mysql-opts'
user110971 is the username of your account.
Forcing the ssh to allocate a pseudo tty (
This problem happens each time that you send a command through
ssh and you need to insert the input because, by default,
ssh will not allocate a pseudo-tty.
You can force the tty allocation with the option
-t, (even more than one if needed):
Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple
-toptions force tty allocation, even if ssh has no local tty.
As you can read in this Debian post (Jul_11_2008) about
sudo, it is an old issue that loves to recur:
ssh [email protected] "sudo ls" password: password
And password is shown you
The solution is to force ssh to allocate a pseudo-tty, with the -t flag:
ssh -t [email protected] sudo ls
[*] If you can rely on leaving the password in a file accessible only by you and root on the working client.
If it is possible to reboot the remote computer changing OS or to remove the HDD, the computer can’t be considered completely secure… but in that case the database itself will not be secure.
Mount option “hidepid” for proc fs is also valuable. It makes your commandlines invisible in process list for other users.
proc /proc proc hidepid=1 0 0