0

I'm trying to ssh to a machine, but it hangs and gets timed out.

$ ssh root@<ip address> -v
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <ip> [<ip address>] port 22.
debug1: connect to address <ip address> port 22: Connection timed out

Ping for the machine is disabled. Also able to ssh to the machine from other computers. Also able to ssh to other machines in the same network, from my machine.

  • 1
    Maybe there's a firewall configured on the remote machine that is specifically blocking your machine, or maybe your machine cannot reach the subnet. Can you SSH/ping other machines on the same subnet of the remote machine? You can test your connectivity by using traceroute -n <AnyipAddressInSubnet> (you might need to install traceroute using sudo apt-get install traceroute). Also, what happens if you telnet <ipAddress> 22 on the remote machine? – Alaa Ali Aug 19 '13 at 5:28
  • 1
    When you do get SSH working, I recommend immediately disabling root SSH logins. If this is a machine where root logins are enabled, that still doesn't require you to enable them remotely. Instead, it's best to SSH in as a non-root user and use su to become root. – Eliah Kagan Aug 19 '13 at 5:34
  • sudo, actually: help.ubuntu.com/community/RootSudo – Marius Gedminas Aug 19 '13 at 5:51
  • 1
    @MariusGedminas Not in this specific scenario. The remote system is probably not even Ubuntu. For a system with the root account enabled, to authenticate as root once logged in as a non-root user, su is used. For Ubuntu, in its default (and recommended) configuration, sudo, but for such an Ubuntu system, a root SSH login would be impossible in the first place (but this would not cause it to fail before any TCP connection is established, which is happening here). – Eliah Kagan Aug 19 '13 at 6:13
0

If you can reach other machines on the same network, then you can use them as a stepping stone to reach this one too. Put the following in your ~/.ssh/config:

Host <yourmachine>
ProxyCommand ssh -q -a -x <othermachineonthatnetwork> nc %h %p

If the machine doesn't have a hostname, you can put its IP address instead of %h in the netcat invocation. Oh, I should mention that othermachineonthatnetwork should have netcat-openbsd installed.

Then I would try to debug the connection from both ends: run tcpdump or wireshark to capture the network traffic on the remote machine while you're trying to ssh directly to its IP address, see if any packets make it through. Try to check firewall configuration. Try services other than SSH.

  • Why would other machines on the network be able to reach a machine that is dropping packets sent to it by the original machine on the same network? Or is the idea that perhaps the client machine in this scenario is not on the same LAN, and that this SSH server has particularly restrictive firewall settings not applicable to other machines on the same network? – Eliah Kagan Aug 19 '13 at 6:15

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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