I'm having some trouble changing the ports on a new CentOS 7 (minimal) machine (IP To log into the new machine, I use a proxy VPS (let's say, IP

I edited the /etc/sysconfig/selinux file to disable SElinux and rebooted.

[root@host ~]# getenforce  

After I disable selinux and restart the machine, I edit the /etc/ssh/sshd_config and change the Port entry from 22 to let's say 7890 (just an example) + systemctl restart sshd.

Then I copy the default ssh xml configuration file for firewalld from /usr/lib/firewalld/services/ssh.xml to /etc/firewalld/services/ssh.xml and change the port from 22 to 7890 + firewall-cmd reload.

I also make the change permanent in firewalld:

firewall-cmd --zone=public --add-port=7890/tcp --permanent

The problem comes when I try to log through SSH to the new CentOS 7 machine from a different VPS. The login from the initial VPS still works after the changes are made to the port number, but no new machines can connect to the CentOS 7 machine.

The error that I'm getting is:

ssh: connect to host port 7890: Connection timed out

This is the output from my ss -ntulp:

tcp   LISTEN     0      128      *:7890          *:*      users:(("sshd",5566,3))

The thing is that if I change the SSH port back to the default 22 value, then every machine can connect to it without any problems (after I edit the two files ssh.xml and sshd_config to the default 22 port).

There must be something that I'm missing or doing wrong. Can someone point me in the right direction?

Thank you.

  • 3888 and 7890 are not the same port! – Michael Hampton Sep 13 '15 at 17:47
  • Sorry, I edited to reflect the same ports. Was a bad on my typing. – Havri Sep 13 '15 at 17:50
  • 3
    Plus, there is no good reason to change the ssh port number anyway. You don't gain anything in security, and in fact you have already lost a significant amount of security (by disabling SELinux)! – Michael Hampton Sep 13 '15 at 17:51
  • I haven't had the chance to work much with SElinux yet, but I don't think that that's my problem here. Appreciate your concern, though. :) – Havri Sep 13 '15 at 17:59
  • 1
    The problem is that you should not be doing any of this at all! – Michael Hampton Sep 13 '15 at 18:11

Sounds like even though you've said that you've disabled SELinux, you probably haven't. Editing /etc/sysconfig/selinux by itself isn't enough to disable it, you'd need reboot for it to take effect (or issue setenforce 0).

Anyways, if that's true then SELinux is blocking a non-standard SSH port (7890) from accepting connections. To enable it, you'd have to relabel the port as so:

semanage port -a -t ssh_port_t -p tcp 7890

Following that, your SSH connectivity will probably work as intended.

Consider what some of the people saying "why are you doing this?" are saying - using a non-standard SSH port is security through obscurity at best. Ensure you harden the service even further once you get it working.

  • I edited the post to reflect that I did reboot the machine after I disabled SElinux from /etc/sysconfig/selinux file. Getenforce returns Disabled. – Havri Sep 13 '15 at 20:16
  • Also, it is indeed a temporary security through obscurity, just until this problem is solved. – Havri Sep 13 '15 at 20:57

It seems that I have found something in the CSF + LFD, as all our machines that couldn't connect are using them. The adding of additional IPs and ports to the allow rules on the SSH client wouldn't have helped (tried it already - still couldn't connect), as suggested by @BaZZiliO in the comments. A restart of lfd + csf allowed me to connect immediately:

 service lfd restart  
 csf -r

The reason why I didn't think of disabling or restarting the firewall on the SSH client was that it was initially functioning properly, so I thought that it was a configuration issue.

As for the CentOS 7 configurations written in the question, they are correct and function properly, so they are good for cofiguration testing purposes (not recommended in production environments without further security configurations).

Thank you all for your help and I hope that someone will benefit from this discussion.


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.