SSH makes all typed passwords visible when command is provided as an argument to the SSH command

If I run this:

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

When it asks me for the MySQL password, and I start typing, the password is visible on screen. How can I prevent this? If I log in through ssh and then execute the MySQL command, everything works fine.

user110971

Posted 2016-10-25T09:48:39.523

Reputation: 579

5don't you think that title is rather unclear.. You could say it makes all text including passwords visible. And how is ssh meant to know what what you're typing is a password vs some other command or data? – barlop – 2016-10-25T09:51:35.963

@barlop I'm open to suggestions. – user110971 – 2016-10-25T09:52:49.957

@barlop well it works when you execute the command once you ssh to the server. I'm looking for some way to make the ssh behavior the same when the commands are provided as an argument. – user110971 – 2016-10-25T10:18:27.577

it's probably not that necessary, but can you include a full copy/pasted example from the console e.g. showing not just the ssh command but the response, and the mysql prompt that follows. You can change the password to swisscheese so as not to put it on the site I can't test it at the moment – barlop – 2016-10-25T10:45:50.810

@barlop It's just the same messages you would expect i.e. ssh password followed by MySQL password prompts – user110971 – 2016-10-25T11:07:48.587

Would it be possible to use key-pair authentication? This way, no password is used. – Stavr00 – 2016-10-26T20:18:19.603

@Stavr00 for MySQL? You'd need to use a key for everything that needs a password. The -t switch actually fixes the problem. – user110971 – 2016-10-26T20:21:09.383

@user110971 http://dev.mysql.com/doc/refman/5.7/en/secure-connections.html

– Stavr00 – 2016-10-28T15:16:21.517

Answers

101

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 -t option:

ssh -t user@server '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.

Toby Speight

Posted 2016-10-25T09:48:39.523

Reputation: 4 090

15Or you can edit ~/.ssh/config to configure that specific host to always request a TTY. See RequestTTY in man 5 ssh_config. – a CVn – 2016-10-25T15:12:25.767

@MichaelKjörling (and Toby) : maybe add a bit of warning that adding "-t" should be reserved to interactive usage only, as it has side effects. For a good view on some of those side effects : http://unix.stackexchange.com/a/122624/27616 (from StephaneChazelas)

– Olivier Dulac – 2016-10-27T10:43:37.320

Agreed - I was going to suggest that it's a shame you can't add settings (such as this) according to the remote command (rather than by Host). – Toby Speight – 2016-10-31T08:40:56.363

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:

[client]
password=your_pass

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 user@server 'mysql -u user110971 --defaults-file=/home/user110971/mysql-opts'

where user110971 is the username of your account.

Forcing the ssh to allocate a pseudo tty (`ssh -t`)

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):

-t

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 -t options 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 user@server "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 user@server sudo ls

Note:

^[*] 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.

Hastur

Posted 2016-10-25T09:48:39.523

Reputation: 15 043

maybe add a bit of warning that adding "-t" should be reserved to interactive usage only, as it has side effects. For a good view on some of those side effects : http://unix.stackexchange.com/a/122624/27616 (from StephaneChazelas)

– Olivier Dulac – 2016-10-27T10:49:05.770

Mount option "hidepid" for proc fs is also valuable. It makes your commandlines invisible in process list for other users. fstab example:

proc /proc proc hidepid=1 0 0

bandie

Posted 2016-10-25T09:48:39.523

Reputation: 33