[vox-tech] crontab and scp puzzle

Bruce Wolk bawolk at ucdavis.edu
Wed Mar 16 14:03:48 PDT 2011


-n is not a valid option and -q simply reduces the level of output.  The 
command still fails.

On 03/16/2011 01:14 PM, Michael Wenk wrote:
> Oops, I should have said -n not -N.
>
> Sorry.  Not sure its valid for scp tho.  Looks like -q is, but the
> programs are somewhat interwoven, so who knows.
>
> Mike
>
> On Wed, Mar 16, 2011 at 1:13 PM, Michael Wenk<mjwenk at ucdavis.edu>  wrote:
>> It is looking for an open tty and is failing because cron does not do that.
>>
>> I don't know much about scp and ttys, but I would try either -N or -q
>> and see if that works.  Otherwise see if there's an SSH/SCP option to
>> get it to not use a tty.
>>
>> Mike
>>
>> On Wed, Mar 16, 2011 at 9:43 AM, Bruce Wolk<bawolk at ucdavis.edu>  wrote:
>>> I need to copy a file from my server to a workstation on a regular
>>> basis.  I have set up passwordless ssh access to the server from my
>>> workstation.  When I execute the following on the workstation, the
>>> command succeeds and the file is copied:
>>>
>>> scp -P 33303 bruce at myserver.com:backup/db.sql.gz
>>> /home/bruce/backup/db.sql.gz
>>>
>>> But when I put the same command into a cron file on the workstation, the
>>> command fails.  The relevant output from the scp command is:
>>>
>>> debug1: Found key in /home/bruce/.ssh/known_hosts:5
>>> debug1: ssh_rsa_verify: signature correct
>>> debug1: SSH2_MSG_NEWKEYS sent
>>> debug1: expecting SSH2_MSG_NEWKEYS
>>> debug1: SSH2_MSG_NEWKEYS received
>>> debug1: Roaming not allowed by server
>>> debug1: SSH2_MSG_SERVICE_REQUEST sent
>>> debug1: SSH2_MSG_SERVICE_ACCEPT received
>>> debug1: Authentications that can continue: publickey
>>> debug1: Next authentication method: publickey
>>> debug1: Offering public key: /home/bruce/.ssh/id_rsa.pub
>>> debug1: Server accepts key: pkalg ssh-rsa blen 279
>>> debug1: PEM_read_PrivateKey failed
>>> debug1: read PEM private key done: type<unknown>
>>> debug1: read_passphrase: can't open /dev/tty: No such device or address
>>> debug1: No more authentication methods to try.
>>> Permission denied (publickey).
>>>
>>> I edited the cron file using crontab -e and have verified that it is
>>> excecuting properly as user bruce.
>>>
>>> I googled around but found nothing that helps.  Why would the
>>> authentication work with direct execution, but fail with cron execution?
>>>   Does anyone have any ideas?
>>>
>>> Bruce
>>> _______________________________________________
>>> vox-tech mailing list
>>> vox-tech at lists.lugod.org
>>> http://lists.lugod.org/mailman/listinfo/vox-tech
>>>
>>
>>
>>
>> --
>> Michael Wenk
>> mjwenk at ucdavis.edu
>>
>
>
>


More information about the vox-tech mailing list