Hi,
Same issue
ssobtest3.koel.co.in/apps12i]ssh -v oracle@ssobtest1
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ssobtest1 [10.1.1.71] port 22.
debug1: Connection established.
debug1: identity file /apps12i/.ssh/identity type -1
debug1: identity file /apps12i/.ssh/id_rsa type -1
debug1: identity file /apps12i/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
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(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ssobtest1' is known and matches the RSA host key.
debug1: Found key in /apps12i/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: /apps12i/.ssh/identity
debug1: Trying private key: /apps12i/.ssh/id_rsa
debug1: Trying private key: /apps12i/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).
Regards
Bala
Quote:
Originally Posted by jschiwal
If you load your private key in the putty keygen program, an openssh style public key is printed near the top of the dialog. However, if I had to use a windows client, I would install cygwin and use cygwin's ssh client.
Running "ssh -vv" will print out debug information. Also check the logs on the server. They may indicate a problem such as permissions.
The permissions of the user's home directory may cause a failure as well.
I had a situation where I used a "AllowUsers" entry using user@host which failed, but user@host.domain worked. It was the reverse DNS lookup phase that caused the the authentication failure.
|