View Full Version : SSH authorized _keys
Gwyrrdin
02-03-2002, 02:05 PM
hmmm
I did RTFM of ssh-keygen, ssh and sshd.
But it doesn't seem to work.
I want to kill the password for a script executed by cron. I generate a html page from my squid log on a linux box, and want to transfer the .html file with scp to my webserver.
I generated the identy.pub, id_rsa.pub and id_dsa.pub and cat-ted those in an authorized_keys file on my OS X box. I double checked the permissions and checked the conf files of both the client and server.
any pointers? am I overlooking something?
any hints are welcome....
Gwyrrdin
mervTormel
02-03-2002, 04:59 PM
i can't quite visualize this yet; what are the source and target hosts? source = linux, target = osx, source id's generated on source? fed to keygen on target?
so, does host-to-host ssh work?
what are the results of the scp? any messages in console or system.log other than auth failures? does scp -v give any illuminating info?
what's your scp look like?
i am flat out ignorant here, but it seems to me there would have to be some source to target ssh handshaking here in your scp. off to RTFM...
Gwyrrdin
02-03-2002, 05:53 PM
yeah ssh works fine
scp also
But I want to remove the password check. In other words I want to use the public key mechanism for authorisation instead of password.
FYI it's from a linux box to a OS X box.
no errors in logs on both side...
it just fails in public key and drops to password....
output from scp -v:
service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased
debug3: start over, passed a different list publickey,password,keyboard-interactive,hostbased
debug3: preferred publickey,password,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: password,keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
password:
off course the interesting thing her is the debug2 line:
debug2: we did not send a packet, disable method
btw...this is debug level 3, the highest avaible with ssh, as you know debuggin' scp is a pain in the ass...
so, you could rewrite the question to:
I want to use public_key based authication instead of password based...
and again....I did read the manpages and the FAQ's
what is going wrong here?????
mervTormel
02-03-2002, 06:54 PM
Gwyrrdin,
okay, i know (eyes crossed) my ssh installation works.
i get some interesting results using the scp -B (batch) switch, perhaps it will nudge you along...
in scp man pages, the batch switch says don't ask for pw or pphrase
so here's a vanilla scp
% scp -i .ssh/identity foo/bar targetIP:/pathto/file
user@ip's password:
bar 100% |*********| size KB 00:01
so, scp work, but i don't know why i pass it an identity, it still authenticates, but that's my problem, not yours, right?
but here's the interesting thing with the -B switch
% scp -vB -i .ssh/identity.pub foo/bar targetIP:/pathto/file
...
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: .ssh/identity.pub
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: no more auth methods to try
Permission denied (publickey,password,keyboard-interactive).
debug1: Calling cleanup 0x17a0c(0x0)
so, it dint get the right ident, but it dint ask for the auth, so perhaps this is close?
when i said 'off to RTFM...' i meant me off, not you off, you dig? :eek:
Originally posted by Gwyrrdin
...
I generated the identy.pub, id_rsa.pub and id_dsa.pub and cat-ted those in an authorized_keys file on my OS X box. I double checked the permissions and checked the conf files of both the client and server.
any pointers? am I overlooking something?
any hints are welcome....
Gwyrrdin
identity.pub is for ssh version 1, and id_rsa.pub and id_dsa.pub are for version 2, so you should put identity.pub into the authorized_keys file, but the id_*.pub files go into authorized_keys2. According to your -v output, it's using version 2 (SSH2_MSG_SERVICE_ACCEPT), hence it's only looking for authorized_keys2.
Gwyrrdin
02-04-2002, 02:18 AM
i tried that already....created that file, and even created the directory .ssh2 with the good files in it...
no go
cheers
Gwyrrdin
Gwyrrdin
02-04-2002, 04:14 AM
strange....
still workin' on it...
i think the problem is the ssh1 and 2 afterall...
when i force ssh to use ssh1 with the -1 switch, no password is being asked.
But SCP uses SSH1 authentication, and keeps asking for a password...
Weird world.
Novajo
02-04-2002, 10:10 AM
I am myself trying to get this whole thing to work, but have been unsuccessful. I wonder what type of mechanism you are using: are you simply not encoding your key or you are using a single entry mechanism? From what I understand, the best way to deal with passwords with SSH is found here at http://www.macosxhints.com/article.php?story=20011128174701140
on local machine as user who's crontab will hold the script:
ssh-keygen -t dsa
scp ~/.ssh/id_dsa.pub remote_user@remote.server:~/.ssh/temp
ssh remote_user@remote.server cat ~/.ssh/temp >> ~/.ssh/authorized_keys2
then.,..
ssh remote_user@remote_server
should not ask for a password unless the remote server is using ssh version 1 only.
The _best_ way to resolve _that_problem is to notify the sysadmin of the remote server that ssh1 is not nearly as stable or secure as openssh as nicely as you can.
Gwyrrdin
02-06-2002, 02:01 AM
that's exactly the way how I did it from the beginning.
But upgrading the ssh package on my linux box solved the problem.
On the linuxbox was openssh 2.9p2 installed.
Thanks for all the input and the method described above is the best way to do it.
Cheers
Gwyrrdin.
haironfire
08-14-2002, 02:20 AM
Trying to achieve the same result between my laptop on OSX and a remote server operating Red Hat Linux. Followed n9 post directions. A verbose log of the latest ssh attempt follows. Any help interpreting where I went wrong?
debug1: Connection established.
debug1: identity file /Users/springer/.ssh/identity type 0
debug1: identity file /Users/springer/.ssh/id_rsa type 1
debug1: identity file /Users/springer/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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 sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 137/256
debug1: bits set: 1612/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'es55191.easystreet.com' is known and matches the RSA host key.
debug1: Found key in /Users/springer/.ssh/known_hosts:3
debug1: bits set: 1596/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try pubkey: /Users/springer/.ssh/id_rsa
debug1: authentications that can continue: publickey,password
debug1: try pubkey: /Users/springer/.ssh/id_dsa
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is password
vBulletin® v3.8.4, Copyright ©2000-2010, Jelsoft Enterprises Ltd.