Configuration of SSH access for use by remote shell scripts and remote tools for maintenance, remote backup, and archival systems has great usefulness, but it has always been at the very least a subject of high controversy when it comes to server security. Many shell scripts that a user might want to run, such as:
$ ssh email@example.com /usr/local/bin/dangerous_script.pl
cannot handle a required SSH passphrase prompting him or her to authenticate but in fact will break unless a password-less private-public SSH key pair, an
ssh-agentconfiguration, or possibly a trusted host network mechanism—something that does not prompt for an SSH password—has been configured ahead of time. This is because SSH expects the passphrase from the current terminal associated with that shell session. A user can get around this issue by using an expect script or possibly a Perl (see
CPAN Module Net::SSH::Perl) script (or your shell script could alternatively call one of the aforementioned types of scripts):
#!/usr/local/bin/expect spawn sftp $argv expect "password:" send "mysshpassowrd\r"
Granting a password-less SSH mechanism for remote host access to typical users is justification enough for a lynching in the eyes of some systems administrators. However, alternative security measures to justify the password-less SSH mechanism for remote host access, such as a user on the remote host machine only given a restricted korn shell (rksh) account or restricted shell (rssh) instead of a full bash or Bourne shell account. It is also possible on an authorized key to restrict a user to a subset of commands in a list so that in effect, the user can only use the exact commands required to run remotely without the possibility for further access or an accidental command run that could damage the system. The SSH restriction example provided in Listing 5 provides such a restriction type.