> > > Ah, SELinux again... Kinda' defeats the purpose these days, doesn't it? > > > No it's doing exactly what it should be doing ... in a 'normal' usercase there's no need for SSH to be on a port other than TCP/22 and this prevents it ... if you need it on another port it's trivial to add on the new port with semanage to the rules...
But it's not a good idea to move SSH to a port over 1024 since it leaves you in a potentially vulnerable state in terms of attack surface. This is a key networking daemon that all credentials, data and commands goes over - as such it's ripe for use in a man in the middle attack to gain more information about a system. Only root can bind below 1024 so if SSH (or indeed other services too) have bound to a low port then it must have started life as a root owned process... an unprivileged user cannot bind to these ports at all. If you configure SSH to bind to a port over 1024 then an attacker who achieves unprivileged access to the box (either an attack on a shell account or via another exploitable service such as httpd/php/etc) can use methods to force the process to crash and then bind their own process to that port to man in the middle login details, session information (such as root password) and so on ... If you want SSH on a different port the better options are to pick a port below 1024 (and add that port to the sshd_t context via semanage) or to bind SSH to 22 and to use iptables to do a redirection internally from the high level port you want to the 22 that it is really listening on ... that way an unprivileged process/user cannot impersonate your SSH daemon and externally it's still visible on whichever port you prefer.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
