rsync files as user using ssh key

Go To


I'm trying to rsync some files over to a backup host I have.
I'd like to be able to do this as a cron user (named cron_user in this example).
The destination host has a "from" line in the ~/.ssh/authorized_keys file with the ip address, and I've copied the private DSA key to a user protected directory (specified within the encapsulated ssh -i command).

I'm still getting prompted for a password. Is there another way around this, or is there something I'm missing that bypasses requiring a password and referencing the ssh key I've specified?

sudo rsync  --timeout=3600 -azO  -e 'ssh -i /var/cron_user/cron_user' /tmp/bacup1-$(date'+%Y-%m-%d' ).tgz /tmp/backup2$(date '+%Y-%m-%d' ).tgz cron_user@hbackup00:/database/backups/app_backup/

Upon further investigation, using a -v shows that it's not allowing the use of the key based on IP:

 IP: debug1: Remote: Your host '' is not permitted to use this key for login. 

Although I have the IP listed in the /home/user_cron/.ssh/authorized_keys file:

 [root@hbackup00 user]# cat ~cron_user/.ssh/authorized_keys 
 from=",,,,,,," ssh-dss

Is there something I'm missing to allow this user to authenticate without a password? I've tested using a ssh -i invoking the same keyfile from other hosts listed here, no issues...

2012-04-03 23:00
by user1172482
What happens if you just run ssh -i /var/cron_user/cron_user uptime from a command prompt? Does it work? Or not? If not, is there anything useful in the logs on the remote server - larsks 2012-04-04 00:39
I'd look at file perms first: SSH can be proscriptive about these. Second, I'd look at the selinux audit files, the key file may have an incorrect context and its correct context might not be available to ssh - MattH 2012-04-04 10:37
verified that selinux is fully disabled, per usual on our systems: [eshrago@hbackup00 selinux]$ pwd /etc/selinux [eshrago@hbackup00 selinux]$ grep disabled config

disabled - SELinux is fully disabled.

SELINUX=disabled [eshrago@hbackup00 selinux] - user1172482 2012-04-05 18:40


Here are some suggestions to help you debug:

  • Try the ssh directly, without rsync. This will help isolate the problem -- if it still fails, you have less to test, and if it works, then you know the ssh invocation that rsync is performing is different from the one you thought it was, and you can investigate that.

  • Turn up logging on the server. In /etc/ssh/sshd_config, set LogLevel VERBOSE or higher. (See the sshd_config man page.) Sometimes the server logs interesting information it doesn't share with the client.

  • Turn up logging higher in your client command line, with -vvv.

2012-04-05 23:22
by Greg Price


sshd was puppet controlled. d'oh!

2012-04-09 16:59
by user1172482