scp works on command line, fails in cron
ton...@hotmail.com
I am a bit baffled here. I have set up public/private key
authentication many times and have not had the sort of problem I am
having now.
I am testing a script that will be the framework for more complicated
tasks and the first test I want to run is a simple scp from one server
to another. I am starting very simple, no passphrase (yet) and am
already running into a wall. When I run this command:
/usr/local/bin/scp /tmp/2 10.46.0.102:/utils/backup
It copies the file /tmp/2 to /utils/backup on 10.46.0.102 with no
issue. When I try to do the same thing from cron, I get an email from
cron with this:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password,keyboard-interactive).
lost connection
Any ideas why authentication works fine from the command line, but
gives the above error in cron?
Richard E. Silverman
Chuck
Hash: SHA1
Are you using a ssh-agent, or an encrypted private key?
- --
To reply by email remove "_nospam"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0YntzIf+rZpn0oQRApdPAJ4jDOlG2xe4veeDuFwx9nAHD3BRDgCgnE71
nw5rZVceHkPJd25focwSOJQ=
=5MqA
-----END PGP SIGNATURE-----
ton...@hotmail.com
Chuck wrote:
> Are you using a ssh-agent, or an encrypted private key?
I am not using ssh-agent, but I am using an encrypted private key?
Like I said in the original post, the authentication works find when
run from the command line. It only fails when run in cron, leading me
to believe that there are no issues with the public/private keys (but
of course I could be wrong, it would not be the first time!)
ton...@hotmail.com
http://www.snailbook.com/faq/general-debugging.auto.html
Not sure what you mean by posting this link..is that a question or a
statement?. I know how to set up public/private key authentication (as
I stated, it works fine when run on the comand line, so either this is
an issue with cron or my environment variables)
Ah, maybe this is what you are after:
# operating systems on the client and server hosts, and their versions
All systems involved are Solaris 9 running on V880s.
# SSH software on the client and server hosts, and their versions
OpenSSH_3.8p1
# Exactly what you are trying to accomplish, and exact error messages
you are getting, preferably quoted program output. Just saying, "I got
an error!" is entirely useless.
# Include all the output from the debugging steps given above, or as
many as you can perform in your situation.
See the original post.
scp -v output:
Executing: program /usr/local/bin/ssh host 10.46.0.102, user
(unspecified), command scp -v -t /utils/backup OpenSSH_3.9p1, OpenSSL
0.9.7d 17 Mar 2004
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to 10.46.0.102 [10.46.0.102] port 22.
debug1: Connection established.
debug1: identity file /home/tissicin/.ssh/identity type -1
debug1: identity file /home/tissicin/.ssh/id_rsa type -1
debug1: identity file /home/tissicin/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.8p1
debug1: match: OpenSSH_3.8p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 '10.46.0.102' is known and matches the RSA host key.
debug1: Found key in /home/tissicin/.ssh/known_hosts:18
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,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tissicin/.ssh/identity
debug1: Trying private key: /home/tissicin/.ssh/id_rsa
debug1: Offering public key: /home/tissicin/.ssh/id_dsa
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: password
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
Permission denied, please try again.
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
Permission denied, please try again.
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
lost connection
Note that I have tried it with the user and without, i.e.
scp /tmp/2 10.46.0.102:/utils/backup
and
scp /tmp/2 us...@10.46.0.102:/utils/backup
Both produce the same results.
The same -v output when run from the command line:
/usr/local/bin/scp -v /tmp/2 10.46.0.102:/utils/backup
Executing: program /usr/local/bin/ssh host 10.46.0.102, user
(unspecified), command scp -v -t /utils/backup
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to 10.46.0.102 [10.46.0.102] port 22.
debug1: Connection established.
debug1: identity file /home/tissicin/.ssh/identity type -1
debug1: identity file /home/tissicin/.ssh/id_rsa type -1
debug1: identity file /home/tissicin/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.8p1
debug1: match: OpenSSH_3.8p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 '10.46.0.102' is known and matches the RSA host key.
debug1: Found key in /home/tissicin/.ssh/known_hosts:18
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,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key:
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t /utils/backup
Sending file modes: C0755 11230 2
2
100% 11KB 11.0KB/s 00:00
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
Chuck
Hash: SHA1
How are you feeding it the passphrase if you have an encrypted private
key but aren't using ssh-agent? It looks like it's failing to decrypt
the private key.
- --
To reply by email remove "_nospam"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0chZzIf+rZpn0oQRAtfpAJ4nn47aFTT5RJw63ceCMNVwZWIYOQCfY76L
rY8DmyJ3P0IVfuA1QaqWKLU=
=q8yp
-----END PGP SIGNATURE-----
ton...@hotmail.com
"...I am starting very simple, no passphrase (yet) "
I am not using a passphrase. This user has an empty one. (for now)
Chuck
Hash: SHA1
Then you are using an unencrypted passphrase. Here's a couple of things
to check.
1) Is the cron script connecting to the same server? If not, the server
it's connecting to probably doesn't have the public key in the
authorized_keys file
2) Is the cron script using the same identity file? (i.e are you using
the -i option and if so is the file name the same)
- --
To reply by email remove "_nospam"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0dfAzIf+rZpn0oQRAgQmAKCde2bzizDpyY6B7XJOnwuQgIAJZgCdHohw
YCFOKsD0hFlFviOel1eV/5I=
=/KUG
-----END PGP SIGNATURE-----
Chuck
Hash: SHA1
Chuck wrote:
| ton...@hotmail.com wrote:
| |>From my original post:
| |
| | "...I am starting very simple, no passphrase (yet) "
| | I am not using a passphrase. This user has an empty one. (for now)
| |
|
| Then you are using an unencrypted passphrase. Here's a couple of things
| to check.
Oops. That should say "you are using an unencrypted private key". The
rest of the reply applies.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0df5zIf+rZpn0oQRAuD1AJkBj2Gs57aC89G7aNlLFvpboTeyVACfQY0B
tN4APJYROXpNZLL8rgbj990=
=/OOs
-----END PGP SIGNATURE-----
ton...@hotmail.com
> 1) Is the cron script connecting to the same server? If not, the
server
> it's connecting to probably doesn't have the public key in the
> authorized_keys file
Yes. In fact, if I do
crontab -l
...and cut and paste the command from the output, the copy works fine.
It *only* fails when run from cron.
> 2) Is the cron script using the same identity file? (i.e are you
using
> the -i option and if so is the file name the same)
See above. Running the script from the command line works, when cron
runs it, it fails.
This is the wierdest authentication problem I have ever seen.
Frank_Hamersley
> I am testing a script that will be the framework for more complicated
> tasks and the first test I want to run is a simple scp from one server
> to another. I am starting very simple, no passphrase (yet) and am
> already running into a wall. When I run this command:
>
> /usr/local/bin/scp /tmp/2 10.46.0.102:/utils/backup
>
> cron with this:
>
> Permission denied, please try again.
> Permission denied, please try again.
> Permission denied (publickey,password,keyboard-interactive).
> lost connection
Can you pls post your crontab line (with suitable obfuscation of sensitive
bits)?
Also which shell are you using for your CLI?
Cheers, Frank.
Richard E. Silverman
Note the following differences:
WORKS:
> debug1: Next authentication method: publickey
> debug1: Offering public key:
> debug1: Server accepts key: pkalg ssh-dss blen 433
> debug1: Authentication succeeded (publickey).
DOESN'T WORK:
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/tissicin/.ssh/identity
> debug1: Trying private key: /home/tissicin/.ssh/id_rsa
> debug1: Offering public key: /home/tissicin/.ssh/id_dsa
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Next authentication method: keyboard-interactive
Two points: 1) the list of keys it decides to try is different, and 2)
when it does succeed, the key has no comment on it. Usually, it would say
the filename, e.g.:
debug1: Offering public key: /u/res/.ssh/res-dsa
Something odd is going on -- crank up the debugging to -vvv and get the
server syslog and/or debug output too.
--
Richard Silverman
r...@qoxp.net
ton...@hotmail.com
* * * * * /usr/local/bin/scp -v /tmp/2 10.46.0.102:/utils/backup
This runs it every minute for testing purposes.
I have tried using bash and ksh, both give the same results. I double
checked to make sure my path to the shel is correct (i.e. /usr/bin/ksh
and /usr/bin/bash )
No other cronjobs fail, just this one..
Bill Unruh
Is your secret key file (id_rsa) password protected with something like
ssh-agant running so you forgot that you had to enter the password sometime
in the past?
If you are going to use scp from cron then you cannot have the secret key
files password protected.
Frank_Hamersley
> Here is the crontab line:
>
> * * * * * /usr/local/bin/scp -v /tmp/2 10.46.0.102:/utils/backup
Personally I use rsync (with ssh) for this sort of stuff. Anyway try the
following...
* * * * * /bin/bash -c '/usr/local/bin/scp -Bv /tmp/2
tiss...@10.46.0.102:/utils/backup'
(I am guessing the correct user id is tissicin)...then post the results.
Cheers, Frank.
ton...@hotmail.com
the results:
/usr/bin/bash -c '/usr/local/bin/scp -Bv /tmp/2
tissicin@@10.46.0.102:/utils/backup'
Executing: program /usr/local/bin/ssh host 10.46.0.102, user tissicin@,
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key:
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Trying private key: /home/tissicin/.ssh/identity
debug1: Trying private key: /home/tissicin/.ssh/id_rsa
debug1: Offering public key: /home/tissicin/.ssh/id_dsa
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
lost connection
FYI, I am using DSA, not RSA if that matters.
Frank_Hamersley
> I tried the rsync command, it doesnt work on the command line.
Because the (current) versions of rsync use ssh as a transport I wouldn't
expect it to work until we can get the scp working. Once that is done take
another look at rsync if you have a lot of files or a lot of data to move.
> /usr/bin/bash -c '/usr/local/bin/scp -Bv /tmp/2
tissicin@@10.46.0.102:/utils/backup'
> Executing: program /usr/local/bin/ssh host 10.46.0.102, user tissicin@,
> command scp -v -t /utils/backup
> OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004
[snip]
> debug1: identity file /home/tissicin/.ssh/identity type -1
> debug1: identity file /home/tissicin/.ssh/id_rsa type -1
> debug1: identity file /home/tissicin/.ssh/id_dsa type 2
> debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8p1
> debug1: match: OpenSSH_3.8p1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.9p1
[snip]
> debug1: Host '10.46.0.102' is known and matches the RSA host key.
> debug1: Found key in /home/tissicin/.ssh/known_hosts:18
[snip]
> debug1: ssh_rsa_verify: signature correct
[snip]
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Trying private key: /home/tissicin/.ssh/identity
> debug1: Trying private key: /home/tissicin/.ssh/id_rsa
> debug1: Offering public key: /home/tissicin/.ssh/id_dsa
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: No more authentication methods to try.
> Permission denied (publickey,password,keyboard-interactive).
> lost connection
I can't detect anything that is particularly unusual. The remote server is
identified using an RSA key but that should be OK. The only other bit I'm
not sure about is the key exchange. Firstly the RSA keys show "Trying
private key" whereas for the DSA key it seems the process has been reversed
because it says "Offering public key". Other more enlightened ssh types
will probably confirm this is normal for the DSA authentication protocol.
> FYI, I am using DSA, not RSA if that matters.
FWICT it shouldn't matter although I have always used RSA keys.
The next step is probably to run the command with -v -v (i.e.. twice) to get
the next level of debug statements.
The curious thing to me is that if cron invocations fail while interactive
ones succeed, it "seems" clear that it is a user process/environment
problem. This is a common issue in using cron because the forked shell is
quite different on start-up to a normal keyboard interactive shell and
usually requires an effort to get all the environmental variables and paths
established that shell scripts presume are present.
The only other thought - I was wondering if the fact that there is no
physical keyboard is interfering with the steps around considering
"keyboard-interactive" mode even though it is not expected to be used?
Cheers, Frank.
ton...@hotmail.com
past. In fact, I tested this same script on a Linux system to the
solaris box, and it works just fine in cron.
I am pretty sure there is something screwed up with my environment
settings but I don't have a clue as to what it could be.
Richard E. Silverman
You might try my suggestions.
----------------------------------------------------------------------
Newsgroups: comp.security.ssh
Subject: Re: scp works on command line, fails in cron
From: Richard E. Silverman <r...@qoxp.net>
Date: 28 Dec 2004 20:16:57 -0500
Message-ID: <m24qi5e...@darwin.oankali.net>
Note the following differences:
WORKS:
> debug1: Next authentication method: publickey
> debug1: Offering public key:
> debug1: Server accepts key: pkalg ssh-dss blen 433
> debug1: Authentication succeeded (publickey).
DOESN'T WORK:
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/tissicin/.ssh/identity
> debug1: Trying private key: /home/tissicin/.ssh/id_rsa
> debug1: Offering public key: /home/tissicin/.ssh/id_dsa
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Next authentication method: keyboard-interactive
Two points: 1) the list of keys it decides to try is different, and 2)
Chuck
Maybe it's not your environment that's screwed up, but cron's. There are
a couple of files that cron uses to set up a it's environment but I
can't remember what they are called right now.
Maybe what you could try is to export your entire interactive
environment to a file and source it at the beginning of your cron script.
ton...@hotmail.com
The first line of my script now sources in my .profile and it finally
works from cron!
Thanks so much for all the input!
Hopeflly we all learned something here, I know I did!
:)
Richard E. Silverman
If you found out what was in your .profile that made the difference and
told us, we might learn something; as it is, no, we haven't.
--
Richard Silverman
r...@qoxp.net
Chuck
Hash: SHA1
Ditto. Please let us know what in the .profile made the difference. If
you want to just post a copy of it along with any scripts it sources
that would be fine too. Someone here will probably see the problem right
away. If you do this be sure to scrub the files of anything you wouldn't
want to make public knowledge.
- --
To reply by email remove "_nospam"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB3BF1zIf+rZpn0oQRArbHAJ9PfJzIMAhomkql70bF5kJb5M7fvQCeO3pe
jLTFk6akevS6N/Ve0ftK5dM=
=95qk
-----END PGP SIGNATURE-----
ton...@hotmail.com
cat .profile
MAIL=/usr/mail/${LOGNAME:?}
ENV=$HOME/.kshrc
export ENV
cat .kshrc
HISTSIZE=2048
set -o vi
PS1=`hostname`:'$PWD>'
export EDITOR=vi
export PATH=$PATH:/usr/local/bin:/home/tissicin/bin
alias rm='rm -i'
alias ls='ls -F'
alias l='ls -altr'
stty erase '^H' susp '^Z'
alias ifc='ifconfig -a'
Anything in there look suspect?
Frank_Hamersley
Not to me - although I wonder if the act of sourcing the .profile sharpened
up the environment just a tad such that made ssh feel at home - perhaps $ENV
might be involved! What is in $HOME/.kshrc?
Otherwise it would be useful to run a cron job that simply runs an "env"
command with and without a source .profile and take a look at the
differences. Certainly cron sets up a very bare-bones shell but there
doesn't seem to be anything in the .profile above that ssh would need IMO.
Cheers, Frank.