rsync asking for password - not suitable for crontab invocation

[ivanachukapawn]

This is the code: [CODE][/usr/bin/rsync -azv --rsh='/usr/bin/ssh -p1022' --delete $REMOTE_IP:$REMOTEHOMEDIR/ $LOCALHOMEDIR 2>&1 >> $LOGFILE
/CODE]

In the past I have executed the script with this rsync invocation from cron with no problem. But I recently upgraded my Linux OS (to 2.6.16.60-0.76.8-smp) and now rsync is asking for a password. I am logged in as root. How should I code in order for this rsync to proceed without asking for a password? (Note: the remote host root password is the same as the local host root password).

[nplusplus]

You might consider sshkey authentication.

N

[ramin.honary]

If you want to access a remote system without using a password, the remote system needs to "trust" your computer. To make it trust you, you need to copy your SSH public key to the remote host. If you don't have a key, you can generate one with ssh-keygen. You can follow the steps in this brief tutorial. Save your public key on the remote system. As long as the remote SSH client can use the public key from the remote system, it will not ask for a password.

[IJskes]

If you can install rsyncd (the daemon) on one end, you can configure the rsyncd to do what you want. You can create users with restricted rights to directories. And have rsync access that user from the command line.

I am unsure if rsync does any encryption though.

[atreyu]

Just a note on your actual code, you should swap the places of your redirection commands and your log, e.g.:

/usr/bin/rsync -azv --rsh='/usr/bin/ssh -p1022' --delete $REMOTE_IP:$REMOTEHOMEDIR/ $LOCALHOMEDIR >> $LOGFILE 2>&1

[ivanachukapawn]

Dear NeverEnding,

The way I have it coded seems to produce the required LOGFILE. What is the rationale/documentation for your suggested change?

[atreyu]

The way you have it, anything sent to STDERR will not wind up in the log file (maybe you don't care though).

e.g.:

[user@host]# cat test.sh
#!/bin/sh
echo blah
ls boogers
[user@host]# sh test.sh 2>&1 > LOG
ls: boogers: No such file or directory
[user@host]# cat LOG
blah

now the other way:

[user@host]# cat test.sh
#!/bin/sh
echo blah
ls boogers
[user@host]# sh test.sh > LOG 2>&1
[user@host]# cat LOG
blah
ls: boogers: No such file or directory

See here for a proper explanation...

[ivanachukapawn]

thats great! Thanks very much for the help.

[ivanachukapawn]

ramin.honary,

The trust relationship had been established and ssh had been working fine without a password. The user is root and the .ssh directory is in /root/

The contents of this directory on the remote host are:

remotehost:~/.ssh # pwd
/root/.ssh
remotehost:~/.ssh # ls -la
total 32
drwx------ 2 root root 4096 2011-09-14 07:42 .
drwx------ 7 root root 4096 2011-09-26 07:32 ..
-rw------- 1 root root 4820 2011-09-14 07:42 authorized_keys2
-rw------- 1 root root 184 2011-03-10 13:48 config
-rw-r--r-- 1 root root 3592 2011-09-14 07:55 known_hosts
-rw------- 1 root root 672 2011-03-10 13:45 connectinghost.id_dsa
-rw-r--r-- 1 root root 603 2011-03-10 13:45 connectinghost.id_dsa.pub
remotehost:~/.ssh #

This all worked fine. Then on the remote host I upgraded the Linux OS. Now the rsync (which uses the ssh shell) asks for a password.

[atreyu]

The trust relationship was broken when you upgraded the remote host. Had you backed up the SSH keys and put them back into place on the new system, then you would be good to go (apart from a different system RSA fingerprint conflict -but that's another problem).

On your remote host/upgraded PC, you need to generate keys, e.g.:

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa

then copy them to your original pc. There's a script included with the OpenSSH package to assist with this, e.g.:

ssh-copy-id -i ~/.ssh/id_dsa root@<ORIGINAL_PC_IPADDR>

now the contents of the upgraded PC's pubkey should be in ~/.ssh/authorized_keys2 file on the original PC.

Test that keys are working by going to the remote/upgraded Linux PC and doing:

ssh root@<ORIGINAL_PC_IPADDR> hostname

does that work?