Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 1 down vote favorite
1

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.

share|improve this question
Do you have denyhosts installed? – grawity Apr 30 '12 at 21:10
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. – phpdna Apr 30 '12 at 21:11
@grawity: I've denyhosts on my server. Can it be the problem? I'm still unable to access my sshd. – phpdna May 1 '12 at 10:51

4 Answers

up vote 0 down vote accepted

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.

share|improve this answer
What is stale?? – phpdna Apr 30 '12 at 19:44
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. – BloodyIron Apr 30 '12 at 19:59
Would it help to delete .ssh config file? – phpdna Apr 30 '12 at 20:01
On the client end yes, as it may contain the stale key. Deleting it on the server end would make things worse. – BloodyIron Apr 30 '12 at 20:27
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. – phpdna Apr 30 '12 at 20:28
show 6 more comments
up vote 1 down vote

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.)

share|improve this answer
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. – phpdna May 1 '12 at 12:53
up vote 1 down vote

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.

share|improve this answer
That doesn't work. It's a remote virtual server in some server farm? It's very cheap, too. – phpdna Apr 30 '12 at 20:13
@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? – RedGrittyBrick Apr 30 '12 at 20:16
Thank you for the pointer. I think I can restart my server from a web-based control. It seems the only solution. – phpdna Apr 30 '12 at 20:22
up vote 1 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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