> > > > 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