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>