I have an application running in my corporate environment, which users access through SSH. All the users within the corporate network as that of the server are able to access this application over SSH.

However, all of a sudden users from a different network outside our corporate network, for whom necessary firewall rules are in place, are unable to access this application over SSH. From a machine on the external network, we are able to do a telnet to port 22 of the server successfully. However, when we try to establish a SSH connection to the server on the corporate network, we get a message saying that the "Server Closed the connection".

Have been hanging around this issue for 2 weeks now. But unable to get a solution. When one can do telnet to port 22, does that mean the client and the server can communicate successfully over SSH without any restrictions or does the ability to telnet not imply full SSH 2 way communication between client and server ? Is there a way of testing between the client and server If SSH connection will work among them, other than telnet ?

  • Even if you test with telnet or nmap and both work, that doesn't mean access from a certain IP is guaranteed. I'd check the firewall rules on the server first. – schaiba Sep 11 '13 at 15:59
  • 2
    please post the output of 'ssh -vvv hostname' – RSFalcon7 Sep 11 '13 at 16:04
  • it's seems your network is blocked using TCP Wrapper, you can check /etc/hosts.allow and /etc/hosts.deny in server side – Rahul Patil Sep 11 '13 at 17:07
  • Pls do ssh -vvv at client, for the server, content of /var/log/secure (or equivalent login log for your OS) and post them here – Shâu Shắc Sep 11 '13 at 19:13

First off get your client to connect with ssh -vvv (which will output some debug information about what ssh is doing). That may help you diagnose the issue, this is the most likely place to shed light on the issue.

Second check that if you are using a hostname to connect to the SSH server that the DNS resolves to the correct host.

The sshd may be set to use TCP Wrappers. You may have to add entries in /etc/hosts.allow.

Depending on the authentication mechanisms used by the server, if the user is not using the correct mechanism, they will not be allowed. (For example if it is set to only allow PubkeyAuthentication and you have not got a public key set for that user they will get rejected).

You may have PubkeyAuthentication set and the client may be using SSH v1 to connect (which is RSAAuthentication only).

Third sshd itself has a number of configuration settings that could reject the connections (man 5 sshd_config) to get details on each one:

 AllowUsers, DenyUsers, DenyGroups, AllowGroups, AuthorizedPrincipalsFile
  • Agreed. If you can telnet to the port and get a sshd prompt you are talking to sshd, and can start debugging the ssh-handshake. The -vvv combined with looking at the logs will most likely show quickly where the problem is. – Thorbjørn Ravn Andersen Sep 11 '13 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.