From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: Red Hat ships a SSH configuration where the root user is allowed to directly login using SSH. For the sake of security it would be better to disable this functionality. If necessary, a normal user can always become root by using su, and having two logins decreases the chance of letting a cracker become root. The following lines in the file "/etc/ssh/sshd_config" should be changed : < #PermitRootLogin yes --- > PermitRootLogin no Version-Release number of selected component (if applicable): openssh-3.5p1-6 How reproducible: Always Steps to Reproduce: 1. "# ssh 10.0.0.1" (10.0.0.1 is running RH Linux 9) 2. <entering root password> 3. Actual Results: User root logged in on 10.0.0.1 Expected Results: Root login using ssh should be disabled. Additional info: Red Hat Linux release 9 (Shrike) openssh-askpass-3.5p1-6 openssh-clients-3.5p1-6 openssh-askpass-gnome-3.5p1-6 openssh-3.5p1-6 openssh-server-3.5p1-6
I'm trying to understand the logic in this request. If I allow my root password to become compromised, then my machine would be automatically vulnerable to all kinds of nasty attacks. The root password should be the most advanced and complicated password one would ever hope to create for a login to a machine (usually, system administrators would hope that all their users would treat their account and password with a little more dignity). If there is one thing about the root password - is that is should be considered the Holy Grail and not available to public consumption. If no one knows the root password, how could they possibly compromise the machine by attempting to login as root via ssh? Since ssh does not exchange nor pass your password or authentication keys as plain text, what compromise is there?
I agree with you that a root password should be uncrackable; should consist of a mixture of upper- and lowercase characters, numbers, special characters and only be known to the system administrator of the machine. But the reality is different. There are a lot of curious home-users with Cable-modem or ADSL installing Red Hat Linux and SSH is enabled by default on Red Hat Linux and I'm sure that there are some people between these thousands of users with a password that can be guessed by somebody else.
I don't think Red Hat should feel responsibility for "TPEBTCATK" (the problem exists between the chair and the keyboard). Since this is an RFE... Component == Anaconda Severity == enhancement Upon initial installation of Red Hat Linux 9.x (10 .. N), Anaconda should prompt the user to enter the root password. A dialog box could pop up informing the user that if the root password were too easy to guess, the machine could be compromised from external attacks. The dialog box would ask if the user wished to allow logins from root only at the console _or_ from the console and secure shell. Disabling root logins from secure shell by default is a bad idea to the under-informed (remember the /etc/securetty debacle - "I can't login to my machine via telnet.").
Just to put in my $0.02USD: The problem is that everyone "knows" that there is a root account and that by default it can log in. This leaves the system (which by default never disables an account for failed login attempts) vulnerable to an admittedly slow brute-force attempt against a known account. I would instead suggesst that the default configuration for Red Hat Linux be a disabled root login. As for AS, I'm not sure. That brings up the question of the wisdom of disabling root logins on a box that will most likely be in a lights-out environment. I can't count the number of times that I have had to log in as root due to NFS or load problems that rendered all other users (at least nearly) impossible to log in as... then again one hopes that in such environments you have some sort of console (serial or otherwise) access. I'll let other debate the trade-offs there, but I think for RHL it's a pretty clear choice.
Telnet servers by default do not allow root login (including the RedHat configuration). Traditionally the reasons for this have been (as I recall): 1) It makes it twice as many passwords to break 2) Who becomes root (using su) is logged. So you can find out which user account was broken into first (and torture them :) ). I think it should at least be consistent between telnet and SSH. As someone who is a PEBKAC from time to time myself, I'm glad RH is shipped as secure as possible.
David, As far as #2 goes, if I were a hacker and obtained the root password to your box, I would certainly modify, if no delete the log files behind me showing how I got in. ;) As far as root access on SSH. Toss up, it's disable-able, but it's also a nice feature to have when the console is a ways away and something goes wrong in a NIS'd environment and there is NO local true-user account on the machines, nor would there ever be. Since SSH is encrypted, unlike telnet which is cleartext, I would consider the threat pretty low.
I agree that this is security through obscurity. There is no real security benefit from disabling this option, and will only lead to people complaining that it's been changed.
There is only within a hair of more security if you use arbitrary user account and su with the root ssh login disabled so that the attacker has to find not only password but the user name too. But this is completely equivalent to using such password as you normally would and prefixing it by the user name you would use. Because it's easily possible to modify the default if the administrator wants to there is no reason for complicating things to administrator who knows how to create a secure password. We also support headless installs and the user accounts are added after reboot on firstboot - too late for headless if you don't use kickstart.
*** Bug 97070 has been marked as a duplicate of this bug. ***
*** Bug 171595 has been marked as a duplicate of this bug. ***
I agree that the root password needs to be protected. What some commentors are missing is that this is a way to help protect the root password. Comment #4 is key. Everyone knows there is a privledged account named root. If it is not directly accessible crackers will need to guess an unprivledged account name and password, and then still break root while logged in to the local machine. It seems to me that is a considerably more difficult task than a single password that can be attacked remotely. So, I disagree strongly that there is no increase in security. Further, this is apparently a known exploit. I am seeing many dictionary attempts from all over the globe on the root account on my systems. Since there is nothing special about my systems (there are only a couple of home PCs), I assume this is a widespread phenomena. In my opinion it would be better to have a secure system, that I can easily open up if I want to, than an insecure system that I have to figure out how to clean up after a compromise. I also note the Solaris ships with remote root ssh access disabled.
Reopening as per discussion on fedora-devel, and tweaking slightly to reflect suggested change: instead of disabling root logins entirely, instead use PermitRootLogin=without-password which would allow logins via cryptographic key but not using password authentication. That way, root ssh can easily be used for emergency administrative access, but not present a vulnerability to random dictionary-attack probing.
Without a good solution for the remote vnc install without a kickstart I don't think we should change this default. However I think that there could be an improvement to the standard use case of a desktop install. The firewall is setup by default and has sshd port open - this is necessary when firstboot is not run yet - but in case it is run the sshd port should be closed by default. So s-c-securitylevel should be changed so it shows and sets sshd port blocked by default when it is run in firstboot. This way an user with a potentially weak root (and user) password doesn't have to explicitely uncheck the sshd in s-c-securitylevel and his machine is protected after firstboot. If the user explicitely opens the sshd port in firewall we can expect that he is aware of potential attack on weak passwords through sshd and has reasonably good root and user's passwords.
I hope you will reconsider leaving the root account exposed via sshd. What is important to realize is that people who run Fedora as a desktop system are asked for their root password multiple times on a daily basis, for administrative reasons. This encourages people to choose easy to remember, easy to type root passwords. These types of passwords are esp. vulnerable to dictionary attacks. The firewall is not an acceptable solution, as many reasonable people won't think to check! Users should either be informed that their administrative password is open to dictionary attacks, and should be reconsidered in that light (possibly in the firewall application?), or root login should be disabled by default. As you know, bot nets and brute force password guessing are very real dangers. Is it unreasonable to expect experienced users who need the feature to enable it, and take the more secure route by default?
*** Bug 450513 has been marked as a duplicate of this bug. ***
It appears that discussion has ended. Should this bug remain open?
It was kept open so there are no duplicate bug reports created.
*** Bug 467604 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 498628 has been marked as a duplicate of this bug. ***
Perhaps a compromise may be, at firstboot: chkconfig sshd off Set PermitRootLogin no in /etc/ssh/sshd_config For users that may actually use these features, it is dead simple for them to turn them back on. And for the large amount of people who don't use ssh that have this vulnerability, this would be a much more secure setup. It seems unconscionable to me to allow ssh root access via password with unlimited login attempts.
*** Bug 817325 has been marked as a duplicate of this bug. ***
Few recent notes to keep track about this topic. Upstream makes this default in future openssh-6.9: https://anongit.mindrot.org/openssh.git/commit/?id=88a7c598a94ff53f76df228eeaae238d2d467565 Change Request on Fedora: https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no Discussion on mailing list: https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html Widely rejected so we will have to hold our old default with next update.
*** Bug 1425285 has been marked as a duplicate of this bug. ***
`PermitRootLogin no` was made the upstream default in 2015, and a subsequent change introduced `PermitRootLogin prohibit-password` which has been the default since there. There is zero good reason Fedora should be setting this to `yes` in 2019. Also if Fedora is going to modify upstream configuration files, we need to point out at the top that we've modified it from upstream's defaults. Right now Fedora, I argue inappropriately, suggests this file is the same as upstream by keeping the same header and not including a NOTE, for example: # NOTE: Fedora has modified the upstream version of this file: # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ https://raw.githubusercontent.com/openssh/openssh-portable/master/sshd_config
Proposed as a Blocker for 30-final by Fedora user chrismurphy using the blocker tracking app because: Final release criterion: *The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation). * I've requested an assessment on impact from security@ but given that upstream openssh has set `#PermitRootLogin prohibit-password` for nearly four years, and Fedora is carrying a silent modification to allow root logins, I think it's at least an "important" impact.
+1b +1 prohibit-password as default value.
-1 blocker from me. This is a configuration setting, not a bug and thus can't violate the release criteria. I agree that the default should be changed, but this should be an F31 Change, not something we drop in via the blocker process two weeks before GA.
-1 blocker. This is a policy question, and last time the change was proposed, it was rejected (see #c26 above); given that I don't think we can reasonably just use the blocker process to declare that it must be changed now, in a massive hurry.
-1 blocker here for the reasons above (not a "bug", should go thru the change process, need to solve all the install methods that still need it).
-1 blocker, -1 fe. I agree with Adam that if we should want to make this change, it should be thoroughly discussed first! According to the bug number, this has been going on and on since 2003. We have existed all the time and probably have not experienced any massive break-ins, so I tend to believe that this change is nothing we could be spending our time too much though. There are other problems, we could be talking about.
This has to be a proper Systemwide Fedora Change. Given this is deviation from the upstream OpenSSH default, I'd be in favor of doing it in Fedora 31.
-1 blocker, -1 fe. Doing this in rawhide would be great though.
That's +1 / -6, marking as rejected. If anyone feels strongly that this is the wrong decision, please bring it up during the open floor period at the blocker review meeting in an hour or so - thanks!
I strongly agree that this is not a good use for the blocker process. I think a Change is a good idea. If this isn't getting any traction, the Prioritized Bug process may be used to raise attention. https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process
I filled the following draft for Fedora 31 system-wide change: https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd Please, let me know whether this looks good or there is something missing. I will send it to the change wrangler and for the review of Fesco afterward.
The Change page looks nice.
I think the change should apply on upgrades, i.e. Fedora 29 and Fedora 30, upon being upgraded to Fedora 31, should also have PermitRootLogin prohibit-password. There is a substantial user base that depends only on upgrades for the entire lifecycle of their hardware.
No, that does not make any sense. This would break existing configurations for users that have root user with strong password. This must not apply to upgrades (in other form than creating a .rpmnew file that contains the configuration change).
This was changed in rawhide few days back based on the Fedora 31 change: https://bugzilla.redhat.com/show_bug.cgi?id=1722928 https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd