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: NetStat Server Output
From the SSH Server:
tcp6 0 0 :::22 :::* LISTEN 5784/sshd
Best Answer
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: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
acceptsin
,out
, orinout
;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:
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.