Red Hat Bugzilla – Bug 437811
sshd defaults "on" on default installation ( also in previous releases )
Last modified: 2013-01-09 23:36:43 EST
Description of problem:
sshd defaults to on ( SSH server running why??? )
and on top of that the sshd
port defaults to open ( hased in s-c-f ) so if
noob users gets himself a copy of Fedora installs it
by pressing NEXT NEXT NEXT etc done and *NEXT* through firstboot
he's vulnerable to bruteforce attacks.
Version-Release number of selected component (if applicable):
This has been going on for some releases..
Sit down with somebody who has no understanding of computers
and make them install Fedora... Without intervention
Or just next/ok/done your self through the installation like any
noob user would do...
Steps to Reproduce:
sshd is running...
and s-c-f leaves the sshd port open (port 22 )
sshd should not be running...
and s-c-f should have port sshd unhashed..
I guess there must be some good reason for this.
From my perspective this is an security risk
and fails QA for enduser...
Please read the discussion in bug 136289 and bug 147557
But system-config-firewall should not leave the port open by default. That seems
to be a regression.
anaconda is telling lokkit (system-config-firewall) to open the port in
firewall.py. anaconda should not open services or ports by default.
BTW: anaconda is not using the service option of lokkit.
Reassigning to anaconda.
Let me just point this out before I get the some *words of wisdom* from some
of those persons that commented on the bug 136289 and bug 147557 bugs.
Today we have the tools to make a "headless respin" !!!!
The fact that tools exist to allow people to respin doesn't mean that we should
be trying to push lots of users in that direction. Especially as that then
requires them to have another Fedora machine available to do the build on.
Also, with the rise of virtualization, there are even more cases where you want
to have ssh available rather than depending on the fact that there's a console.
Sorry Jeremy need to go head on head with you on this one.
Have asked Fedora QA board to take this to issue up on next meeting
with input from Fedora-Security team.
Then after this has received a proper discussion
a QA board member can close this with good explanation why
or this can be fixed..
sshd in many cases should default to on. Anyone doing servers will want it this
way. Home users on the other hand may not want sshd running as they prefer to
get rooted via avahi or samba or that web server they left on by accident. For
anyone that wants sshd running, there is a fair amount of configuring that you
must do before you leave it alone: disable protocol 1, setup login group, add
login accounts to that group, create an allowgroups entry in sshd.conf, setup
tcp_wrappers, setup iptables, setup the pam stack, turn off ipv6, etc.
We are looking to address this complexity with some lockdown tools in the F10
time frame. I think we could do a couple things to make the current situation
better, but I don't think it should be disabled by default.
Actually, protocol 1 has been shut off by default since Feb of 2008.
What ever the user turns on after he has been delivered a secure product
is not our responsibility, but it is our responsability when we deliver
unsecured product to the end user in the first place.
And yes if only sshd was disabled and the end user had to go through
the steps you mentioned to enable it or simple we would not ship sshd by default
and the user who is actually gonna use it would simple have to select it in the
package selection in anaconda and install not a rocket science is it but no
nobody can touch sshd.
Is this lockdown yet another step to M$ way of doing things..
Selinux + policykit == bad, selinux + policykit + yet another lockdown == Worse