Nonstandard ssh port Connection Refused
 

Hello everyone, this is my first post and I thought I would request help with a problem I have been struggling with for a few days now. I am trying to change my ssh port from the standard 22 to a new four digit number (lets say xxxx) but when I try to connect remotely I receive
If i use the standard port 22 remotely I am able to connect as expected.

What I've Tried

After I change the port in my /etc/ssh/sshd_config and restart the ssh service, I make sure the logs say
I forward the port on my router (R7000)
my iptables are flushed
ufw allow port xxxx

I have tried multiple ports making sure they are above 1025

Inside my local network I can connect to other computers using ssh -p xxxx ... but when I try it remotely I still get connection refused.

Could this be my router(or me) not forwarding ports correctly? I feel as if it should be an easy solution that I just am not finding. Also, I am using linux mint if it helps.

Thanks for any help in advance guys!

If you are running selinux (a good idea for anything attached to the net) then you need to tell it about the new port.

You might also have to create firewall rule to allow the new port number

Thanks for the replies. As for SELinux, I had actually never heard of it before so I will look into that for future use. Thanks for the tip.As for firewall, my iptables rules are flushed and I have already allowed the port for ufw (I believe those are the only two firewalls that mint comes with). I did initially think it was the firewall though and so does anyone know if there is an additional command after

So you can connect to the server using your new port from inside your local network, but not from outside?

I'm confused by your statement:
Did you mean to say you can connect FROM other computers? If so, then the problem is clearly in your router config. Many routers need to have port forwarding set up in two places. Once in the port forwarding rules, and also in the firewall rules to even allow the connection to begin with.

This is probably a silly question but which external port number are you forwarding to which internal port number? If your router has an option to forward the SSH port to an internal port that will not work as it will be forwarding external port 22 to internal port 2222 (for example) rather than forwarding external port 2222 to external port 2222 instead.
[2222 used as your new SSH port]

Ya sorry, I did mean to say that I could connect from other computers in my local network. I will look more into my router setting then. And sorry for being confusing before, I am not always the best writer.
As for my external and internal port numbers, they are both set to the same thing. As in external is 2222 and the internal is 2222.

I thought that would be the case but mentioned it as these things are easy to forget or overlook.

Are you testing from within your own network? I have seen routers that allowed port forwarding but only for connections that are *really* coming from the outside. The only way I found to actually test that it works was going online via a umts connection over my mobile and then trying to connect.

Some other thoughts: Are you sure that you are using the right target ip? You can use http://www.whatismyip.com/ to check.

Are you sure that you are forwarding the port to the right machine in your lan? You may want to use a static IP for that machine, just to be 100% sure.

You could run a nmap scan:

Where the ip-address must be the public one(!)

If your router is forwarding the port correctly you should see it open, the output on mine looks like this:
Note that you may have to install nmap beforehand, it's in the repositories of most distros.

Thanks joe_2000 for all the suggestions. I reconfirmed my ip and used nmap to scan the port again and it says 'xxxx/tcp open'. As for trying this behind my router, I technically am. I am however sshing from laptop in my local building to another computer in another building and then trying to ssh back in to the desktop computer that I am having the problem with. Does the network still consider this local? I imagined it as the network seeing it as a new external connection that is to be directed to the desktop. I will use your suggestion of mobile to test it though, if it works I will write back claiming my ignorance.

Unfortunately that did not work, I will continue searching around. Sorry for being so difficult.

That's fine. The problem would be if you were ssh'ing to your own public IP from within your network (without stopping off at a 3rd party machine first). Some routers are fine with this, some block it.

Hmm, weird. Some more thoughts:
Can you confirm there are no ip conflicts within your local network? (Maybe your router shows you which machines are connected in its interface?)
Have you tried the part of using a static ip?
Have you tried doing this with another computer (to potentially rule out the router as the source of the issue)? If you cannot do it with another computer maybe you can at least run a live system on the target machine.
Just for me to understand the situation better: Can you confirm that the router forwards port 22 correctly? (I am not sure about the wording in your initial post)

You mentioned allowing a port in ufw, but that your iptables were flushed. This sounds a bit conflicting to me. I have not used ufw, but could it be that it does something you aren't aware of (like filtering source ips)? Can you deactivate it completley, run iptables -F and try again?
Are you running other smart tools such as denyhosts or similar?

Another possibility to test whether the router is forwarding the port correctly: Install a webserver (e.g. apache), run it on a non-default port, and see if you can open the default page in a browser by putting your public ip in the address bar. (Obviously after having forwarded that port) If you use apache it should say something like "It works!".

Wow sorry about this guys but I decided to try it from another remote location and it turns out it works. The problem is the other connection I was sshing through to be able to connect from the outside connection. It apparently has limits on where it can connect and refuses connection if it's not on the white list, so that was the problem the whole time. I was not the one who set up the other connection and I had never had a problem with any other locations so I didn't think to doubt it. Sorry for wasting time and thanks for attempting to help me through my ignorance. I will marked this as solved just in case anyone else is as dumb as I am.

No need to apologize, no damage done :-)

It would be interesting though to understand the issue better so as to learn from it. The part I don't understand is why your test through a cell phone connection failed... Did you still have the remote connection on the connection past in that test? I.e.
?

That would indeed explain. But if you did it should work, shouldn't it?