Server Fault is a question and answer site for system and network administrators. 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

When I try to set my SSH port to something other than 22 (editing /etc/sysconfig/iptables and /etc/ssh/sshd_config) I end up locked out of my server and having to boot into rescue mode to rectify the problem.

I've gone through this cycle a few times now, each time being more careful that I'm doing the right things.

Is it possible that my new port (33933 in this case) is somehow being blocked somewhere else - or there's another file referencing 22 that I need to change?

This is on CentOS 6 on a brand new dedicated box that I've just set up from (an reseller).

share|improve this question
Is SELinux active? (sestatus -v) – dawud May 2 '14 at 10:52
Could you paste the output of iptables -L -n -v into your question? – MadHatter May 2 '14 at 11:21
So I did some googling, and one of the things that cropped up is that it's not recommended to set SSH to a port > 1024. I tried the whole thing again with a port in that lower range, and it worked straight off. Could it be that the hosting company knows SSH > 1024 is a bad idea and hence block it? Seems unlikely. Either way, my problem is fixed now, and I'm happy to be ignorant about why 33933 wasn't working - too much else to do. – Codemonkey May 2 '14 at 14:26
up vote 8 down vote accepted

You can set ssh to multiple ports. Just had multiple Port lines, eg

    Port 22
    Port 1500

That way you can can port 22 still working while you troubleshoot port 33933.

Next after you changed your config and restart ssh (you can restart ssh with an active connection), would be to test the server is listening on that port.

    netstat -ltnp

Post the output of that.

share|improve this answer
Great tip, I had no idea you could specify multiple ports - I'll certainly be doing that in future. – Codemonkey May 2 '14 at 14:24

I would guess that with CentOS it's SELinux blocking your connection. Try

selinux port -l | grep ssh

and see that probably only port 22 is allowed.

semanage port -a -t ssh_port_t -p tcp 39333

would add port 39333 to allowed ports for ssh. Verify with

semanage port -l | grep ssh

and you should be all set.

share|improve this answer
SELinux is disabled, good thought though. – Codemonkey May 2 '14 at 14:23

First question is, did you actually load the new configurations after you edited the files?

I would recommend setting up iptables to allow incoming connections on both ports as the first step. Secondly you can test an update to sshd without breaking your current ssh connection. If you type service sshd reload, you should be able to verify that you are able to start a new ssh connection, while keeping the old one alive, such that you can still revert your changes, if they do not work.

If you have inetd or xinetd installed on the server, you can use that to configure a secondary sshd port which operates independently from the primary. Here is an example of how that could look in xinetd:

service second-ssh
    type            = UNLISTED
    flags           = REUSE
    socket_type     = stream
    protocol        = tcp
    port            = 64739
    wait            = no
    user            = root
    disable         = no
    server          = /usr/sbin/sshd
    server_args     = -i

To find out if the other port is blocked somewhere on the network, you can use tcpdump on each end of the connection to see if the SYN packet is sent by one end and if it is received by the other end. If it turns out to be blocked, you can use traceroute to find out, where it is blocked: traceroute -n -T -p 33933

share|improve this answer

After editing those files, you need to restart both services in order to apply the new configuration.

Just run service sshd restart && service iptables restart and you should be able to access.

share|improve this answer
I had tried both that and rebooting, neither was helping. – Codemonkey May 2 '14 at 14:20

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.