Cron Job From Local Machine


#1

I’ve been trying to set up a cron job from my local machine to upload an excel spreadsheet daily to a user account on our company web site. We set up XODA to have a document sharing utility and want to be able to upload our time logs daily. I tried copying my public key and appending it to the authorized_keys file within the .ssh directory to allow access without asking for a password. I’ve tried using:

to upload the file to a certain directory. This works just fine in the command line. I also wrote a simple shell script to do the same thing and when I run the shell script it works just fine. But, when I try to the script or line with cron, it fails. It attempts to ask for the password three times and then times out.

If anyone has any suggestions or fixes, help would be greatly appreciated. Thanks.


#2

The difference between running things on the command line and in cronjobs, is that cronjobs don’t load your normal shell environment, maybe you need something from that environment, though I can’t really think what would cause this particular problem.

You could try of course to load your .bashrc or .bash_profile or whatever your shell uses before running the cronjob, see if that makes a difference:

. ~/.bashrc; scp …etc…


#3

Try adding “-vv” to the “scp” command (before the filename) to have scp output verbose debugging information. If that doesn’t make the issue clear, post the logs here so we can see what’s going on.


#4

Here’s the debug information:

Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN’
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END’
debug1: identity file /Users/ME/.ssh/id_rsa type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 126/256
debug2: bits set: 506/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host ‘DOMAIN.com’ is known and matches the RSA host key.
debug1: Found key in /Users/josh/.ssh/known_hosts:3
debug2: bits set: 507/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/ME/.ssh/id_rsa (0x1001256f0)
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/ME/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
debug1: read_passphrase: can’t open /dev/tty: Device not configured
debug2: no passphrase given, try next key
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
debug1: read_passphrase: can’t open /dev/tty: Device not configured
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can’t open /dev/tty: Device not configured
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can’t open /dev/tty: Device not configured
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password).
lost connection

My cron job looks like this:

And my shell script looks liks this:

[code]#!/bin/bash

cd /Users/ME
scp -vvi /Users/ME/.ssh/id_rsa timelog.xls USER@DOMAIN.com:/home/USER/files
exit[/code]

SSH isn’t really my forte so I don’t know exactly what’s going on here. I tried using the -i parameter to force it to use my private key (without using id_rsa, it tried id_dsa and identity which is not where it’s at). What I can gather is that it seems to be my private key? Why would it need my private key? Anyway, if anyone can see the problem I greatly appreciate the help.

Thanks.


#5

What OS are you using on your machine that’s doing the uploading?

If you use windows I can make you a small vb.net app that will do the business, you’d just need to setup a scheduled task for when and how you want the app to run.


#6

We run Linux/Mac at my office. The machine I’m trying to run the cron job on is a Mac.


#7

Ah, can’t write apps for Mac :slight_smile:


#8

The message from there that most jumps out at me is:

debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> debug1: read_passphrase: can't open /dev/tty: Device not configured debug2: no passphrase given, try next key

It sounds as though your SSH key has a passphrase on it — since there’s no way to ask for the passphrase while the cron job is running, the key can’t be used. You will need to remove the passphrase, or set up a separate SSH key with no passphrase, to allow it to run from a cron job.

(If you are running on a Mac, it’s possible that the passphrase has been added to your Keychain. This will confound debugging a bit, since the Keychain is only available when you are running the script from an unlocked login session.)


#9

It does have a passphrase for security. I tried using a dummy account with no passphrase, but then it just defaulted back to the user account’s password through dreamhost. Is there a way to include the dreamhost user account’s password or something of the like?


#10

You need to add that second keypair’s public key to the authorized_keys file on the server.


#11

Yes, that’s already been done. Like I vaguely mentioned in my first post, I can run the script and run just the scp line in the command line and it works just fine and doesn’t ask for a password - i.e. the public keys are on both the server and the local machine. I can ssh in and sftp without it asking for a password. The password obviously has been saved in the keychain, but I’ve also tried logging out and even rebooting and it still doesn’t require a password.

The only problem is when I run it in cron. The cron job will open the script and run the script, but when it tries to open the connection to the server, it fails as is noted in the log. The main concern is somewhere in the private keys, but I don’t know how to fix this issue.


#12

If I understood you correctly, you said you created a second keypair without a passphrase, but using that one the server asks you for a password.

If that’s so, then the server doesn’t know the public key of that second keypair.