Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm writing a bash script that will be called from cron to pull a file from a remote server once a day. I'm using SSH, so I need to supply a password automatically since this is running unattended. Here's what I've come up with so far:

1: create a DSA key pair via ssh-keygen
2: copy the public key to the remote server
3: configure ssh-agent to deal with the key passphrase

My question is: Is all this necessary? Is this the simplest/best approach? This is a really simple task, so I'd like to make the configuration as simple as possible while maintaining a reasonable level of security.

Additional info:
-not running the rsync daemon
-both machines are Ubuntu linux

share|improve this question
1  
Wait, hang on...you're not running sshd? How do you intend to use ssh for this then?` –  EEAA Nov 9 '10 at 14:18
    
Maybe I have some terminology confused. Yes, sshd must be running as I login with ssh. I thought (maybe mistakenly) that there was a 'deamon mode' to ssh separate from sshd (which can accept a --password-file), and that is what I'm not using. –  Hollister Nov 9 '10 at 14:53
    
Whoops, the daemon I'm not using is the rsync daemon. My apologies for the confusion. –  Hollister Nov 9 '10 at 15:00
add comment

4 Answers 4

up vote 7 down vote accepted

Anything you do will be insecure without the use of ssh and sshd.

The canonical way is to use scp or even better, rsync and an ssh key without a password.

Alternatively, create a key used only for copy, and on the remote end edit the authorized_keys file to contain only the command(s) you need to run, and the key, e.g.:

# remote_server:/home/copyuser/.ssh/authorized_keys:
command="[...]" ssh-rsa KEY_HERE user@host

There is also scponly available. If you create a user, set their shell in /etc/passwd to /usr/bin/scponly and they will not be allowed to login, but copy files in and out per the normal permissions.

share|improve this answer
    
Right, I do plan to use rsync over ssh. I just need to figure out the best way to handle the password/passphrase. –  Hollister Nov 9 '10 at 14:55
    
As mentioned above, a private key with no passphrase and restricted privileges on the remote end. –  Sam Halicke Nov 9 '10 at 15:04
    
+1 ssh command keys or scponly/rssh is the correct approach. –  janneb Nov 9 '10 at 15:23
    
+1 allowing only the commands you need can increase security (better isolation between client and server) –  Aleksandr Levchuk Nov 9 '10 at 15:28
    
Thanks for all the advice. I plan to go with passphraseless key, and a reduced privilege account. As far as the commands in the key, this account really needs to do nothing, as the rsync will pull the file. How do I specify "no commands" (or the minimum)? –  Hollister Nov 9 '10 at 15:45
add comment

While I suppose you could use a passphrase-protected private key, that's usually not recommended for processes that are intended to run via cron. I'd recommend skipping the passphrase and then making sure that whatever user account you're using only has very limited privileges on the target box. By skipping the passphrase, you won't need to deal with messing around with ssh-agent.

share|improve this answer
    
> "that's usually not recommended for processes that are intended to run via cron". Why is this not recommended? –  Hollister Nov 9 '10 at 14:56
    
Because you have to put in the passphrase every time the key is used. –  Sam Halicke Nov 9 '10 at 15:01
    
@serverninja: unless I also use ssh-agent, right? –  Hollister Nov 9 '10 at 15:07
    
@Hollister yes, you could, but you need to start ssh-agent using -a to provide a specific socket address (e.g. /tmp/auth_ssh.sock) and then set your cron job's environment to include SSH_AUTH_SOCK pointed there. –  Sam Halicke Nov 9 '10 at 15:27
add comment

Here are my recommendations:

  • Create a specific set of SSH public/private keys for this cron job. Use: ssh-keygen -t rsa -N '' -f id_cronjobname
  • Protect the resulting id_cronjobname file such that only the cron job can read it. If this file is compromised, anyone with that keyfile can potentially gain the same privileges.
  • Restrict the use of that key on the remote end. For example, in the remote authorized_keys, you may wish to prefix the key with the example below.
  • Consider also using "from" to limit the IP address in the authorized_keys file. See "man sshd" for more information on these restrictions.

Example line from remote authorized_keys file:

no-pty,no-agent-forwarding,no-X11-forwarding,no-port-forwarding,command="rsync --server --sender -vlogDtprze.i --ignore-errors --numeric-ids --inplace . /path/on/destination/system" ssh-rsa SSH_KEY_STRING user@host"

The exact command to put in there you can get by running the rsync command you plan to use, and then at the same time on the remote system do "ps awwlx | grep rsync".

NOTE: One common problem I run into is that the use running the cron job does not have the remote host's SSH key, so it is trying to ask if the connection is ok. Make sure you place the remote system's SSH host key in /etc/ssh/ssh_known_hosts (probably just copy it out of your own ~/.ssh/known_hosts file after you have connected). Alternately, you can do "su - $USER_CRONJOB_RUNS_AS" and then manually invoke the command and make sure it works. Additionally, this is good for testing the job.

share|improve this answer
    
Wow, thanks for the detailed answer. That looks like a very secure solution. +1 for the 'from' tip. Why use rsa and not dsa? –  Hollister Nov 14 '10 at 23:06
    
Just my preference, RSA is shorter. Use DSA if you prefer. –  Sean Reifschneider Nov 15 '10 at 13:20
add comment

In step #1 (generate keys) when you get asked for a paraphrase you should hit Enter right away - you'll have a paraphrase-less key pair, then you can skip step #3 (configure ssh-agent).

Security wise, in this setup, if your ssh client gets compromised then the ssh server (where you are pulling from) will also becomes open to the adversary (as non-root if you are not logging in as root). That's not a big problem and it's a pretty common way of doing things. But try to do security updates on your Ubuntu systems periodically.

Anything simpler then than this setup will be pretty low security.

The options described by serverninja will get you higher security (better isolation between client and the server) but those setups have a larger configuration overhead and harder to debug.

Once you setup the password-less key pair (copy pub key to ~/.ssh/autorized_keys on the server), rsync will without any extra options just like ssh and scp.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.