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 '10.5.122.118' 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="10.5.112.42,10.5.122.118,10.5.100.200,10.5.100.205,10.5.99.223,10.4.99.229,10.4.99.223,10.4.100.182" 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...
ssh -i /var/cron_user/cron_user uptimefrom 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
SELINUX=disabled [eshrago@hbackup00 selinux] - user1172482 2012-04-05 18:40
Here are some suggestions to help you debug:
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
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
sshd was puppet controlled. d'oh!