Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having trouble getting SSH to work. I am using a non-standard port (9876). I verified my server's IP address both by using an external whatismyip type site, and by using curl, both give the same result.

If I do this from the server:

ssh -p 9876 localhost

it works.

If I do this:

ssh -p 9876

it also works.

But, if I do this:

ssh -p 9876

I get the error "Connection refused". (Note that the example ip given above is changed from the real address.) If I try to connect from a remote machine on a different network I get the error "network is unreachable", even though I can ping it from the same remote machine.

The only reason I can think for this behavior is that COMCAST is looking inside the packet, seeing that it is an inbound SSH attempt and then automatically impersonating a server refusing the request. Is this what is happening? Are there alternative explanations?

Additional Notes

Note that I can ping the address in question, so if I can ping it, then it is "reachable" right? How is it, that it is reachable to ping and not to ssh or telnet?

share|improve this question
If you are attempting to connect to yourself using your public ip address that isn't going to work unless you forward traffic on that port to your local intranet address. I can assure you Comcast isn't blocking your traffic. – Ramhound Sep 19 '13 at 11:53
Why would this not work? If I try the command from a different machine on a different public network I get the response "network is unreachable". – Tyler Durden Sep 19 '13 at 14:04
Sounds like you have not forward the traffic on the port to the server as to why that's how your NAT is currently setup – Ramhound Sep 19 '13 at 14:09
Ok, so that would mean COMCAST is blocking me, and they must be looking inside the packet, otherwise how would they know it is SSH traffic and not HTTP traffic (which I receive fine on the server machine). – Tyler Durden Sep 19 '13 at 14:13
Comcast isn't not blocking the traffic the http traffic is on another port which is likely being forwarded to your server – Ramhound Sep 19 '13 at 14:21
up vote 2 down vote accepted

Although there are rumors of COMCAST blocking inbound connections by "stateful packet inspection" I found that I was able to connect my machine from outside and that originally I was being blocked by my router which I thought was bridge, but actually was running a NAT. For the benefit of people who may have similar problems details below...

My situation was that I had plugged the connection from the cable modem into an Airport Express which was acting as a hub for the connection to the Linux box running the SSH server. I had thought that the Airport was in bridge mode (ie passing all traffic through), but actually it was in NAT mode which blocks all inbound traffic.

To solve the problem I made an exception on the Airport. First I had to make a dedicated DHCP filter for the server which hardcodes the server's MAC address to an internal IP address of my choosing, then I had to open port 9876 (the port I am using for SSH) on the NAT and point it to the IP address I picked for the server. After that it worked.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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