> > 
> > I haven't read all the messages in this thread carefully, but have you
> > sent the output of ssh -v to the list? That should tell us where the
> > problem is (i.e., ssh -v hostname, where hostname is the name of the
> > machine you are connecting to). 
> > 
> Here is the output of ssh -v: 
> 
> [doctor@minion1 doctor]$ ssh -v dark-lord
> OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Seeding random number generator
> debug1: Rhosts Authentication disabled, originating port will not be 
> trusted.
> debug1: restore_uid
> debug1: ssh_connect: getuid 500 geteuid 0 anon 1
> debug1: Connecting to dark-lord [192.168.100.1] port 22.
> debug1: temporarily_use_uid: 500/500 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 500/500 (e=0)
> debug1: restore_uid
> debug1: Connection established.
> debug1: identity file /home/doctor/.ssh/identity type 0
> debug1: identity file /home/doctor/.ssh/id_rsa type -1
> debug1: identity file /home/doctor/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2
> debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_2.9p2
> 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: 120/256
> debug1: bits set: 1032/2049
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'dark-lord' is known and matches the RSA host key.
> debug1: Found key in /home/doctor/.ssh/known_hosts2:1
> debug1: bits set: 1036/2049
> 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,keyboard-interactive
> debug1: next auth method to try is publickey
> debug1: try privkey: /home/doctor/.ssh/id_rsa
> debug1: try privkey: /home/doctor/.ssh/id_dsa

<rest snipped>

Looks to me like it's trying protocol 1 and then protocol 2. Which are
you trying to use? I've got it working using protocol 2.

For protocol 2, you should have an id_dsa and an id_dsa.pub on the
local machine. The remote machine should have its own id_dsa and
id_dsa.pub files. The remote machine should have a file named
authorized_keys2 which contains the contents of the local machine's
id_dsa.pub.

You might also try ssh -2 hostname to force protocol 2, assuming you
are trying to use protocol 2 and created your keys with: 
ssh-keygen -t dsa

HTH,
Dave



_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to