Date: Fri, 04 Oct 2002 18:10:10 -0400 From: Gerard Samuel <gsam@trini0.org> To: Kevin Oberman <oberman@es.net> Cc: FreeBSD Questions <questions@FreeBSD.ORG> Subject: Re: passwordless scp and cronjobs Message-ID: <3D9E11C2.7040506@trini0.org> References: <20021004204412.7CD245D04@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
And deeper into the rabbit hole I go. Here is a snip from server debug -> ----------------------------- debug1: userauth-request for user sys_dev service ssh-connection method none debug1: attempt 0 failures 0 debug1: Starting up PAM with username "sys_dev" debug1: PAM setting rhost to "gladiator.trini0.org" Failed none for sys_dev from 192.168.0.3 port 1042 ssh2 debug1: userauth-request for user sys_dev service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/developer/.ssh/authorized_keys debug1: restore_uid debug1: trying public key file /home/developer/.ssh/authorized_keys2 Authentication refused: bad ownership or modes for file /usr/home/developer/.ssh/authorized_keys2 debug1: restore_uid Failed publickey for sys_dev from 192.168.0.3 port 1042 ssh2 Now, seeing this, got me thinking. The directory is a shared directory between shared users (some friends of mine that I trust). So I changed the ficticious user sys_dev's home directory to their own, and everything started working. Kevin, thanks for the help. Now that I have this working, I can look at locking down this little system.... Kevin Oberman wrote: >>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: >> >> > > > > -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ 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?3D9E11C2.7040506>