5

On my Linux machine (Alice), I am setting up a service account with an rsync cron job that will synchronise some files with a remote host (Bob). Obviously, I would want to make the rsync secure by using SSH with a keypair.

So my question is: is there any point in passphrase-protecting the private key?

If I passphrase-protect the private key, obviously I wouldn't put the passphrase in the cron job script. I would need to set up a persistent background ssh-agent process so that the cron job can use it. But then doesn't it somewhat defeat the purpose of the passphrase-protection? If someone can break into Alice, can't they just use the persistent ssh-agent to do all the bad things they need to?

The only (slight) advantage, I believe, is that even if the intruder can copy the private key, they would not be able to use it elsewhere because they don't know the password.

Kal
  • 247
  • 1
  • 6
  • Answer from dr jimbob is good -- adding a passphrase is simply an example of multi-factor authentication and only matters if someone gets the key. Everyone says "yes use a passphrase it's more secure" but it creates complexity. People (being people) look for shortcuts around complex things. Keep it simple and follow advice below. – Tom Harrison Jr Feb 21 '16 at 18:07

2 Answers2

12

In these sorts of scenarios, I leave the private key unencrypted (except maybe sitting on a disk that is encrypted), with read permissions restricted to root and the cronjob run as root, but do my best to restrict the usefulness of this key to the very specific task (versus allowing it to login to the remote machine with full access).

This can be done fairly straightforward by configuring ~/.ssh/authorized_keys to automatically run a specific command when logged in using the specific key. 

command="/usr/bin/remote_commands_to_run.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3Nz...DfE= root@some_client

See this answer for more. You should be careful that the commands in /usr/bin/remote_commands_to_run.sh do not allow an attacker to escape to a shell. It may also make sense to create a limited account on the remote machine with say a shell of /bin/false that runs the remote command (e.g., put the public key associated with the private key in that limited user's authorized_keys).

As always after setting it up, try and test to make sure the key doesn't have more privileges than you expect (e.g., that sftp doesn't work, that rsync doesn't work, etc).

On further notice, I see your particular task is to rsync data (presumably in specific directories). This is probably doable with limited accounts (e.g., chroot'd to only be able to see those specific directories with no access to a shell). I believe tools like rssh can be used to do this; consult superuser or serverfault for best advice.

Granted what I do in this scenario is mount the specific directories as a network drive (e.g., through NFS / sshfs) and then do the rsync to that mounted directory in a cron script.

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 1
    "with read permissions restricted to root and the cronjob run as root" You mean with read permissions restricted to *whichever user the cronjob is run as*? – Kal Jun 05 '14 at 04:39
  • 1
    @Kal - Sure. But I usually just run the cronjob as root. E.g., `sudo crontab -e` add a line where the command is `34 1 * * * /usr/bin/ssh -i /root/remote_host_cron_job_id_rsa user@remote_host` and have the private key pair only root readable. This of course assumes I have root access. Yes this opens up an attack surface (if an attacker could replace the binary `/usr/bin/ssh` with something malicious, you get to run a binary as root when the cronjob next executes). It's better to set up another limited account client side that runs the cronjob and is the only user to read the key. – dr jimbob Jun 05 '14 at 17:29
1

I think password protection is wise. Better to have it than not. But, like you said, if Alice's machine is compromised, even with the private key it is no use without the password. However, if the machine is compromised, the attacker could simply wait for Alice to enter the password, and it would be easily captured using a keylogger.

Æther
  • 72
  • 5