Hi
I'm new on ssh

This is my current situation

A: Fresh installed CentOS 6.5
B: CentOS 6.5 (Installed at 2013. Oct, updated via YUM)
C: window7 64bit

From A to B connection, it works with no trouble. C to B is also OK. (via putty)
A to A (ssh localhost or ssh XXX.XXX.XXX.XXX ->ip of A) is also fine.

However C to A or B to A are failed.

And I got following message.
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: connect to address XXX.XXX.XXX.XXX port 22: Connection refused
ssh: connect to host XXX.XXX.XXX.XXX port 22: Connection refused

I deactivated SElinux, iptable and firewall. But still it does not work!

I also remove and re-install openssh, nothing changed.

I also checked /etc/hosts.allow and /etc/hosts.deny.

Is there anything I can do?

So the working connections are:
A to B
C to B
A to A

And the failed connections are:
C to A
B to C

But what about:
A to C
B to A
C to C

Which system(s) do you want ssh access to? Which connection did you post the output from? How did you set up the ssh server on your Windows box? How did you disable SELinux and iptables? Have you looked in the log files on the server of interest to see why it's rejecting the SSH attempts?

Thank you for reply.

Sorry, there are some error.

failed connections are
B to A
C to A

So what I want is the connection to 'A' via SSH

I disable SELinux using system-config-SElinux.
iptable was stopped using system-config-services

I've check /var/log/secure.
But there is no record about B to A or C to A. It's odd.

More strange thing is A to B to A is work!
I first connected to B from A.
The connection was successful.
Then I tried to connect to A using same terminal. It works!
It was done on 'A' console.

I check netstat and both connections (A to B and B to A) were estblashed.

So I tried B to A connection on 'B' console. But nothing changed. The connection still refused.

Did you restart the machine after disabling selinux? I believe iptables can be stopped on the fly, but selinux changes only take effect on the next boot.

Thanks for reply.

I rebooted both console several times.

This should normally indicate that nobody is listening on A's ssh port 22, or the firewall blocks it.

In a later post, you say that you checked with netstat. Are you sure that the sshd process is listening on port 22 of A's IP address?

Another test would be running the sshd in debug mode. E.g.

This way, it uses port 2222 instead of 22.

On the client, run ssh -p 2222. See if sshd on A says anything.

You might also want to check ssh_config and ~/.ssh/config (client) and sshd_config (server) for wrong bind addresses. Or use a default config file, which you probably find under /usr/share.

Thanks for reply.

However port 2222 still doesn't work.

I used a default config file.

One of strange thing is this...

After removing known_hosts...



[root@Cell test]# ssh -v root@10.18.10.40
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.18.10.40 [10.18.10.40] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.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
The authenticity of host '10.18.10.40 (10.18.10.40)' can't be established.
RSA key fingerprint is 1c:52:ef:62:1b:ea:0c:e5:b5:b0:2a:4a:87:55:9a:03.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.18.10.40' (RSA) to the list of known hosts.
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
Read from socket failed: Connection reset by peer


B can obtain public key of A. However connection has been failed.
I tried once more. but almost same result (with known_hosts)

[root@Cell test]# ssh -v root@10.18.10.40
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.18.10.40 [10.18.10.40] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.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.18.10.40' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
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-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure. Minor code may provide more information


debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@10.18.10.40's password:
Read from socket failed: Connection reset by peer

After several attempts.....

[root@Cell test]# ssh -v root@10.18.10.40
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.18.10.40 [10.18.10.40] port 22.
debug1: connect to address 10.18.10.40 port 22: Connection refused
ssh: connect to host 10.18.10.40 port 22: Connection refused
[root@Cell test]#

You say you have the same result when using port 2222, but what does the ssh daemon on 10.18.10.40 say?

Or kill the ssh daemon on 10.18.10.40 (service sshd stop) and run it in debug mode there, using the default port: /usr/sbin/sshd -d. You may get an idea why it drops the connection.

Two more hints. This could be related to the keys setup on the server, or perhaps the permissions of the .ssh directory and its content on the server (by "server", I mean the system running the sshd).
.ssh must have permissions 700; .ssh/authorized_keys must be 600. And of course they must be owned by the correct user.

And a final hint: An impressive list comes up when I google for "Read from socket failed: Connection reset by peer" ssh.

I used clone mac address for some reason.
However this might be the reason. I changed back to orignal address and ask my network administrator to register 'original address'.
And it works. I don't think generally clone mac address does not make trouble. But it looks like that the problem is related with firewalls or something of my institute.

Thank you for all.