Automating SSH with a shell script

For all that the SSH program suite is wonderful, one of its weaknesses is that it's not at all easy to specify a password to allow you to include it (or its file transfer cousin sftp) in a shell script.

When I worked with sftp for my book Wicked Cool Shell Scripts I actually ended up deciding that it was easier and more secure to actually prompt for the password rather than save it in a data file or similar.

However, there are a couple of ways that I think you could explore to make SSH completely script-friendly:

1. Config files

if you can add data files on both your system and the remote system you'll be connecting to, you can try adding data to the /etc/hosts.equiv or /etc/shosts.equiv files. As the man page says:

"First, if the machine the user logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote machine, and the user names are the same on both sides, the user is immediately permitted to log in. Second, if .rhosts or .shosts exists in the user's home directory on the remote machine and contains a line containing the name of the client machine and the name of the user on that machine, the user is permitted to log in. This form of authentication alone is normally not allowed by the server because it is not secure."

As they say, this isn't a particularly secure method at all, and has lots of holes that leave you open to exploitive hacks. Most smart admins will automatically axe any '.rhosts' or "hosts.equiv" files either in /etc (hugely dangerous) or in an individual user's home directory (still pretty dangerous).

Instead, there's a more complex solution that involves both using "rhosts" combined with RSA authentication. Again, quoting from the man page:

"The second authentication method is the rhosts or hosts.equiv method combined with RSA-based host authentication. It means that if the login would be permitted by $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or /etc/shosts.equiv, and if additionally the server can verify the client's host key (see /etc/ssh_known_hosts and $HOME/.ssh/known_hosts in the FILES section), only then is login permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing and routing spoofing. [Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.]"

Again, this is a bit more secure than the first method, but still not a great solution unless you have otherwise strong security on both systems and neither is exposed to the public internet.

2. SSH_ASKPASS

The other approach you could try taking with ssh within a script is to experiment with the environment variable SSH_ASKPASS . Here's what the man page explains:

"If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .Xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)"

Not very clearly explained, but enough that you could probably start poking around and find something or other to help you on your exploration.

3. sftp -b batch mode

The sftp program also has a "-b" flag for batch mode, with its man page including this intriguing comment: "Since it lacks user interaction it should be used in conjunction with non-interactive authentication." However, there's no further documentation on how to work with non-interactive authentication so I don't know how you'd learn more about it.

I realize this isn't the answer you were seeking, but I hope it's useful and informative nonetheless. If someone knows how to make ssh / sftp more script-friendly, please add it as a comment.