I have restarted my system remotely, but now when I try to ssh, I get the message

ssh: connect to host desktop.hostname port 22: Connection timed out

And when I try to ping it:

PING desktop.hostname ( 56(84) bytes of data.
From localhost ( icmp_seq=1 Destination Host Unreachable

Is there a way to remotely access my computer?

  • 1
    Since it cannot be pinged, and sshed, I am assuming that the PC hasnt been restarted yet, or there is some network trouble. If you have a monitoring panel, like cPanel or use Amazon Webservices, I recommend that you restart the machine again. I sometimes face the same problem after restarting or deploying new servers, and usually have to restart or wait for a few minutes before trying again. Apr 16 '11 at 5:06
  • Agree with @kaustubh -- unless you have reason to believe pings are being blocked, being unable to ping usually indicates you don't have minimal network connectivity. And without that, of course, no applications that rely on network connectivity (e.g., ssh) will work.
    – belacqua
    Apr 16 '11 at 5:25
  • @jgbelacqua Just because we are on the topics, pinging is not a reliable method of establishing that a computer is up, because my servers don't respond to pings. Apr 16 '11 at 5:37
  • @kaustubh "Unless you have reason to believe pings are being blocked" I know it isn't reliable in a blackbox scenario, but if you're the admin, and you allow it as a troubleshooting tool, then you know failure usually means a loss of net connectivity. The network group I'm in has policies either allowing things like icmp, CDP, LLDP, etc., or not, but as long as you either control the environment or know the expected behavior, you know what tests should work. There are pros and cons, but ping can be a nice initial check before doing validation and real troubleshooting.
    – belacqua
    Apr 16 '11 at 5:48

By default, connection to network go up when the user login. So, if you have not configured your machine to login automatically, your network connection is down.

The solution is to set the connection as a "system connection" in network manager: in this way the connection go up when the machine boot up, and do not wait for a user to login.

  • 1
    That is NOT correct, for a remote SSH connection. What you have said is valid, but ONLY for a VNC (or similar) remote desktop connection.
    – david6
    Dec 2 '11 at 1:21
  • @david6: that was CORRECT for 10.04, that the answer was referring to; and this has absolutely nothing to do with ssh or vnc
    – enzotib
    Dec 2 '11 at 6:48
  • I have four servers, all with 10.04 LTS, and I can ssh to them without anyone logging in first.
    – david6
    Dec 2 '11 at 8:24
  • @david6: on ubuntu desktop the connection, managed by Network Manager, was set by default as NON-system connection, so that it started when the user login. The OP acceted my answer, so it means that it was exactly in this situation.
    – enzotib
    Dec 2 '11 at 8:37
  • 2
    Sorry, I don't follow.. I have several desktop PCs, all on 10.04, for a science monitoring project. They are unmanned, and spread over several countries. I am able to monitor, restart, and update them all over SSH.
    – david6
    Dec 2 '11 at 8:58

Unfortunately a remote Linux server may not always re-start correctly, and will then require human intervention (on site).

This can sometimes be resolved using out-of-band equipment, which supports power-cycling (on, off) and/or a serial console connection.


Possible failures:

  1. SSH daemon is not running because it is not a service marked to run at startup. In which case you'll need to start the ssh daemon and then also mark it as a service to run at startup next time. There are some interesting methods to use php or other web services to attempt to start ssh remotely, but they are complex and depend a great deal on there being existing security violations. LOL

  2. Networking is down. Unfortunately, that must be resolved at the server as well.

  3. Firewall is blocking you. Also must be resolved at the server.

  4. SSH is now (somehow) listening on the wrong port. Not likely, but not to be overlooked as a possibility.

  5. And the remote possibility that the server is actually off or failed boot. If this was the server's first reboot after or during an install, however, this is a measurable percentage.

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.