Why does this bash script work at console but fails when run as a cron job?

I have the following bash script, which runs without problems at the CLI, but fails when run as a cron job.

#!/bin/bash

cd /home/oompah/scripts/tests/
scp -P 12345 file1 oompah@someserver.com:~/uploads

if scp -P 12345 oompah@someserver.com:/path/to/file2.dat local.dat >&/dev/null ; then 
    echo "INFO: transfer OK" ; 
else 
    echo "ERROR: transfer failed" ; 
fi

The error message I get (redirected to a log file) when I run it as a cron job is:

ERROR: transfer failed

The error message I get in my mail inbox is:

Permission denied (publickey).
lost connection

The first scp (copy) fails as well (although I am not checking it). Does anyone know why this is happening, and how I may fix it?.

BTW: I am running this on Ubuntu 10.0.4 LTS

[Edit]

I added the -i option to scp (first command in script), and also added debugging (using the v option). Here is the full debug trace:

Executing: program /usr/bin/ssh host 12.34.56.78, user oompah, command scp -v -t ~/uploads
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 12.34.56.78 [12.34.56.78] port 12345.
debug1: Connection established.
debug1: identity file /home/oompah/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu3
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[12.34.56.78]:12345' is known and matches the RSA host key.
debug1: Found key in /home/oompah/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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/oompah/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
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).
lost connection
Permission denied (publickey).

Hopefully this provides more clues

You are probably running with an ssh-agent or have auth'ed you private key specifically. When you run in cron you do not have a session, and you do not have anything that goes along with sessions like ssh-agent or ttys to read a password from.

Create a password-less key and add the public key to the target account under ~target/.ssh/authorized_keys. You will then be able to use the key you just created with scp to auth and copy the file.

FYI: You may want to read the ssh server man page on command keys and how key access and authentication work.

If you don't change user accounts, this would is usually be a problem with the environment. You can check that by running env and/or set and redirecting the output to a file, comparing the results from the cli and cron. In this case, it looks like cron is doing a set -x before running your script so the first error causes the script to exit.

Two possible solutions. Add a || true to any command that can fail without any issues. Or you can do a set +x at the top of your script to revert to the behavior you have on the command line.

Edit: scratch that. I though your script was dying on the first scp until I reread your question. It's most likely a problem with your environment. Put an env >/path/env.out at the top of your script and compare your cli vs cron results.

Edit: one other idea, are you encrypting home directories, and if so, are you logged in when this cron script runs? If you aren't logged in with the directory encrypted, you won't be able to run this. For this reason, I only encrypt home directories on desktops that I'll always be logged in.