Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Oct 2002 13:44:12 -0700
From:      "Kevin Oberman" <oberman@es.net>
To:        Gerard Samuel <gsam@trini0.org>
Cc:        FreeBSD Questions <questions@FreeBSD.ORG>
Subject:   Re: passwordless scp and cronjobs 
Message-ID:  <20021004204412.7CD245D04@ptavv.es.net>
In-Reply-To: Your message of "Fri, 04 Oct 2002 15:48:56 EDT." <3D9DF0A8.7040508@trini0.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 04 Oct 2002 15:48:56 -0400
> From: Gerard Samuel <gsam@trini0.org>
> 
> I started the whole process again and added the SSH2 option to the 
> command line which now looks like this ->
> scp -o 'Protocol=2' -v ~/temp/file.zip sys_dev@hivemind:

Good. This is now at least running V2 protocol.

> Towards the bottom you'll see its trying authentication methods, using 
> the public key as the first option.
> I would tend to believe if all were well, it shouldn't have to go past 
> that point.

This is absolutely correct. Unfortunately, the client lacks the
knowledge of why the publickey method was rejected. You can only tell
that the attempt failed.

I doubt that you will luck into the correct fix by shots at the config
file. Instead, get debug information from the server side. To do this
you will need root access to the server-side system.

On the server side:
% /usr/sbin/sshd -p 378 -d
This will start a new instance of the ssh daemon that will connect to
port 378. (If 378 is not available on your system, pick another port
<512.) This instance will not fork a daemon and will print verbose
debug information.

Then add -P 378 to the scp on the client and try again. The daemon
debug information is usually enough to clarify what is failing.

Finally, I really get uncomfortable seeing un-encrypted private keys
being used. They are a significant vulnerability. I hope that the
account is in a jail or in some other way limited in access on the
destination system.

You might consider the use of .shosts and host authentication for
this. While there is a slightly greater possibility of spoofing, it is
probably safer than an open key that can get you to somewhere
vulnerable. 

Good luck.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634

> debug1: send SSH2_MSG_SERVICE_REQUEST
> debug1: service_accept: ssh-userauth
> debug1: got SSH2_MSG_SERVICE_ACCEPT
> debug1: authentications that can continue: 
> publickey,password,keyboard-interactive
> debug1: next auth method to try is publickey
> debug1: try pubkey: /home/gsam/.ssh/id_rsa
This SHOULD have worked!
> debug1: authentications that can continue: 
> publickey,password,keyboard-interactive
> debug1: try privkey: /home/gsam/.ssh/id_dsa
> debug1: next auth method to try is keyboard-interactive
> Password:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021004204412.7CD245D04>