sshd refuse connection?

Question

For some reason I cannot access from my vitrual machine my remote virtual server at a server farm and instead it gives me this error message:

   OpenSSH_5.9p1, OpenSSL 1.0.0g 18 Jan 2012
   debug1: Reading configuration data /etc/ssh/ssh_config
   debug1: /etc/ssh/ssh_config line 20: Applying options for *
   debug1: Connecting to www.xxx.de [XXX.XXX.XXX.XXX] port 22.
   debug1: Connection established.
   debug1: permanently_set_uid: 0/0
   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: identity file /root/.ssh/id_ecdsa type -1 
   debug1: identity file /root/.ssh/id_ecdsa-cert type -1
   ssh_exchange_identification: Connection closed by remote host

Recently I did a lot of reverse shell kung-fu and I've setup a defense script a while ago? What's the problem? My server runs Suse 12.1.

Solution 1

It sounds like your SSH client may have a stale key for that host. I'm not sure how to clean it out, but the identity file part suggests to me this may be the case.

Solution 2

I believe it is easier to debug these sorts of problems at the server end (assuming you can travel to the server or have another means of access)

The sshd logging level can be turned up and the logs inspected for the reasons that the sshd gives for closing the connection.

man sshd says

LogLevel
Gives the verbosity level that is used when logging messages from sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended.

Solution 3

If a TCP connection is accepted and immediately closed, it is very likely to have been blocked using tcp_wrappers, and this almost always means denyhosts, which you mentioned in a comment to have installed.

If you can, try connecting from a different address (for example, through a proxy) and check whether you are listed in /etc/hosts.deny. If you are, follow these instructions to remove your address from the half a dozen databases that denyhosts maintains. Optionally, also add your own address to /etc/hosts.allow.

Your webserver continues working because it does not use tcp_wrappers for performance reasons. (Indeed, very few programs actually use it.)

Solution 4

This error could be caused by many things but always indicates a server problem, most of which related to the filesystem or directory permission (which is not that likely if you have not made changes). Maybe your remote server root fs has been remounted readonly, maybe there are disk errors, etc. You should see something in your system error logs. If possible, you should shut it down and have a filesystem check asap. Fixing the filesystem should fix it in most case.

View more solutions

Comments

[user1686]

Do you have denyhosts installed?

[Micromega]

I can't remember the exact name but my webserver works only ssdh is down. I've a defense script to protect my sshd installed.

[Micromega]

What is stale??

[BloodyIron]

You connected to that system previously with putty, and it asked to keep a key for the system. You then regenerated the key pair on the system for SSHD connections. The staleness is that your putty would still have a key, but it's for the previous set. This is all speculation of course, as it may not be the problem.

[Micromega]

Would it help to delete .ssh config file?

[Micromega]

That doesn't work. It's a remote virtual server in some server farm? It's very cheap, too.

[user5249203]

@David, ah - that wasn't clear to me from reading your question (you might consider editing the question to mention that). However some hosting providers have a web-based control panel that provides a "virtual console" for exactly this sort of circumstance - does yours?

[Micromega]

Thank you for the pointer. I think I can restart my server from a web-based control. It seems the only solution.

[BloodyIron]

On the client end yes, as it may contain the stale key. Deleting it on the server end would make things worse.

[Micromega]

It didn't work. It seems the sshd is down. Not good. I cannot connect with cygwin either. Or maybe it's because I run xdebug on the server and it's simply to weak for that stuff? It's a very inexpensive server.

[BloodyIron]

Cygwin? I assume your client is through a Windows environment? Have you tried with PuTTY? I dont know much about xdebug, but X shouldn't be initializing if you're just making a CLI SSH session. If you are using an app to SSH connect then X11 forward, that's a bigger ballgame.

[Micromega]

I don't like putty. I use poderosa but I doesn't work either. What's so special with puTTY?

[BloodyIron]

Nothing is special apart from the fact it is a SSH client you haven't connected with before. It may shed more info that's relevant.

[Micromega]

I've loaded poderosa and it didn't work. Same message. I think it's dead.

[BloodyIron]

If multiple clients you haven't used before don't work, then it's likely on the server end, or a connection problem between you and the server. If you can access other services on that server, such as a web site, then it is with the SSH daemon.

[user1686]

@BloodyIron: FYI, stale keys would cause a large and very visible security warning, from any SSH client. (That's part of the security of SSH.)

[Micromega]

I need to add this ip range to hosts.allow: en.ntunhs.net/IPInfo/EN/78/34.htm. How can I do this? I'm currently using a remote rescue system.

[Micromega]

denyhosts.sourceforge.net/faq.html#3_7