SSH Case Studies: Batch Jobs, FTP and SSH
(Page 1 of 2 )
In this third part of a nineteen-part article series that delves deeply into SSH, we'll cover some general precautions you should take when doing batch jobs, and begin a discussion of FTP and SSH. This article is excerpted from chapter 11 of the book SSH, The Secure Shell: The Definitive Guide, Second Edition, written by Daniel J. Barrett, Richard E. Silverman and Robert G. Byrnes (O'Reilly; ISBN-10: 0596008953).
11.1.5 General Precautions for Batch Jobs
Regardless of the method you choose, some extra precautions will help secure your environment.
126.96.36.199 Least-privilege accounts
The account under which the automated job runs should have only those privileges needed to run the job, and no more. Donít run every batch job as root just because itís convenient. Arrange your filesystem and other protections so that the job can run as a less-privileged user. Remember that unattended remote jobs increase the risk of account compromise, so take the extra trouble to avoid the root account whenever possible.
188.8.131.52 Separate, locked-down automation accounts
Create accounts that are used solely for automation. Try not to run system batch jobs in a user account, since you might not be able to reduce its privileges to the small set necessary to support the job. In many cases, an automation account doesnít even need to admit interactive logins. If jobs running under its uid are created directly by the batch job manager (e.g., cron), the account doesnít need a password and should be locked.
184.108.40.206 Restricted-use keys
As much as possible, restrict the target account to perform only the work needed for the job. With public-key authentication, automated jobs should use keys that arenít shared by interactive logins. Imagine that someday you might need to eliminate the key for security reasons, and you donít want to affect other users or jobs by this change. For maximum control, use a separate key for each automated task. Additionally, place all possible restrictions on the key by setting options in the authorization file. [8.2] The command option restricts the key to running only the needed remote command, and thefromoption restricts usage to appropriate client hosts. Consider always adding the following options as well, if they donít interfere with the job:
These make it harder to misuse the key should it be stolen.
If youíre using hostbased authentication, these restrictions arenít available. In this case, itís best to use a special shell for the account, which limits the commands that may be executed. Since sshd uses the target accountís shell to run any commands on the userís behalf, this is an effective restriction. One standard tool is the Unix ďrestricted shell.Ē Confusingly, the restricted shell is usually named ďrsh,Ē but has nothing to do with the Berkeley r-command for opening a remote shell, rsh.
220.127.116.11 Useful ssh options
When running SSH commands in a batch job, itís a good idea to use these options:
ssh -q -o 'BatchMode yes'
The Ėq option is for quiet mode, preventing SSH from printing a variety of warnings. This is sometimes necessary if youíre using SSH as a pipe from one program to another. Otherwise, the SSH warnings may be interpreted as remote program output and confuse the local program. [7.4.17]
TheBatchModekeyword tells SSH not to prompt the user, who in this case doesnít exist. This makes error reporting more straightforward, eliminating some confusing SSH messages about failing to access a tty. [18.104.22.168]
Our recommended method for best security with unattended SSH operation is public-key authentication with keys stored in an agent. If that isnít feasible, hostbased or plaintext-key authentication may be used instead; your local security concerns and needs will determine which is preferable, using the foregoing discussion as a guideline.
To the extent possible, use separate accounts and keys for each job. By doing so, you limit the damage caused by compromising any one account, or stealing any one key. But of course, there is a complexity trade-off here; if you have 100 batch jobs, separate accounts or keys for each one may be too much to deal with. In that case, partition the jobs into categories according to the privileges they need, and use a separate account and/or key for each category of job.
You can ease the burden of multiple keys by applying a little automation to the business of loading them. The keys can all be stored under the same passphrase: a script prompts for the passphrase, then runs ssh-add multiple times to add the various keys. Or they have different passphrases, and the human inserts a diskette containing the passphrases when loading them. Perhaps the passphrase list itself is encrypted under a single password provided by the human. For that matter, the keys themselves can be kept on the key diskette and not stored on the filesystem at all: whatever fits your needs and paranoia level.blog comments powered by Disqus