To rsync (incremental) from remote server (Centos 6.x) to local client (Ubuntu 18.04) I copied the public key I created from client to server to execute rsync without password.
PasswordAuthentication yes
at sshd_config
At local Ubuntu I have some executable scripts that look like
#!/bin/sh
RSYNC=/usr/local/bin/rsync-incr
SSH=/usr/bin/ssh\ -p\ xxxx
ROTATE=60
RUSER=yyyy
RHOST=zzzz
RPATH=/path-to-remote-dir/
LPATH=/path-to-local-dir/
$RSYNC -az --rsh="$SSH" $ROTATE $RUSER@$RHOST:$RPATH $LPATH
I run this script from command line /path-to-local-script-file
and it performs okay but if I add this line to crontab -e
00 00 * * * /path-to-local-script-file
I get a cron error "Permission denied, please try again" when it is executed
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
rsync: connection unexpectedly closed (0 bytes received so far)
[Receiver] rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2]
*** ERROR: rsync returned code 255
Obviusly it is a permission issue. What I don't get is why I am able to execute /path-to-local-script-file
from command line and perform rsync task successfully as user myname
and cannot form cron
(crontab -e executed as the same user.
Edit 1: I created a new key without passphrase, deleted the old rsa-ssh line with the public key from authorized_keys at remote server.
Same behavior, ok running script from command line, permission denied from cron
Edit 2:
Server log connecting ssh from command line
May 23 10:20:53 host sshd[21067]: Accepted publickey for root from xxx.xxx.6.13 port 42836 ssh2
May 23 10:20:53 host sshd[21067]: pam_unix(sshd:session): session opened for user root by (uid=0)
Server log connecting ssh from cron
May 23 10:17:03 host sshd[18163]: Failed password for root from xxx.xxx.6.13 port 42514 ssh2
May 23 10:17:03 host sshd[18163]: Failed password for root from xxx.xxx.6.13 port 42514 ssh2
May 23 10:17:03 host sshd[18164]: Connection closed by xxx.xxx.6.13
It appears that you are running the script manually as a non-root user and cron is running it as root.
If that is the case then you will need to define the path to the ssh private key.
If you are connecting as root to the remote server (bad) then you will need the root authorized_keys to have the public key of the workstation