Skip site navigation (1)Skip section navigation (2)
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>