SSH via cron giving Permission denied, please try again, but it works from the command line!

18 Oct, 2011  |  Written by  |  under Uncategorized

I was recently stumped with an rsync using ssh command that has been running for a year from my cron suddenly stop working. Here was the error:

Permission denied, please try again.
Permission denied, please try again.
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(601) [Receiver=3.0.8]

The rsync runs an ssh with a set of keys that needs no password. So it should automatically login to the remote server and start the rsync. And that’s how it was working and working fine.

I’d ad changed my ssh config on both servers so I knew that had to be the issue, but what had me stumped is that it worked fine when I ran the rsync manually from the command line!

Turns out, thanks to reading a handy post by chmac on the Fedora Forum, that my ssh-agent for my interactive session was taking over and providing the keys the server needed. However, when run via cron, the agent wasn’t present, so gave a permission denied error.

It was easy to verify. As soon as I removed the ‘SSH_AUTH_SOCK’ variable from my shell, the rsync/ssh no longer worked without a password.

Which pointed me to the actual problem – in modifying my ssh config a few days earlier, I’d removed the public key from authorized_keys2 on the server, so my ssh was no longer able to automatically connect. Re-adding the public key fixed the problem!

No Responses so far | Have Your Say!

Leave a Feedback

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>