Today we decided that the best course of action for our Ubuntu Server (VPS) would be to restore a back-up after too many settings had be changed to our Geoserver instance. However, after restoring the back-up and rebooting, I am no longer able to login to the server by normal means via SSH. It simply gives me a "connection timed out" error.

What I have done:

  • Used the "Rescue System" to login to the Server via SSH (worked).
  • Checked the sshd_config file and init.d/ssh for anything out of the ordinary.
  • Checked the auth log to see if it even noticed my SSH connection attempt (which it did not).

I am completely stumped on this case. To me, it just seems like the network doesn't go up at all after a reboot. However, I am unable to directly connect to the server as it is a Virtual Private Server hosted remotely.

I've searched a bit around the web, but nobody seems to get the "Connection timed out" error which is happening to me right now.

The server runs on Ubuntu 14.04

Any suggestions?

Additional note: I can only connect to the server when it is in Emergency Mode, which means it skips everything I did on the server and puts it in a /repair directory. So if I, for example, check which ports are open, it will tell me the ports that are open from the Emergency Mode, not from my own installation.

Additional info from comments:

iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

  • 4
    Smells like botched firewall settings (or routing table) to me. – a CVn May 18 '15 at 14:06
  • Can you add a script that will be run when you reboot it into "normal" mode? If so, make one that will print routing table, network interface config and firewall settings to a file. Then boot the server once into normal mode, and then back into rescue mode. Compare the rescue mode settings to the ones stored in the file. – Jenny D May 19 '15 at 8:13
  • Actually, since your normal configuration is in the /repair directory, you should be able to look at the config files there and compare them to the config in your rescue mode. (I'm fairly sure that @MichaelKjörling's diagnosis is correct; look at routing and firewall.) – Jenny D May 19 '15 at 8:41
  • Does the server even finish booting? Maybe it gets stuck on one of the init scripts and never get to the point where networking is enabled. – kasperd May 19 '15 at 9:16
  • @kasperd Good point. This should also be checkable by looking at the logs, which should be available even in emergency mode. – Jenny D May 19 '15 at 12:04

check if the server is able to ping its default gateway check if the ping works to server from outside if ping works , then do a tcpdump on the interface to check if the NIC on the server is receiving any traffic try ssh from with in the server -- ssh localhost #if this does not work - sshd itself might be broken

  • I can ping from and to the server just fine when it is in emergency (repair) mode, but that's because it skips every configuration I've ever done on the server and runs on only the necessary files to run. – Bahumut5 May 19 '15 at 7:17

Check if ssh service is running and is ssh port is listening

netstat -ntap

You should see one line with port 22 listening for process sshd:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0        *                   LISTEN      pid number/sshd

If the process is active and listening check network setting, if is not active chek if sshd is installed and running

  • Although I appreciate your comment, this is not something that will work for my situation. The server has placed all my configurations in a /repair directory and runs solely on the required files to connect (so yes, SSH is active and running). – Bahumut5 May 19 '15 at 7:14
  • 1
    If they get "connection timeout", the issue cannot be that SSHD isn't running. If SSHD isn't running, the error message will be "connection refused", not "connection timed out". – Jenny D May 19 '15 at 8:14
  • Your note is correct. AFAIK Ubuntu 14 doesn't have a default iptales configuration that drop port 22. Please, if possible post the result of iptables -L (run as root or use sudo) – Alessandro Carini May 19 '15 at 8:26
  • iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Please note though, that this is done in EMERGENCY MODE (Strato VPS) and thus does not necessarily include how the normal configuration works. – Bahumut5 May 19 '15 at 8:32
  • @Bahumut5 As you say, any information from the emergency mode is not very useful in figuring out what goes wrong in normal mode. IMHO, your continuing to get data from emergency mode is a waste of time - you need to get the information from normal mode in some fashion. – Jenny D May 19 '15 at 8:40

First: Thank you all for your help regarding this issue.

Second: Due to circumstances, we were no longer able to wait and decided to reload a different back-up, which seemed to work. We were unable to determine what exactly caused the error due to the new back-up that worked didn't have any differences with the one that failed and we thus consider it to be a faulty back-up problem.

Thanks again for the help though, really appreciated.


try this command.

update-rc.d -f ssh enable 2 3 4 5

Could try doing an nmap of the server to see what ports are open on the network. You should see port 22 open.

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.