OpenSSH server sshd_config PermitRootLogin -> NO

On Thu, Jan 21, 2010 at 04:21:25PM -0000, Lars Noodén wrote:
> Public bug reported:
>
> Ubuntu does not use the root account directly so the PermitRootLogin
> directive in sshd_config should be set to "no" by default.

Since the root account is disabled by default, it's impossible to login as root
by default.

Could you elaborate how defaulting PermitRootLogin to no would improve the
default installation?

 status incomplete
 importance wishlist

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Hmm. Wishlist is not the right category for a bug.

Mathias, defaulting PermitRootLogin to "no" improves the layered process of 'security' for the default installation by adding another layer of protection and not relying on the hope that the root account will always remain disabled. Correcting the default setting for that directive adds an additional line of defense should the root account become activated, something which is easily done by accident, curiosity or misguided attempts at solving other problems. You can work that out for yourself.

My own recent anecdotes show that, on the Ubuntu forums and when dealing with about 150 students (from 2006-2009) whom I guided in laboratory exercises involving Ubuntu, root accounts do get activated.

You can go to the page at the first link above to the people who write OpenSSH and read what they recommend: defaulting PermitRootLogin to no.

Does that answer your question?

See also

http://wiki.centos.org/HowTos/Network/SecuringSSH#head-9c01429983dccbf74ade8674815980dc6434d3ba

https://calomel.org/openssh.html

http://www.linux.com/archive/feature/119744/

The issue is a trade-off between three classes of people, I think:
 - People that have systems where root can SSH in (which consists of):
  - Those that want to SSH in as root
  - Those that are surprised they can SSH in as root
  - Those that don't care

http://cheezburger.com/View.aspx?aid=3094191616

By changing the default to "no", we protect the class of people that don't care, and irritate the people that expect to log in as root. By leaving the default as "yes", the class of people that don't care are vulnerable, but irritate the people that think this is insecure.

The choice depends on the perceived benefit in protecting that class of user while weighed against those expecting to log in as root without having to also change SSH configs. Is the dark green area larger than the blue area?

Thank you for the cheezburger link, Kees. From it, I am starting to understand more about how decisions are made in the Ubuntu project and the authoritative resources drawn upon to help make informed decisions. Anyhow, those that somehow get the impression that they want to log in as root can always set the PermitRootLogin directive in /etc/sshd_config from 'no' to 'yes'

What use-case is there for remote root login that cannot already be met by a tuned sudoers?
Use of sudo allows further compartmentalization of access and privilege.

"Layering security defenses in an application can reduce the chance of a successful attack...
so that if one layer of defense turns out to be inadequate, another layer of defense will hopefully prevent a full breach. "
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/347-BSI.html

"What use-case is there for remote root login that cannot already be met by a tuned sudoers?"

The first that comes to mind are various backup strategies. Of course, best practice would indicate to use ForceCommand in this situation. Another option would be to use 'forced-commands-only' instead of 'no'. This may be overly-complicating things though....

"authoritative resources"? I'm inferring that you think my use of a simple diagram tool to help illustrate this bug is somehow inappropriate? And yes, I know what layered security is. :)

Please understand that the PermitRootLogin config default is not a new issue. I'm trying to make sure everyone can have the same language to discuss it, as this has traditionally been what has derailed discussions before. Also, I did not mention in my first comment, but I support changing this setting. That said, Ubuntu tries to make its decisions via consensus, which this issue does not have. I'm hoping to build such a consensus.

The primary concern I have is for the safety of Ubuntu users, though it must be balanced against usability. A default system doesn't even have openssh-server installed (it is, of course, installed on nearly all server systems). A system _with_ openssh-server does not allow root login because the root user's password is locked. Therefore, the bulk of Ubuntu users are protected already from root-targeted SSH brute-force attacks.

This bug is explicitly about the behavior of an already non-default system (openssh-server installed, root password enabled). For this minority of Ubuntu systems, the PermitRootLogin setting currently creates a problem for the people that aren't thinking about how brute forcing might compromise them (i.e. people that did not understand the implications of enabling the strongly discouraged root password). Changing the setting protects these people and gets in the way of people that do not know how to change PermitRootLogin to "yes".

If upstream are so convinced that this is a bad idea, then I doubt they would have made PermitRootLogin default to yes! I do not intend to deviate from upstream in the Debian or Ubuntu packaging on this matter. If you want this changed, convince upstream.

We wrote down our thoughts on this in openssh's README.Debian file some years ago.

Jamie, the various backup strategies that I have seen are all suited to using sudo. They all run a program or script which receives some arguments at run time. That includes rsync over ssh. Could you please be specific about which backup strategy is not able to work with sudo?

Kees, yes, I see that it is not an new issue. However, there is no need to rationalize legacy settings. The closest to a real choice is between a small up front investment in knowledge or documentation about sudo versus a larger mess later on. In that way, the assertion of security XOR usability, appears to be a false dichotomy.

Colin, this bug report is for Ubuntu, not Debian, OpenSSH portable team, or OpenBSD. The object is to address the relative weakness of Ubuntu servers in regards to bruteforce attacks against root accounts. Since upstream is mentioned, you probably have direct experience there. I would remind then that OpenSSH is developed as part of OpenBSD and that when installing OpenBSD, the default there during the basic installation is if a regular user is added is to turn off remote root login. So one compromise would be to add the same option to the Ubuntu server installation script.

Most sub-distros do not have openssh-server by default, so this bug does not affect them, only AFAIK the Ubuntu server.

On Fri, Jan 22, 2010 at 12:54:29PM -0000, Lars Noodén wrote:
>
> Most sub-distros do not have openssh-server by default, so this bug does
> not affect them, only AFAIK the Ubuntu server.
>

The default Ubuntu Server install does *not* have openssh-server installed.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

"The default Ubuntu Server install does *not* have openssh-server installed."

Ok, then that's a separate bug needing a separate bug report.

Nearly all installations of the openssh-server package, I am guessing then, are on the Ubuntu Server or an alternate install tuned to be rather like the Ubuntu Server. Is there a way of getting the popularity contest data to examine package installation frequency and finding groupings or clusters of daemons commonly installed together?

Mathias, did comment #2 answer your question about setting PermitRootLogin to NO as default would improve the
default openssh-server installation?

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/510732/comments/2

On Fri, Jan 22, 2010 at 08:26:58PM -0000, Lars Noodén wrote:
> "The default Ubuntu Server install does *not* have openssh-server
> installed."
>
> Ok, then that's a separate bug needing a separate bug report.
>

As outlined on the Security Team policies [1]

  No Open Ports

  Default installations of Ubuntu must have no listening network services after
  initial install. Exceptions to this rule include network infrastructure
  services such as the DHCP client and mDNS (Avahi/ZeroConf, see
  ZeroConfPolicySpec for implementation details and justification). When
  installing Ubuntu Server, the administrator can, of course, select specific
  services to install beyond the defaults (e.g. Apache).

[1]: https://wiki.ubuntu.com/SecurityTeam/Policies

So there is no need to open a new bug report about this. If you want to discuss
this policy I'd recommend to send your proposal to the ubuntu-devel@ mailing
list. A bug report is definitely not the best option to have your thoughts on
that matter heard.

> Nearly all installations of the openssh-server package, I am guessing
> then, are on the Ubuntu Server or an alternate install tuned to be
> rather like the Ubuntu Server. Is there a way of getting the popularity
> contest data to examine package installation frequency and finding
> groupings or clusters of daemons commonly installed together?
>

I don't think so. It's hard to measure what is installed and what is not. As
consequence anyone's numbers are as accurate as anyone else's.

> Mathias, did comment #2 answer your question about setting PermitRootLogin to NO as default would improve the
> default openssh-server installation?
>

Yes - thanks.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Mathias,

> Could you elaborate how defaulting PermitRootLogin to no would improve the
> default installation?

It does not pass a "makes sense" sensor (at least not mine). It actually alarmed me a for a minute into thinking there may be a backdoor into my system. (I double checked /etc/shadow to make sure)
The improvement comes from a more consistent and logical system/configuration.

Colin,

> If upstream are so convinced that this is a bad idea, then I doubt they would have made PermitRootLogin default to yes! I do
> not intend to deviate from upstream in the Debian or Ubuntu packaging on this matter. If you want this changed, convince
> upstream.

If you do not want to be BETTER than upstream, then what's the point of a derivative distro? In OSS philosophy you can/should report to upstream and have it fixed there so it benefits everyone, but when a setting doesn't make sense, it just doesn't make sense and should be changed IMHO.

For anyone not wanting to change it: What is the reasoning behind setting PermitRootLogin to "yes" other than "upstream does it too"?

I have stated my position repeatedly, in many different places. It's
obvious that you simply disagree so I don't think it's worth me stating
it again. I respect your right to disagree.

Don't argue about it. Just make the correction by setting it to "No"

Yes, it is not safe setting, particularly for home PC - there is put a simple password to root, and often install ssh server, if you have an external IP and need access from work.

The entirety of the discussion seems to say there's no intention to change the current defaults. Why is this 'wishlist', not 'wontfix' or somesuch?

This one can probably be closed since the default is now "PermitRootLogin without-password" and that's close enough.

It has been fixed upstream:

http://www.openssh.com/txt/release-6.9