You can add keys to the agent (assuming C shell syntax here):$ ssh-agent | head -2 > ~/agent-info $ cat ~/agent-info setenv SSH_AUTH_SOCK /tmp/ssh-res/ssh-12327-agent; setenv SSH_AGENT_PID 12328;
then instrument any scripts to set the same values for the environment variables:$ source ~/agent-info $ ssh-add batch-key Need passphrase for batch-key (batch job SSH key). Enter passphrase: **************
You also need to ensure that the batch jobs (and nobody else!) can read and write the socket. If there's only one uid using the agent, the simplest thing to do is start the agent under that uid (e.g., as root, do su <batch_account> ssh-agent ...). If multiple uids are using the agent, you must adjust the permissions on the socket and its containing directory so that these uids can all access it, perhaps using group permissions.#!/bin/csh # Source the agent-info file to get access to our ssh-agent. set agent = ~/agent-info if (-r $agent) then source $agent else echo "Can't find or read agent file; exiting." exit 1 endif # Now use SSH for something... ssh -q -o 'BatchMode yes' user@remote-server my-job-command
TIP: Some operating systems behave oddly with respect to permissions on Unix-domain sockets. Some versions of Solaris, for example, completely ignore the modes on a socket, allowing any process at all full access to it. To protect a socket in such situations, set the containing directory to forbid access. For example, if the containing directory is mode 700, only the directory owner may access the socket. (This assumes there's no other shortcut to the socket located elsewhere, such as a hard link.)Using an agent for automation is more complicated and restrictive than using a plaintext key; however, it is more resistant to attack and doesn't leave the key on disk and tape where it can be stolen. Considering that the agent is still vulnerable to being misused via the filesystem, and that it is intended to run indefinitely, the advantages of this method are debatable. Still, we recommend the agent method as the most secure and flexible strategy for automated SSH usage in a security-conscious environment.
These make it harder to misuse the key should it be stolen. If you're using trusted-host 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.no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
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. [Section 7.4.15, "Logging and Debugging"] The BatchMode keyword 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. [Section 22.214.171.124, "Batch mode: suppressing prompts"]ssh -q -o 'BatchMode yes'
|10.8. Summary||11.2. FTP Forwarding|
Copyright © 2002 O'Reilly & Associates. All rights reserved.