Saturday, February 6, 2010

Using passphrase-protected SSH keys in Cron

Just a few days ago I told you all about the glory that is SSH, and now I want to show you how to automate its use.

I'm sure you noticed while you were setting up your key that it asked you for a passphrase to protect the key.  If you opt not to set a passphrase, it will store your key in plain text, which means that if anyone gets access to your filesystem, they have access to your key.  They can copy it and use it on any computer to log into your server as you, so you are much better off protecting your key with a passphrase.  The key generator will use the passphrase to encrypt your key and give you protection from this threat.

Because the SSH key is encrypted, whenever you want to use it, it will ask you for your passphrase so that it can get access to the key.  This is exactly what you want to keep your key secure, but if you want to automate any of your SSH related tasks in Cron, you will be prompted for the passphrase every time SSH tries to establish a connection with your server.  One quick, easy way out of this situation is to simply keep your SSH key unencrypted and hope that no one who gets near your computer has malicious intentions, but there's a better way: ssh-agent.

Ssh-agent is a process that stores SSH keys in memory.  When you set up your SSH key with a passphrase, you may notice that Gnome gives you the option to "unlock this key automatically when I log in" (Ubuntu offers this option, YMMV); if you select that option, it will use Ssh-agent to store your SSH key in memory.

So at this point you have your SSH key encrypted on disk but unlocked in memory, so you can manually SSH into your server without entering the password for you account on the server or your passphrase for the SSH key, but you want Cron to have the same ability.  At this point, any SSH jobs in Cron will prompt you for your passphrase to unlock the SSH key.  I will show you how to fix that by making your unlocked SSH key (which is stored in memory by ssh-agent) accessible to Cron.

There are 2 steps involved in making your key available to your script running in the Cron environment: Saving the 2 SSH environment variables to disk and reading them into your environment within your Cron job.

Saving the SSH environment variables

Go into your crontab file by entering "crontab -e" at the command line.  Add the following on its own line:

     @reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

The @reboot is a special token in cron that will cause the command to be run when you first log in.  The command will cause the SSH_AUTH_SOCK and SSH_AGENT_PID to be written to a file on disk.

Retrieving the SSH environment variables within a Cron job

Basically, in order to make the running instance of ssh-agent available to your cron job, the following line needs to be run:
      
     . ~/.ssh-agent

On my machine, I put it right into crontab just before the job I wanted to run, like this:

     # m h  dom mon dow   command
     30 * * * * . ~/.ssh-agent; unison default -ui text -batch

If you are running a script, you can alternatively put the command at the top of the script.

And that's all there is to it!  You should now be able to run an SSH command using an SSH key that is encrypted on disk but unencrypted in memory within a cron job. 

EDIT:  A few days after posting this, I discovered that it was actually not working for me at all.  The steps I just described probably would have worked just fine if I was trying to start my own ssh-agent process and manually add keys to it using ssh-add, but I was trying to do it using the ssh-agent process and key which seahorse sets up for me when I first log in, and this configuration required a slightly different solution.  See my follow-up post for details.
 

See also:  http://sial.org/howto/openssh/publickey-auth/

3 comments:

  1. maybe you should write that this doesn't work at the top... don't tell us after we read the whole article...

    ReplyDelete