9

I'm attempting to set up an SSH server on my local machine using OpenSSH. When I try to SSH from a remote host into my local SSH server, the SSH server doesn't respond and the request times out. I'm pretty sure there's a really obvious fix for this that I'm simply overlooking.

Here's what happens when I try to SSH in from a remote host:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

Where robots is my remote host, and 99.3.26.94 is my local SSH server.

SSH Is Running

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

Where arnold is my local SSH server.

Port Forwarding Is Set Up On the Router

I've got my home router set up to forward ports 80 and 22 to my SSH server. Interestingly, port 80 worked without a hitch -- goes straight to the Apache web directory. Port 22 -- not so much.

NMap Says It's Filtered

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Where robots is my remote host, and 99.3.26.94 is my local SSH server.

It's Not IPTables (I think)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

...And I don't have any other firewalls in place -- it's a relatively fresh Debian netinst.

So, then: What else could it be? It certainly appears to be a firewall-y sort of thing to just ignore traffic, but if it's not the router, it's not iptables, and it's not another firewall on the SSH server, ...what the heck else is there??

EDIT: Connection Request from Internal Network Error

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host
  • 1
    Have you tried SSH'ing in from a computer behind the router (internally)? Also, see this. – saiarcot895 Jun 2 '15 at 19:31
  • Thanks for the reference material, @saiarcot895. Also, see edit. – kittykittybangbang Jun 2 '15 at 19:58
  • What it the ip address of the computer that you tried to do the above ^ with? Can you ping it? – datUser Jun 2 '15 at 20:17
  • First of all check if something if not taking the address arping remotehost must answer only one hw address,then check if hwaddress is the same.Then check resolution with dig remotehost and dig -x remoteip,then check if the remote host is not pointing to 127.0.0.1,for this check the /etc/hosts of remote.And finally try to disable firewall,and check if ssh process is running. – elbarna Jun 2 '15 at 20:18
  • It might also help to tail -f whichever log file(s) you have sshd pointed at for output. If there is absolutely nothing in the logs, it is more likely a problem between the two devices, not on the ssh server. – 0xSheepdog Jun 2 '15 at 22:47
16

A Very Disappointing Self-Answer

Having set this problem aside for a day and come back to it, I was both relieved and perturbed (more perturbed than relieved) to find that everything was, mysteriously, working properly.

So, What Was the Issue?

No settings were changed or adjusted -- not on the router, not on the SSH server, and not on the SSH client's machine. It's fairly safe to say it was the router not handling the incoming traffic properly, in spite of proper settings. Given that dinky home router software isn't really designed to deal with port forwarding, it took the poor guy a while to implement the necessary changes.

But It's Been Like 6 Hours!!

Yeah dude, I know. I spent all day trying to figure out what was wrong -- and didn't ever find it because there wasn't anything wrong. Evidently, it can take 6 hours -- possibly more -- for the router settings to take effect.

So How Do I Know If This Is My Issue?

A nifty tool I came across during this escapade is tcpdump. This lean little guy sniffs traffic for you, offering valuable insight into what's actually going on. Plus, he's got some super filtering features that allow you to narrow down exactly what you want to look at/for. For example, the command:

tcpdump -i wlan1 port 22 -n -Q inout

Tells tcpdump to look for traffic via the wlan1 interface (-i = 'interface'), only through port 22, ignore DNS name resolution (-n = 'no name resolution'), and we want to see both incoming and outgoing traffic (-Q accepts in, out, or inout; inout is the default).

By running this command on your SSH server while attempting to connect via a remote machine, it quickly becomes clear where precisely the problem lies. There are, essentially, 3 possibilities:

  1. If you're seeing incoming traffic from the remote machine, but no outgoing traffic from your local server, the problem lies with the server: there's probably a firewall rule that needs to be changed, etc.
  2. If you're seeing both incoming and outgoing, but your remote machine isn't receiving the response, it's most likely the router: it's allowing the incoming traffic, but dropping your outgoing packets.
  3. If there's no traffic at all, that's probably a router issue as well: the remote machine's SYN packets are being ignored and dropped by the router before they even reach your server.

And once you've discovered where the problem lies, a fix is (usually) trivial.

  • 1
    Awesome Sauce for your "Disappointing Answer"! Bonus points for your user name.... I've been going in circles on this for two machines on the same local network! Turns out the Evil Bell Router is crap! It allows me to connect ONCE only. Then later, when I try to reconnect it refuses to route me! I can even SSH the OTHER way just fine. Well at least once. I wonder if that will not work in a few hours too.. – Richard Cooke Jun 11 '18 at 15:46
  • Wow, been pulling my hair for a whole day over this - looks like i've the 'Evil Bell Router' problem as well. @RichardCooke: what was your solution? – John Doe Mar 25 at 22:52
  • @JohnDoe: Replaced router. An Asus model that is on the DD-WRT approved hardware list. Any more shenanigans and I'll install DD-WRT! – Richard Cooke Mar 27 at 2:16
1

I'm running Mint (Ubuntu).

I'd done everything...public key in correct format in authorized_keys, chmodding, chowning, restarting ssh and sshd etc. As has all been documented all over the place.

For me, it was the ufw firewall. The lack of any ssh response at all tipped me to this, yet I could ping no problem both ways on a LAN.

I tested by:

sudo ufw service stop

...and it worked perfectly, i.e. I got a response from an ssh call.

So, start ufw up again:

sudo ufw service start

...and add the rule:

sudo ufw allow openssh

All working fine now.

0

Just for others:

I had to use the -P option in tcpdump instead of -Q

tcpdump -i wlan1 port 22 -n -P inout
  • I'll upvote this if you identify the distro name/version your using. – Richard Cooke Jun 11 '18 at 15:52
0

If you, like me, have enabled UFW (on Linux, Ubuntu in my case), try this:

sudo ufw enable OpenSSH

This will allow OpenSSH in the firewall.

  • I just locked myself out, and I feel extremely stupid. But that was it actually. – martpie Sep 4 '17 at 12:54
0

Most of the time firewall is a culprit. Doservice iptables stop and service ip6tables stop.

If stopping service doesn't work, then do iptable flush.

iptables --flush.

If its a VM then do same in host also

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.