If you are using ssh keys, you have installed ssh-agent, and you have added your keys automatically at login, any ssh connections to the servers that use the key now connect without intervention. This includes sftp and scp. Remember, ssh can be used to issue a single remote command just by appending the command on the ssh command-line. The remote command can include such things as wildcards and ~ operators so long as they are quoted:

$ pwd
/home/gboyd
$ ssh hills.ccsf.edu 'echo ~'
/users/gboyd

Using a here document you can even create and run a script on-the-fly on a remote system:

$ ssh hills.ccsf.edu 'bash << EOF
> echo hello there
> pwd
> id
> EOF
> '
hello there
/users/gboyd
uid=3496(gboyd) gid=208(cisdept) groups=217(labstaff)
$

This could allow you to do really nice things, such as back up your work on a remote system automatically when you log off. Just add an appropriate scp or rsync command to your ~/.bash_logout prior to killing your agent.

It is more difficult to automate tasks that occur without user input after you have logged off. Examples of this would be a cron job that executes at midnight every night to copy some files between systems. In order to do this, you must supply your key to the ssh command before it connects. There are two solutions. First, the simple solution, which involves a less-secure key:

• create an alternate key pair using ssh-keygen -t rsa -b 4096 -f pathtoaltprivatekey to create a new key pair and place the private key in pathtoaltprivatekey, which should be a path in the ~/.ssh directory (the public key will be named the same with the suffix .pub ).  Create the key with an empty passphrase (simply hit enter when prompted for the passphrase). Then copy the [public part of the] key to the server's authorized_keys file as well, and mark it as a restricted key that could only be used from your client (using the from=... prefix). Then, connect using ssh and give the option -i pathtoaltprivatekey.  The server will try each key that can be used with your client successively until one succeeds or they all fail. 

This alternate [passphrase-less] key pair can now be used by batch jobs (such as cron) to connect automatically. This, of course, leaves your account more vulnerable. Anyone gaining access to  your account now has access to any servers that use your alternate key without having the security feature of a passphrase. Of course, they must figure out they need to use the alternate key.

If your passphrase-less key is to be used for a single purpose (as is often the case), you can configure it on the client (in authorized_keys) so that it automatically runs a single command. This is an excellent protection mechanism.

The second method relies on using ssh-agent. 

• Start an extra session of ssh-agent, save its environment parameters (that it outputs to stdout) in a file you can source later, load the key(s) into your new agent, then source the file in your cron or batch job later. (By default, ssh-agent will continue after logout, so long as you logout cleanly rather than disconnecting.) This is a bit tricky, but not bad. 

(In this example we start a temporary shell to add the new key to the second agent. This avoids changing the key we are currently using. You don't have to use a here document - you could just start a shell, source the file, add the key and exit the shell.)

ssh-add (started by your temporary shell above) will ask you for your passphrase. It will then respond

Identity added: /home/gboyd/.ssh/id_rsa (/home/gboyd/.ssh/id_rsa)

Then, in your batch file simply add the line

. /tmp/agent.$LOGNAME

at the top. Any ssh commands run by your batch file will now use the agent.

There are two problems with using an agent for a batch job:

1. the agent will continue to run. This is not necessarily bad. You are the only user who can use the agent.
2. if the system is restarted and the batch job is run afterwards, the agent will not exist. This may be a significant issue. It would also be an issue if your system administrator kills processes that have been inherited by init, as does our administrator on hills.

If the batch job is a one-time event, it is highly recommended that your batch job kill the agent and remove the agent.$LOGNAME file when it is finished.