Ian Truelsen wrote:
> Dave Reed writes:
>
> > 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
> >
> Okay. Set this up as you suggest, assuming that the files on the remote
> machine should be, as in the local machine, HOME/.ssh/
>
> Here is what it looks like now:
>
> [doctor@minion1 doctor]$ ssh -2 -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/id_rsa type 1
> debug1: identity file /home/doctor/.ssh/id_dsa type 2
> 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: 126/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: 1033/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 pubkey: /home/doctor/.ssh/id_rsa
> debug1: authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: try pubkey: /home/doctor/.ssh/id_dsa
> debug1: authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: next auth method to try is password
> doctor@dark-lord's password:
> debug1: ssh-userauth2 successful: method password
> debug1: channel 0: new [client-session]
> debug1: channel_new: 0
> debug1: send channel open 0
> debug1: Entering interactive session.
> debug1: client_init id 0 arg 0
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: channel request 0: shell
> debug1: channel 0: open confirm rwindow 0 rmax 16384
>
> I don't seem to be getting any closer.
>
> The permissions are set to 0600 for the remote machine's id_dsa, and 0644
> for the authorized_keys. On the local machine, the id_dsa file is set to
> 0600 and the id_dsa.pub is set to 0644.
Your key authentication is not working (DUH, I had to say it) It is trying
but for some reason it is not authenticating.
Is there anything in the logs on the remote machine?
what is the contents of /home/doctor/.ssh /authorized_keys2 on the remote
machine.
If you don't get anywhere. try running sshd on the remote machine in debug
mode.
>From the man page for sshd:
-d Debug mode. The server sends verbose debug output to the system
log, and does not put itself in the background. The server also
will not fork and will only process one connection. This option
is only intended for debugging for the server. Multiple -d op-
tions increase the debugging level. Maximum is 3.
so ... as root:
# service sshd stop
# /usr/sbin/sshd -d
Then try the remote connection My guess is there is still something wrong with
the id_dsa.pub key from the local machine not being in the
.ssh/authorized_keys2 file
Bret
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
