Find the answer to your Linux question:
Results 1 to 10 of 10
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    rsync asking for password - not suitable for crontab invocation

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

    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 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).

  2. #2
    Linux Newbie nplusplus's Avatar
    Join Date
    Apr 2010
    Charlotte, NC, USA
    You might consider sshkey authentication.


  3. #3
    Linux User
    Join Date
    Nov 2008
    Tokyo, Japan
    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.

  4. $spacer_open
  5. #4
    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.

  6. #5
    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

  7. #6
    Dear NeverEnding,

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

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

    [user@host]# cat
    echo blah
    ls boogers
    [user@host]# sh 2>&1 > LOG
    ls: boogers: No such file or directory
    [user@host]# cat LOG
    now the other way:
    [user@host]# cat
    echo blah
    ls boogers
    [user@host]# sh > LOG 2>&1
    [user@host]# cat LOG
    ls: boogers: No such file or directory
    See here for a proper explanation...

  9. #8
    thats great! Thanks very much for the help.

  10. #9

    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
    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
    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.

  11. #10
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts