Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm using the following command in root's crontab on Debian.

rsync -vqrlHEAXogDtzhi --log-file=${LOG} --progress --rsync-path="sudo /usr/bin/rsync" --exclude-from=$CONFIG_DIR/excludes -e "ssh -i /home/backups/.ssh/id_rsa" backups@${HOSTNAME}:/ ${BACKUP_DIR}

And I'm getting the following:

sudo: no tty present and no askpass program specified

I have tried adding -t to the ssh command and I get:

Pseudo-terminal will not be allocated because stdin is not a terminal.

I have tried adding -t -t to the ssh command and I get:

protocol version mismatch -- is your shell clean?

I have added a .hushlogin to the backups user on the remote box and confirmed that I can ssh as backups using a key to the remote box with nothing displayed (login is hushed). I still get these messages.

Note that I can ssh as backups to the remote box using a key successfully.

Note that my sudo does not have the -tt option.

Note that the following is set in source and destination's /etc/sudoers file:

backups ALL= NOPASSWD:/usr/bin/rsync

Note that my /etc/sudoers file does not have any reference to:

Defaults    requiretty

Note that I won't echo my password in the command.

How can I skin this cat? :|

Thanks

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Sometimes you think too hard about things.

Rsync was not installed on the remote system.

/facepalm

share|improve this answer
    
Please mark your answer as accepted, So it cames on top of the answer list. –  Kwaio Aug 30 '13 at 12:13
    
had this just happen to me, like a fool. –  Parker Hutchinson Aug 26 at 6:21
  1. You don't need sudo if the cron job is excecuting as root.
  2. There's a whole slew of unnecessary flags: -rlptgoD; remove and replace with -a.
  3. The TTY message from sudo is for the local TTY whereas the -t option to ssh is for the remote TTY. Don't confuse the two.
  4. Don't -v and -q contradict each other?
  5. Your last worry should be whether the local SSH private key is encrypted or not. The former cannot be used with unattended runs (e.g., ones where stdin is not a TTY; they aren't run from a terminal or terminal emulator).

EDIT/UPDATE:

  • I take back 1 and 2.
  • 3 should be about there being no local TTY when cron is running, and SSH doesn't allocate one remotely since there isn't a local one.
share|improve this answer
    
This runs out of roots cronjob but ssh's as backups and over there uses sudo to become root again. –  Lynn Owens Aug 30 '13 at 2:32
    
Right. Misread. Edited. –  pilona Aug 30 '13 at 12:07

I'm going to guess that thus is an ssh key problem. Either backup's private key has a pass phrase or the public key isn't in the remote users keychain. Maybe your previous attempt used a key that was already loaded in your keychain?

share|improve this answer
    
There's no pass phrase and the pubic key is in the remoet user's keychain. –  Lynn Owens Aug 30 '13 at 2:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.