Description of problem: For example, if input "1023" for ssh port, after configured, try login rhevh via ssh: [root@agent2 ovirt-node]# ssh admin.73.241 -p 1023 ssh: connect to host 10.66.73.241 port 1023: Connection refused so we need add validator for ssh port to only accpet "22" or "1024-65535" Version-Release number of selected component (if applicable): ovirt-node-iso-3.5.0.ovirt35.20140707.el6.iso How reproducible: 100% Steps to Reproduce: Actual results: Expected results: Additional info:
What is the cause? Why can't ssh connect to sshd on port 1023?
This is cause because we must setup ssh_port_t type before restarting sshd. # semanage port -a -t ssh_port_t -p tcp 1023 <configure ssh to new port> # restart ssh daemon After that, we are ok. I am preparing a patch for this. Anyway, haiyang thanks for your efforts. Please let me know your thoughts.
Port 1023 is reserved for future use, are you prepared to change your port when iana assigns this port to something else? https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
Hi Sven, (In reply to Sven Kieske from comment #3) > Port 1023 is reserved for future use, are you prepared to change your > port when iana assigns this port to something else? > > https://www.iana.org/assignments/service-names-port-numbers/service-names- > port-numbers.txt Agreed but I do believe haiyang,dong used as example for low ports, he could be used let's say '30' port.
Yes, but I don't understand your reasoning at all. Fabian asked: Why can't ssh connect to sshd on port 1023? You gave an technical answer to an organizational problem: Yes you can't connect to ssh on this port because you need a proper selinux rule first. But even with this selinux rule you _must_ _not_ connect to this port, because these ports are reserved by iana. Thus haiyang,dong came up with the solution already: so we need add validator for ssh port to only accpet "22" or "1024-65535" (and add the correct selinux configuration for the given port).
Hey, thanks for the vivid input everybody. My thoughts actually addressing this bug: 1. Are firewall rules permitting the access? 2. Is selinux permitting the access? 3. Is the port used otherwise? A more high level questions, what ports we want to allow. Initially I thought that we should leave it to the administrator to choose any port he wants. But now I believe that Sven has a point, and that we should not allow to bind to privileged ports. This is what the patch currently addresses. Besides that the other points (1-3) should also be checked when the user enters a port. Please consider this in the patch as well.
(In reply to Fabian Deutsch from comment #6) > Hey, thanks for the vivid input everybody. > > My thoughts actually addressing this bug: > 1. Are firewall rules permitting the access? > 2. Is selinux permitting the access? > 3. Is the port used otherwise? > > A more high level questions, what ports we want to allow. Initially I > thought that we should leave it to the administrator to choose any port he > wants. > But now I believe that Sven has a point, and that we should not allow to > bind to privileged ports. > > This is what the patch currently addresses. Initially I thought as you Fabian that's why I was about to address in different approach. However, let's start with haiyang's suggestion and if users start requesting low ports we create a new discussion. > > Besides that the other points (1-3) should also be checked when the user > enters a port. Please consider this in the patch as well. Agreed. I am going to review the suggestion.
This is a mass change, moving bugs of merged patches into MODIFIED. Please correct the state, if you think that the move was not justified.
Moving pending bugs not fixed in 3.5.0 to 3.5.1.
oVirt 3.5.1 has been released, re-targeting to 3.6.0 as not marked as urgent / high severity or priority
(In reply to Sven Kieske from comment #3) > Port 1023 is reserved for future use, are you prepared to change your > port when iana assigns this port to something else? > > https://www.iana.org/assignments/service-names-port-numbers/service-names- > port-numbers.txt Also port 1027 is reserved for future use. Not sure why should there be a difference. Although there are different processes for registering ports in the various relevant ranges, they can still be reserved. We should not stop users choosing whatever ports they feel like. We should recommend and default to assigned ports. Just the same way as any other sane service, such as common web/mail servers.
I agree with comment 11. Closing thereof.