-1

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

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

[root@host ~]# getenforce  
Disabled

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 11.22.33.44 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.

Havri
  • 11
  • 1
  • 7
  • 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
  • what do you mean by "disabled selinux"? There are three modes. What does `getenforce` returns? – Jakuje Sep 13 '15 at 18:08
  • I edited the /etc/sysconfig/selinux file to disable SElinux. I've also edited the post to reflect the SElinux disabling method. – Havri Sep 13 '15 at 18:10
  • 1
    The problem is that you should not be doing any of this at all! – Michael Hampton Sep 13 '15 at 18:11
  • This machine is only for testing different configurations (SSH, firewalld, etc.). I have disabled SElinux just for the moment, to get the hang of the SSH configuration and the new firewalld. I am just trying to change the port for the SSH and that's it. There is no security concern in the environment (private LAN). – Havri Sep 13 '15 at 18:26
  • What does `iptables -n --list` show? There may be other rules that affect the connection, or perhaps whatever the `public` zone is does not apply for some reason... – thrig Sep 13 '15 at 19:08
  • I put only the port part from the iptables -n --list: `iptables -n --list | grep 7890 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7890 ctstate NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7890 ctstate NEW` Let me know if you need the whole output. – Havri Sep 13 '15 at 19:21
  • you should add output of: * on server host `iptables -nL INPUT` from the start to your accept ssh connection rule. * On client host - `iptables -nL OUPUT` * Check if there're any firewall devices is located between client and server. * I think, the best option is add rule like: on server: `iptables -I INPUT -s -J ACCEPT` on client : `iptables -I OUTPUT -d -J ACCEPT` – BaZZiliO Sep 13 '15 at 19:53
  • I ran the iptables command you gave me with the appropriate IP, but it didn't work. I should mention again that if I put the default 22 SSH port, everything works (from all other machines), regardless of the clients' IP address. Should other files be edited as well if I want to change the SSH port, other than ssh.xml and sshd_config? – Havri Sep 13 '15 at 20:14

2 Answers2

1

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.

drew
  • 163
  • 1
  • 6
  • 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
1

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.

Regards.

Havri
  • 11
  • 1
  • 7