4

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 (111.111.111.11) 56(84) bytes of data.
From localhost (222.222.222.22) icmp_seq=1 Destination Host Unreachable

Is there a way to remotely access my computer?

Improve this question
4
  • 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.
    – theTuxRacer
    Apr 16, 2011 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, 2011 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.
    – theTuxRacer
    Apr 16, 2011 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, 2011 at 5:48

3 Answers 3

Reset to default
5

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.

Improve this answer
5
  • 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, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 8:58
1

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.

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .