Why is this rsync + ssh cron job giving me 'Permission denied (publickey)' errors?

Since everything is working fine from the command line, the error Permission denied (publickey) means that the SSH part of rsync is using a different identity file than the specified username.

From Jan's comment on the original question, we can specify the identity file in the rsync command using -e 'ssh -i /path/to/identity.file' ....

Using the below command to start off with a fresh environment in cron and specifying the complete path to the file apparently solves the issue:

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

_{I'm still really interested in this finding. It probably has to do with cron, the fact that it starts with minimal environment variables, and the ssh-agent. I'll be setting up the same scenario ina a couple of days to test it out and report back.}

I just have solved this problem that has kept me busy ..

Unable to connect in RSYNC over SSH, despite having stipulated the identity for SSH ...Nothing is done ... Rsync says "permission denied" and ssh tells me "read_passphrase: can not open /dev/tty: No device or address of this type"

But I read a post that explained that the crontab has its own environment that is not the same as root. I already knew that but I did not understand the impact it could have on SSH when using the SSH-AGENT

But my SSH key exchanges are done with PassPhrase ... so if the environment is different and my RSYNC over SSH expects a passphrase that can not be entered => SSH debug info also indicate the error:

"debug1: read_passphrase: can not open /dev/tty: No such device or address" => Well yes no TTY = no passphrase = not allowed

On my machine I use "Keychain" to have the SSH agent launched so I do not have to reenter the passphrase every time I try a remote connection. Keychain generates a file that contains the following information

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; export SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; export SSH_AGENT_PID;

==> The SSH-AGENT command returns the same info.

So, in the end, it is these information related to the current session that allow future authentications of the current session, without the need to enter the passphrase because already done previously and memorized ...

==> The solution is there ... it is enough in the script launched by the crontab, and to "source" the file containing this information or to do it on the command line ds the crontab ...

example: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh [email protected] :. >> / var / log / check_connexion.log 2> & 1 or use the command "source /home/foo/keychain/foo.server.org-sh" in the script that starts a connection using SSH.

=> With this sourcing, no more worry. The information of SSH_AUTH_SOCK and SSH_AGENT_PID are loaded in the environment of the Crontab and are therefore known, the RSYNC over SSH works without any problem.

It has kept me busy but now, it works :)

Caveat for those who use SSH Agent Forwarding:

If you see this behaviour when debugging a script on a remote host, it's because even with the -e "ssh -i /path/to/key" flag, ssh will use your local (forwarded) key rather than the one on the server.

Concrete example: I have a script on the dev server that pulls in data from the "data server" using rsync over ssh. When I log into the dev server and run it, all is well, but when running from cron, I get the permission denied. Adding some verbosity to the SSH process (flag -vv) I noticed the following:

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

What clued me off here is that by pure chance, I happen to have a different username on the local host ("nighty") than on the dev server ("juanr").

Notice how it marks the key on the dev server as "explicit", but still uses the forwarded key from my laptop to log in. Doing an ssh-copy-id at this point resolves nothing, because it simply reinstalls the forwarded key rather than the one from the dev server. If you use ssh-copy-id with agent forwarding, you need to specify which key to install with the -i flag: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

A little late to the party, but I had the same issue. Local user crontab -l showed my daily backup task:

  0   5   *    *    5    /repos/local-bin/backup-backups daily-6

Worked when I called /repos/local-bin/backup-backups daily-6 directly. Worked when I called the underlying rsync command by itself. Worked when I ssh-ed into the systems I was attempting to back up. ssh-add -l showed my environment's agent/keychain had the keys I needed stored properly and readily available.

So, following the advice of the main answer, I added env to /repos/local-bin/backup-backups, made the cron task run immediately, copied the output from env, added export before each of the lines, opened up a new terminal, ran env -i sh, and pasted the export commands into it. Then I ran my ssh command from earlier and it failed. Finally! I noticed that the cron environment was receiving a pid for an ssh agent, though, so it should be working...

I ran ssh-add -l, saw that the latest SSH keys I created weren't added to this environment's agent/keychain... but some of my other keys were?? Which is weird, because it was working with the agent I was using outside of this environment... oh wait! I'm using KDE's wallet/agent outside of this (my desktop) environment, and using ssh-agent directly inside of this environment (my terminal environment)! So I pressed Ctrl+Alt+F2 to drop out of KDE, ran ssh-add -l, saw that it, too, was missing the keys I needed, and ran my add-ssh-keys script. Normally this is done automatically around boot/login time, but these were newly minted SSH keys that needed to be added to both my KDE keychain (which I had done properly) and my non-KDE ssh-agent (which I forgot to do). Hopefully this helps someone else avoid a few hours of hair pulling :)

Have you already tried the old trick of cleaning up the hosts files? I mean:

rm ~/.ssh/known_hosts

It's worth trying as ssh will rebuild it and you will get rid of stale stuff. You can of course also remove the parts belonging to a given IP / Host.

More questions: Is your cron job running under your UID or is it running as user cron or root?

Use the rrsync script together with a dedicated ssh key as follows:

REMOTE server

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

LOCAL computer

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub [email protected]:/home/devel/.ssh

REMOTE computer

cat id_remote_backup.pub >> authorized_keys

Prepend to the newly added line the following

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

So that the result looks like

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

LOCAL

Put in your crontab the following script with x permission:

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP [email protected]:/ /home/user/servidor 

Source: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

To try and debug add to the ssh part "ssh -v" this way you can get verbose mode with some helpful information.

Edit: From the man page:

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

I think you haven't configured the sshd_config file properly. Verify that PermitRootLogin yes and PubkeyAuthentication yes for remote maintenance.