|
Passwordless ssh on the same host
Hi,
I have to hosts named host1 and host2. I am trying to create a passwordless ssh for them. What I did: On Host1, ssh-keygen -t rsa got the id_rsa.pub key and added it to the authorized keys of host2. scp id_rsa.pub root@host2: cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys * Its works fine if I do a ssh root@host2 from host1. I repeated the same steps for Host2 and added its key in Host1. but it doesn't work. I even added the rsa key of host1 into its own authorized keys..to see If I could do a passwordless ssh root@host1 from host1 and it failed too...I had to put password everytime.. Please help me. |
1. is the sshd daemon running on both? any differences in the sshd configs?
2. what about firewall ie iptables? 3. try 'ssh -vvv ...' to get verbose output |
Thanks for the response chris.
Sshd deamon is running on both the machines. result for Iptables rule is [root@cl39-10s13 ~]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination I tried running 'ssh -vvv' it doesn't work. |
Here is the debug Info :
[root@cl39-10s13 ~]# ssh -v root@10.39.10.13 OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.39.10.13 [10.39.10.13] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: loaded 3 keys debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr 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 '10.39.10.13' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 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: gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Unknown code krb5 195 debug1: Unspecified GSS failure. Minor code may provide more information Unknown code krb5 195 debug1: Unspecified GSS failure. Minor code may provide more information Unknown code krb5 195 debug1: Next authentication method: password |
a fast google read on your error came up with a few options to check.
1. verify the permissions on both ends for the ~/.ssh directory and its files. 2. update your ssh on both ends. they should look as follows: Code:
ssma-imac:~ ssma$ ls -laF .ssh |
... also, don't forget that "password" should not be among the "authorizations that can continue."
SSH is like the "impregnable fortress" that has a moat surrounded by archers with drawn bows ... and also, a little garden gate. If you don't have what it takes to get past the archers, you can always just try the garden gate. It will let you in, either way, unless you explicitly disable all the weaker alternatives. |
| All times are GMT -5. The time now is 07:14 AM. |