Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RFE: disallow root login via password using SSH|
|Product:||[Fedora] Fedora||Reporter:||Peter van Egdom <p.van.egdom>|
|Component:||openssh||Assignee:||Jakub Jelen <jjelen>|
|Status:||ASSIGNED ---||QA Contact:|
|Version:||rawhide||CC:||bomber98547, cnystrom, collura, cpanceac, darren.gamble, jjelen, mattdm, mcepl, michael, mishu, mitr, rcyriac, rvokal, smohan, tmraz, vwfoxguru|
|Target Milestone:||---||Keywords:||FutureFeature, Reopened|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-05-26 15:16:20 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Peter van Egdom 2003-04-21 06:58:48 EDT
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
Comment 1 Michael Lee Yohe 2003-04-21 10:22:17 EDT
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?
Comment 2 Peter van Egdom 2003-04-21 11:18:07 EDT
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.
Comment 3 Michael Lee Yohe 2003-04-21 12:16:03 EDT
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.").
Comment 4 Aaron Sherman 2003-09-23 16:45:15 EDT
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.
Comment 5 David J Craigon 2004-01-22 10:46:28 EST
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.
Comment 6 Travis Waldher 2004-09-01 15:10:58 EDT
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.
Comment 7 Matthew S. Hallacy 2004-12-21 09:10:10 EST
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.
Comment 8 Tomas Mraz 2005-05-26 15:16:20 EDT
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.
Comment 9 Tomas Mraz 2005-10-24 03:39:50 EDT
*** Bug 97070 has been marked as a duplicate of this bug. ***
Comment 10 Tomas Mraz 2005-10-24 03:44:10 EDT
*** Bug 171595 has been marked as a duplicate of this bug. ***
Comment 11 Chris Nystrom 2005-10-24 04:40:47 EDT
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.
Comment 12 Matthew Miller 2006-08-21 11:18:35 EDT
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.
Comment 13 Tomas Mraz 2006-08-21 17:24:20 EDT
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.
Comment 14 Kurt Erickson 2007-09-29 00:53:45 EDT
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?
Comment 15 Tomas Mraz 2008-06-09 07:47:27 EDT
*** Bug 450513 has been marked as a duplicate of this bug. ***
Comment 16 John Poelstra 2008-07-02 15:23:48 EDT
It appears that discussion has ended. Should this bug remain open?
Comment 17 Tomas Mraz 2008-07-02 15:33:11 EDT
It was kept open so there are no duplicate bug reports created.
Comment 18 Tomas Mraz 2008-10-19 12:00:17 EDT
*** Bug 467604 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Admin XMLRPC Client 2009-03-10 05:20:37 EDT
Comment 20 Fedora Admin XMLRPC Client 2009-03-10 06:17:46 EDT
Comment 21 Fedora Admin XMLRPC Client 2009-03-10 06:19:42 EDT
Comment 22 Tomas Mraz 2009-05-04 03:22:49 EDT
*** Bug 498628 has been marked as a duplicate of this bug. ***
Comment 23 Scott Williams 2010-10-23 17:57:04 EDT
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.
Comment 24 Fedora Admin XMLRPC Client 2011-11-30 07:25:25 EST
Comment 25 Tomas Mraz 2012-04-30 02:40:54 EDT
*** Bug 817325 has been marked as a duplicate of this bug. ***
Comment 26 Jakub Jelen 2015-06-24 10:43:57 EDT
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.
Comment 27 Fedora Admin XMLRPC Client 2016-01-08 08:42:54 EST