I am trying to set up bidirectional password-less login between a linux and a Solaris. The way I am doing is very simple, which is creating pub/priv key pairs on each host and add the pub key to each other's authorized_keys file:
ssh-keygen -t rsa (I tried dsa, and it didn't work aslo)
Surprisingly enough, having done the same set up on both machines, only linux->solaris trusted connection works while solaris->linux does not :wall:
Here is the verbose logs I got when I try to ssh to linux from the solaris:
debug1: Next authentication method: publickey
debug1: Trying private key: /home/nyfcgstg/.ssh/identity
debug3: no such identity: /home/nyfcgstg/.ssh/identity
debug1: Offering public key: /home/nyfcgstg/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug2: input_userauth_pk_ok: fp 80:58:a9:ba:b7:f8:5d:21:16:bd:4c:f8:d1:e0:04:dc
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
Connection closed by xx.xx.xx.xxx
debug1: Calling cleanup 0x41afc(0x0)
After reading the private key the connection just closed by the Solaris.
The same pub key of linux is accepted by other Linux boxes so I am thinking this can be a cross-platform issue?
Open ssh on Linux: OpenSSH_5.2p1_q1.g463c730, OpenSSL 0.9.8k 25 Mar 2009
Open ssh on Solaris:OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
I suppose the problem to be on the server side of the communication: check "/etc/sshd_config" or whatever else you use as a configuration file for "sshd". Restart "sshd" after any changes you make there to read in the new configuration.
No, not at all. But ssh-communication requires two things to work in accordance: the client side (ssh-client, authentication data) and the server side (the sshd daemon and its configuration).
I don't claim to know what went wrong in your case, but the debug output you provided makes me suppose the problem is with the server side. To verify this one will have to examine the server configuration and eventually reconfigure/restart it, as i have told you.
Alternatively you can try to set up communication from a third host to the problematic one: if i got you correctly "HostA->HostB" works, but "HostB->HostA" doesn't. Set up "HostC->HostA" and see if this works. If it does it is probably not the sshd in host A as such, but maybe just the configuration: there are different versions of open-ssl (the library which does the underlying encryption) and maybe you hit upon such a version incompatibility.
Fact is: i don't know and as long as you can't present more and better data probably nobody can. So we are left to suggestions and more or less educated guesses about possible reasons.
I used your method and found out the problem was with HostA, because it can connect to every hosts but none can connect to it. so I asked system admin to check on the netgroups that HostA belonged to and eventually we realized there was a particular netgroup hostA should be added to.
The connection is working now. A method or a thought to investigate a problem is more valuable than a direct answer, because that would help people to learn more stuff.