About sshd(8) PermitRootLogin=no

[P J P]

   Hello,

Please see
  -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no

Last week this was discussed in the FST meeting and on the fedora-devel list subsequently.
General consensus seems to be that it is okay to disable remote 'root' login via
sshd(8). Above feature request is for the same.

If you have any comments/suggestions/inputs, please feel free share them or edit the
feature page as required.

Thank you.
---
Regards
   -Prasad
http://feedmug.com

[Tomas Mraz]

On Po, 2014-11-24 at 12:37 +0000, P J P wrote:
>     Hello,
>  
>  Please see
>    -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>  
>  Last week this was discussed in the FST meeting and on the
>  fedora-devel list subsequently. General consensus seems to be that it
>  is okay to disable remote 'root' login via sshd(8). Above feature
>  request is for the same.
>  
>  If you have any comments/suggestions/inputs, please feel free share
>  them or edit the feature page as required. 
For the ssh-inject feature you would need PermitRootLogin
without-password. Also I do not see as a risk to allow root login with
the public-key authentication so that might be a good compromise.

The reason the root login with password was kept allowed was the support
for vnc installation without kickstart as it was previously impossible
to create regular user in anaconda. Now that anaconda allows to create
regular user accounts we could disable sshd root login with password. We
just need to properly advertise that.

The only remaining problem is for systems which have been installed
previously and have only root login and someone upgrades them to new
Fedora release. Here the system would be made inaccessible by the
openssh-server rpm upgrade from the old Fedora to F22.

I am afraid there is no easy solution for the problem above.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)

[Petr Lautrbach]

On 11/24/2014 01:57 PM, Tomas Mraz wrote:
>  On Po, 2014-11-24 at 12:37 +0000, P J P wrote:
> >    Hello,
> >
> > Please see
> >   -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
> >
> > Last week this was discussed in the FST meeting and on the
> > fedora-devel list subsequently. General consensus seems to be that it
> > is okay to disable remote 'root' login via sshd(8). Above feature
> > request is for the same.
> >
> > If you have any comments/suggestions/inputs, please feel free share
> > them or edit the feature page as required.
>  
>  For the ssh-inject feature you would need PermitRootLogin
>  without-password. Also I do not see as a risk to allow root login with
>  the public-key authentication so that might be a good compromise.
>  
>  The reason the root login with password was kept allowed was the support
>  for vnc installation without kickstart as it was previously impossible
>  to create regular user in anaconda. Now that anaconda allows to create
>  regular user accounts we could disable sshd root login with password. We
>  just need to properly advertise that. 
reference https://bugzilla.redhat.com/show_bug.cgi?id=89216

>  
>  The only remaining problem is for systems which have been installed
>  previously and have only root login and someone upgrades them to new
>  Fedora release. Here the system would be made inaccessible by the
>  openssh-server rpm upgrade from the old Fedora to F22.
>  
>  I am afraid there is no easy solution for the problem above.
>   
I think it's ok for upgrade between versions if it's promoted as a
Fedora Feature.


Petr
-- 
Petr Lautrbach

[Richard Z]

On Mon, Nov 24, 2014 at 02:02:59PM +0100, Petr Lautrbach wrote:
>  On 11/24/2014 01:57 PM, Tomas Mraz wrote:
>  > On Po, 2014-11-24 at 12:37 +0000, P J P wrote:
>  >>    Hello,
>  >>
>  >> Please see
>  >>   -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>  >>
>  >> Last week this was discussed in the FST meeting and on the
>  >> fedora-devel list subsequently. General consensus seems to be that it
>  >> is okay to disable remote 'root' login via sshd(8). Above feature
>  >> request is for the same.
>  >>
>  >> If you have any comments/suggestions/inputs, please feel free share
>  >> them or edit the feature page as required.
>  > 
>  > For the ssh-inject feature you would need PermitRootLogin
>  > without-password. Also I do not see as a risk to allow root login with
>  > the public-key authentication so that might be a good compromise.
>  > 
>  > The reason the root login with password was kept allowed was the support
>  > for vnc installation without kickstart as it was previously impossible
>  > to create regular user in anaconda. Now that anaconda allows to create
>  > regular user accounts we could disable sshd root login with password. We
>  > just need to properly advertise that.
>  
>  reference https://bugzilla.redhat.com/show_bug.cgi?id=89216
>  
>  > 
>  > The only remaining problem is for systems which have been installed
>  > previously and have only root login and someone upgrades them to new
>  > Fedora release. Here the system would be made inaccessible by the
>  > openssh-server rpm upgrade from the old Fedora to F22.
>  > 
>  > I am afraid there is no easy solution for the problem above.
>  > 
>  
>  I think it's ok for upgrade between versions if it's promoted as a
>  Fedora Feature. 
removing root ssh with password is probably a good thing but admins who 
configured ssh with public-key auth probably have done that after spending 
a few thoughts on it and should not be shot in their feet so quickly.

Richard

---
Name and OpenPGP keys available from pgp key servers

[Petr Lautrbach]

On 11/24/2014 03:49 PM, Richard Z wrote:
>  On Mon, Nov 24, 2014 at 02:02:59PM +0100, Petr Lautrbach wrote:
> > On 11/24/2014 01:57 PM, Tomas Mraz wrote:
> >> On Po, 2014-11-24 at 12:37 +0000, P J P wrote: 
...
> >> The only remaining problem is for systems which have been
> installed
> >> previously and have only root login and someone upgrades them to new
> >> Fedora release. Here the system would be made inaccessible by the
> >> openssh-server rpm upgrade from the old Fedora to F22.
> >>
> >> I am afraid there is no easy solution for the problem above.
> >>
> >
> > I think it's ok for upgrade between versions if it's promoted as a
> > Fedora Feature.
>  
>  removing root ssh with password is probably a good thing but admins who 
>  configured ssh with public-key auth probably have done that after spending 
>  a few thoughts on it and should not be shot in their feet so quickly.
>   
I agree. It should be documented at least in Fedora release notes and as
a Fedora Feature preferably accepted by FESCO.

However it would effectively affect only those admins who haven't
touched /etc/ssh/sshd_config file given that this file is marked as
%config(noreplace).


Petr
-- 
Petr Lautrbach

[Tomas Mraz]

On Po, 2014-11-24 at 15:49 +0100, Richard Z wrote:
>  On Mon, Nov 24, 2014 at 02:02:59PM +0100, Petr Lautrbach wrote:
>  > On 11/24/2014 01:57 PM, Tomas Mraz wrote:
>  > > On Po, 2014-11-24 at 12:37 +0000, P J P wrote:
>  > >>    Hello,
>  > >>
>  > >> Please see
>  > >>   -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>  > >>
>  > >> Last week this was discussed in the FST meeting and on the
>  > >> fedora-devel list subsequently. General consensus seems to be that it
>  > >> is okay to disable remote 'root' login via sshd(8). Above feature
>  > >> request is for the same.
>  > >>
>  > >> If you have any comments/suggestions/inputs, please feel free share
>  > >> them or edit the feature page as required.
>  > > 
>  > > For the ssh-inject feature you would need PermitRootLogin
>  > > without-password. Also I do not see as a risk to allow root login with
>  > > the public-key authentication so that might be a good compromise.
>  > > 
>  > > The reason the root login with password was kept allowed was the support
>  > > for vnc installation without kickstart as it was previously impossible
>  > > to create regular user in anaconda. Now that anaconda allows to create
>  > > regular user accounts we could disable sshd root login with password. We
>  > > just need to properly advertise that.
>  > 
>  > reference https://bugzilla.redhat.com/show_bug.cgi?id=89216
>  > 
>  > > 
>  > > The only remaining problem is for systems which have been installed
>  > > previously and have only root login and someone upgrades them to new
>  > > Fedora release. Here the system would be made inaccessible by the
>  > > openssh-server rpm upgrade from the old Fedora to F22.
>  > > 
>  > > I am afraid there is no easy solution for the problem above.
>  > > 
>  > 
>  > I think it's ok for upgrade between versions if it's promoted as a
>  > Fedora Feature.
>  
>  removing root ssh with password is probably a good thing but admins who 
>  configured ssh with public-key auth probably have done that after spending 
>  a few thoughts on it and should not be shot in their feet so quickly. 
That's solved by 'PermitRootLogin without-password' which I think should
be the change and not 'PermitRootLogin no'.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)

[Matthew Miller]

On Mon, Nov 24, 2014 at 01:57:24PM +0100, Tomas Mraz wrote:
>  The only remaining problem is for systems which have been installed
>  previously and have only root login and someone upgrades them to new
>  Fedora release. Here the system would be made inaccessible by the
>  openssh-server rpm upgrade from the old Fedora to F22.
>  I am afraid there is no easy solution for the problem above. 
The config file is marked as "noreplace". This means that it's only an
issue in cases where the previous system has also never had its sshd
config touched. (And suggests that a somewhat kludgey but functional
workaroud would be to ensure that it _is_ touched before the install --
possibly %pre or %pretrans scripts would be sufficient.)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[P J P]

   Hello Tomas, all

>  On Monday, 24 November 2014 6:27 PM, Tomas Mraz wrote:
>  The reason the root login with password was kept allowed was the support
>  for vnc installation without kickstart as it was previously impossible
>  to create regular user in anaconda. Now that anaconda allows to create
>  regular user accounts we could disable sshd root login with password. We
>  just need to properly advertise that. 
  True; that's manageable.

>  The only remaining problem is for systems which have been installed
>  previously and have only root login and someone upgrades them to new
>  Fedora release. Here the system would be made inaccessible by the
>  openssh-server rpm upgrade from the old Fedora to F22.
>  
>  I am afraid there is no easy solution for the problem above. 

  Ummn for Fedora upgrades, maybe in OpenSSH %post install section we could display a bold
warning message about this change, so that the user is aware of it. This message could be
removed in the subsequent updates to the OpenSSH package.

---
Regards
   -Prasad
http://feedmug.com

[Tristan Santore]

On 25/11/14 08:04, P J P wrote:
>     Hello Tomas, all
>
> > On Monday, 24 November 2014 6:27 PM, Tomas Mraz wrote:
> > The reason the root login with password was kept allowed was the support
> > for vnc installation without kickstart as it was previously impossible
> > to create regular user in anaconda. Now that anaconda allows to create
> > regular user accounts we could disable sshd root login with password. We
> > just need to properly advertise that.
>    True; that's manageable.
>
> > The only remaining problem is for systems which have been installed
> > previously and have only root login and someone upgrades them to new
> > Fedora release. Here the system would be made inaccessible by the
> > openssh-server rpm upgrade from the old Fedora to F22.
> >
> > I am afraid there is no easy solution for the problem above.
>
>    Ummn for Fedora upgrades, maybe in OpenSSH %post install section we could display a
> bold warning message about this change, so that the user is aware of it. This message
> could be removed in the subsequent updates to the OpenSSH package.
>
>  ---
>  Regards
>     -Prasad
>  http://feedmug.com
>  --
>  security mailing list
>  security(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/security 
Hi All,

Are we talking here physical releases ? Or just infra or just best
advice for people ? I fear that if we do disable SSH root logins, this
will make some people's lives a lot harder. But could somebody please be
so kind to clarify what exactly we are considering here ?

Thank you.

Regards,

Tristan

-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[P J P]

   Hello Tristan,

>  On Tuesday, 25 November 2014 4:15 PM, Tristan Santore wrote
>  Are we talking here physical releases ? Or just infra or just best
>  advice for people ? I fear that if we do disable SSH root logins, this
>  will make some people's lives a lot harder. But could somebody please be
>  so kind to clarify what exactly we are considering here ? 

  I thought the feature page explains it. Anyway, idea is to prevent remote
users from using 'root' account to login via ssh(1).

   $ ssh root(a)1.2.3.4

Instead, they would need to first login as non-root user and then use sudo(8)
or su(1) commands to gain root access.

If you could share the difficulties it would add to some people's lives, we could try
to find remedies.

---
Regards
   -Prasad
http://feedmug.com

[Brandon Vincent]

I have two divergent opinions on this issue.

Personally, I agree with Theo de Randt on the reasoning behind the
default PermitRootLogin setting in OpenSSH. If your root password is
of adequate strength (in the event that you're not mandating the use
of keys), then realistically the risk of exposing root logins over SSH
is minimal (excluding any unforeseen exploits in OpenSSH). I trust the
mathematics of cryptography.

On the other hand, I can't vouch for the security of other user's
systems. I have a suspicion that the majority of brute force attacks
that succeed occur on systems where the user is unaware that sshd is
running and/or the system was never meant to be reachable from the
internet.

Sucuri found that 58% of brute force attacks were conducted against
the root account [1]. A full list of the passwords tried by attackers
can be found here [2]. The strength of passwords that are tried are
obviously extremely weak.

Since setting PermitRootLogin to no will minimize the footprint of
this attack, I'd be more than happy to see it implemented. Anyone who
wants to sets PermitRootLogin to yes, is likely well aware of the
importance of strong passwords and the visibility of their system over
the internet.

Brandon Vincent

[1]
http://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-tha...
[2]
http://labs.sucuri.net/dump/sshd_bruteforce_list.txt?_ga=1.53033320.11590...

[Brandon Vincent]

On Tue, Nov 25, 2014 at 8:05 AM, Brandon Vincent
<Brandon.Vincent(a)asu.edu&gt; wrote:
>  Personally, I agree with Theo de Randt on the reasoning behind the
>  default PermitRootLogin setting in OpenSSH. 
Apologizes for misspelling Theo's name, it should be Raadt.

Brandon Vincent

[Miloslav Trmač]

Hello,
----- Original Message -----
>  > The only remaining problem is for systems which have been
> installed
>  > previously and have only root login and someone upgrades them to new
>  > Fedora release. Here the system would be made inaccessible by the
>  > openssh-server rpm upgrade from the old Fedora to F22.
>  > 
>  > I am afraid there is no easy solution for the problem above.
>  
>    Ummn for Fedora upgrades, maybe in OpenSSH %post install section we could
>    display a bold warning message about this change, so that the user is
>    aware of it. This message could be removed in the subsequent updates to
>    the OpenSSH package. 
That’s work for the user, and probably even for the programmer more work than
automatically detecting the situation and not changing the configuration.  “Hello, this is
a program telling you to do manually something a program could easily do” is rarely the
best answer.
    Mirek

[Reindl Harald]

Am 01.12.2014 um 23:04 schrieb Miloslav Trmač:
>  Hello,
>  ----- Original Message -----
> >> The only remaining problem is for systems which have been installed
> >> previously and have only root login and someone upgrades them to new
> >> Fedora release. Here the system would be made inaccessible by the
> >> openssh-server rpm upgrade from the old Fedora to F22.
> >>
> >> I am afraid there is no easy solution for the problem above.
> >
> >    Ummn for Fedora upgrades, maybe in OpenSSH %post install section we could
> >    display a bold warning message about this change, so that the user is
> >    aware of it. This message could be removed in the subsequent updates to
> >    the OpenSSH package.
>
>  That’s work for the user, and probably even for the programmer more work than
> automatically detecting the situation and not changing the configuration.  “Hello, this is
> a program telling you to do manually something a program could easily do” is rarely the
> best answer. 
sure?

many people are using Linux because they hope to know to some degree 
what their computer is doing instead "something magically does something"

not that i personally don't have the knowledge to keep control but 
that's not the point - to keep a difference between Linux and MS/Apple a 
Linux distribution sometimes should follow "better safe than sorry" or 
in other words "better ask instead get complaints why not asked"

[Eric Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, Dec 01, 2014 at 11:26:30PM +0100, Reindl Harald wrote:
>  many people are using Linux because they hope to know to some degree
> what
>  their computer is doing instead "something magically does something"
>  
>  not that i personally don't have the knowledge to keep control but that's
>  not the point - to keep a difference between Linux and MS/Apple a Linux
>  distribution sometimes should follow "better safe than sorry" or in other
>  words "better ask instead get complaints why not asked" 
This makes a lot of sense.  I still agree with sane defaults that don't allow dumb
things to happen out of the box but we should also be looking at ways for people to
determine whether or not their systems are setup in an insecure manner.  Some of this
already exists in the SCAP world but is mostly focused on compliance testing and not
'how to make sure I'm not going to get pwned'.

Perhaps we need to make SCAP rules that check for obvious deficiencies and then make that
increadibly easy for an admin to run.  Then issues like allowing root access via ssh
(directly) would come up on the admin's radar and the admin could fix it.  There are
many things I'm running on my server that I *hope* are configured appropriately.  It
would be great if there was a way for my system to be scanned to see if there are things I
could be doing better.

- -- Eric

- --------------------------------------------------
Eric "Sparks" Christensen
Red Hat, Inc - Product Security

sparks(a)redhat.com - sparks(a)fedoraproject.org
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJUfcqPAAoJEB/kgVGp2CYv8kkL/jjo6nSl0vI5Fh177I2NEJEX
> cJjScxbWko5j23v/k6EpiwjFlGKu7tSu8wVptfllwPrjZIujZFrKpb+H/Aw0Vjnn
> tq2zf3foNfry9WhC4fJEOXpDaJqCBGuQyXYHj/zcXthaSzpTPzSOxd1uBiLptlBr
> OHmBUhdRDBDd1zW0N+l/z9ByGLtqe/3k7DDuvUgPVA/Taiw7GzDEyg4Bi9j3i3uj
> by1Hv8WiLUcRET4QoU1VnhfaXshTkTb2VP0W5cOIvIe5napW2A5g80v8ZDTb9eis
> wzbDvJNdG+nkSmKRcVWnxSqdwhfcyXh62Ql0mN/zmIATq921XZDichFAgi7UTIiE
> PK4QS4PwzNxT83CIzHLEcGkzxO/GQbRH6q3FXjxnKQCc/eCLYVhw94VvBX+G5QZg
> PeCvdH7tGb6hjhtUdRScKYTq/n6jBWvAEiLo6HdCKm9JnYQWjv7ZWU/5Gi2ug/u4
> CnuIdO/gY2zrW0XFVNGo4293KGlp7R6scN5wbPNbPA==
> =TLDU
> -----END PGP SIGNATURE-----

[Tristan Santore]

On 02/12/14 14:20, Eric H. Christensen wrote:
>  On Mon, Dec 01, 2014 at 11:26:30PM +0100, Reindl Harald wrote:
>  > many people are using Linux because they hope to know to some degree
>  what
>  > their computer is doing instead "something magically does something"
>
>  > not that i personally don't have the knowledge to keep control but
>  that's
>  > not the point - to keep a difference between Linux and MS/Apple a Linux
>  > distribution sometimes should follow "better safe than sorry" or in
>  other
>  > words "better ask instead get complaints why not asked"
>
>  This makes a lot of sense.  I still agree with sane defaults that
>  don't allow dumb things to happen out of the box but we should also be
>  looking at ways for people to determine whether or not their systems
>  are setup in an insecure manner.  Some of this already exists in the
>  SCAP world but is mostly focused on compliance testing and not 'how to
>  make sure I'm not going to get pwned'.
>
>  Perhaps we need to make SCAP rules that check for obvious deficiencies
>  and then make that increadibly easy for an admin to run.  Then issues
>  like allowing root access via ssh (directly) would come up on the
>  admin's radar and the admin could fix it.  There are many things I'm
>  running on my server that I *hope* are configured appropriately.  It
>  would be great if there was a way for my system to be scanned to see
>  if there are things I could be doing better.
>
>  -- Eric
>  
I would just like to make sure, that new users are aware of what we are
doing. We already have password quality controls and warnings in
anaconda. If we go along the path of root user+password and then the
need for a user login first to then sudo or su to root, I think we
should dump a warning or notification in anaconda. Further, this does
not appear to address the issue of remote installs via vnc/spice. I am
not sure about the latest VNC and Spice, but do they now encrypt traffic
? I never looked into VNC changes in Tigervnc again, but I am aware it
supports extensions to that effect. Are these default though in
anaconda's VNC implementation, does it throw people out if they do not
use encryption or does it allow non-secure fallback ?

Just a few thoughts on my part.

Regards,

Tristan

-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Kurt Seifried]

On 02/12/14 07:28 AM, Tristan Santore wrote:
>  I would just like to make sure, that new users are aware of what we
> are
>  doing. We already have password quality controls and warnings in
>  anaconda. If we go along the path of root user+password and then the
>  need for a user login first to then sudo or su to root, I think we
>  should dump a warning or notification in anaconda. Further, this does
>  not appear to address the issue of remote installs via vnc/spice. I am
>  not sure about the latest VNC and Spice, but do they now encrypt traffic
>  ? I never looked into VNC changes in Tigervnc again, but I am aware it
>  supports extensions to that effect. Are these default though in
>  anaconda's VNC implementation, does it throw people out if they do not
>  use encryption or does it allow non-secure fallback ? 
More to the point, who cares in that situation, many cloud providers use
the VNC terminal to provide "console" access which is then provided via
HTTPS to the end user (so the only unencrypted part is from your VM to
the host server, in other words if an attacker can sniff that they own
the box).

I, along with many cloud people, would be highly annoyed to have the
root account disabled by default. But the times are a changing so maybe
it's not such a terrible thing.

>  Just a few thoughts on my part.
>  
>  Regards,
>  
>  Tristan
>   
-- 
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

[Hubert Kario]

On Wednesday 03 December 2014 09:07:09 Kurt Seifried wrote:
>  On 02/12/14 07:28 AM, Tristan Santore wrote:
>  > I would just like to make sure, that new users are aware of what we are
>  > doing. We already have password quality controls and warnings in
>  > anaconda. If we go along the path of root user+password and then the
>  > need for a user login first to then sudo or su to root, I think we
>  > should dump a warning or notification in anaconda. Further, this does
>  > not appear to address the issue of remote installs via vnc/spice. I am
>  > not sure about the latest VNC and Spice, but do they now encrypt traffic
>  > ? I never looked into VNC changes in Tigervnc again, but I am aware it
>  > supports extensions to that effect. Are these default though in
>  > anaconda's VNC implementation, does it throw people out if they do not
>  > use encryption or does it allow non-secure fallback ?
>  
>  More to the point, who cares in that situation, many cloud providers use
>  the VNC terminal to provide "console" access which is then provided via
>  HTTPS to the end user (so the only unencrypted part is from your VM to
>  the host server, in other words if an attacker can sniff that they own
>  the box).
>  
>  I, along with many cloud people, would be highly annoyed to have the
>  root account disabled by default. But the times are a changing so maybe
>  it's not such a terrible thing. 
Well, as long as the cloud provider allows you to setup SSH keys and 
automatically installs them on any host you provision, I'd say it makes the 
configuration easier to manage and safer: *better* in all ways.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Miloslav Trmač]

(Randomly picking a place in the thread to insert this…)

Fundamentally, as someone has already pointed out, root login enabled/disabled doesn’t
matter for _authentication_ strength: The pair of (guessable or known user name, “root”)
and (user’s password, root password) can be equally strong as the pair of “root” and “a
password as strong as the two previous passwords together”.

OTOH, not all security is pure computer security: it is a good idea to _attribute_ every
action to a physical person, so that physical security mechanisms (disciplinary action,
lawsuits, guns) can be used.  In this sense, the “root” account is a very strange concept,
and it is being used in two very different ways: 1) as an authentication system
bypass/override (very similar to “enter the BIOS password to bypass OS security
altogether”), and 2) as a conventional default user name to use for clearly
single-physical-user OS installations (personal VMs).


Now, arguably, in a perfect design, neither of these should be needed: 

For 1), just use the BIOS password and boot into single-user mode (which then must be
configured not to ask for a password), or perhaps into a special variant of the standard
multi-user mode (so that networking and the IPA client works) with an unauthenticated root
shell open.  This would break for servers with no or difficult physical access and no
KVM/serial console set up; is that a frequent and significant case?

For 2), use the same user name you use on the host or your other computers, and set up
sudo to give this user in the guest full control.  This could, if we can automate the sudo
part, even be more convenient: “ssh hostname” now works without having to prepend root@,
or having to add such a configuration to ssh_config.


So I guess the long-term ideal would be to stop talking about the “root password”
altogether (i.e. have an anaconda install end up with root password authentication
disabled, and for “the” administrator, set up sudo to be authenticated with their own, not
root’s nonexistent, password), and to stop recommending _any_ log ins directly to the root
account.  That would also implicitly resolve the sshd discussion.

Apart from older systems, which can stay unchanged on upgrades easily enough, there must
be other cases where this would cause difficulty.  One obvious disadvantage of disabling
the root password would be that it essentially forces any organization with multiple
sysadmins to deploy IPA or something similar for managing all the individual’s accounts
and passwords; I’m sure this can be argued to be another advantage but some sysadmins who
used a shared password for a few decades (and a few generations of sysadmins) will still
disagree.
    Mirek

[Matthew Miller]

On Thu, Dec 04, 2014 at 10:00:54AM -0500, Miloslav Trmač wrote:
>  For 1), just use the BIOS password and boot into single-user mode
>  (which then must be configured not to ask for a password), or perhaps
>  into a special variant of the standard multi-user mode (so that
>  networking and the IPA client works) with an unauthenticated root
>  shell open. This would break for servers with no or difficult
>  physical access and no KVM/serial console set up; is that a frequent
>  and significant case? 
I don't think it's a significant use case for servers that aren't being
installed via kickstart, where there's the opportunity to configure or
open up _whatever_.


>  For 2), use the same user name you use on the host or your other
>  computers, and set up sudo to give this user in the guest full
>  control. This could, if we can automate the sudo part, even be more
>  convenient: “ssh hostname” now works without having to prepend root@,
>  or having to add such a configuration to ssh_config. 
We already pretty much do this.

>  So I guess the long-term ideal would be to stop talking about the
>  “root password” altogether (i.e. have an anaconda install end up with
>  root password authentication disabled, and for “the” administrator,
>  set up sudo to be authenticated with their own, not root’s
>  nonexistent, password), and to stop recommending _any_ log ins
>  directly to the root account. That would also implicitly resolve the
>  sshd discussion. 
Yes, although I'd argue that in this case it's _more_ important to set
the default to deny, because if everyone assumes that root just can't
get in, it's a cheap back-door to just set a password and hope no one
notices.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Eric Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Dec 04, 2014 at 10:00:54AM -0500, Miloslav Trmač wrote:
>  Fundamentally, as someone has already pointed out, root login
> enabled/disabled doesn’t matter for _authentication_ strength: The pair of (guessable or
> known user name, “root”) and (user’s password, root password) can be equally strong as the
> pair of “root” and “a password as strong as the two previous passwords together”. 
Well, there are a couple advantages for attacking the root account (and this is why
it's done so often).  

First, you already know the username.  That's sometimes half the puzzle!  You're
not trying to guess a username *and* a password but rather only trying to guess a
password.  You're halfway there already!  Now all you have to do is brute force the
password.

Second, if you get into the account you know you've struck gold.  You now,
effectively, own the system.  It's not like being able to login as a user and then
hoping that you might have sudo access to do other things (like change root's
password).

Allowing root access is just dangerous.  If someone really needs it they can turn it on
but I suspect many people don't even realize the access exists and
'fluffybunny' isn't going to keep their systems safe.

- --Eric

- --------------------------------------------------
Eric "Sparks" Christensen
Red Hat, Inc - Product Security

sparks(a)redhat.com - sparks(a)fedoraproject.org
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJUgHq7AAoJEB/kgVGp2CYv+SAL/147t4WKOIBnqFfEEJYxhe2w
> 9gEzXEmNuRdcipeKVI8oPIfS+wL6ygrxLWO4tYtwY+AK8oiLxhMokTt/ZW5Vqpgw
> dpnzfxSppq8VBtWW6s6o4bL1noa3Lphk2yvXp/vtc0BZjniMw9zP1FmasEmEbJw8
> 9lbANNRS63sFifLFEhSt3lIFCTwo8+XBur8FUtLiTthmb0hqiVDXWCTOoaMLSRJX
> WqxYBBUIH3xGVNoMQqQjSJyM96ryy4mUZdtd8nc/oklqnWYdZROjzLzl0uCpU6dF
> qsTMKzMEQbvZJYxEfG8pcIbzOHukC8aG8xb9r0J5/oPiwbtdC+qTMLGN3SoHPFA/
> 6WVMMH+aab/NDZ3M1/pWU24c0DeGCCqDSzL7ulOjkQZxPC2pj1pNTywXz3PNrSm2
> VaTF0Iga6yYsiRWNGT5lYCClDerSAfVOWI6QpSb+EvpOFQKcDcuvwUPUXWu/ivFv
> ZQaBOGuMvA4cyI7SCmQdPLVyvE/ZhEKx2tidcn1+3w==
> =cESf
> -----END PGP SIGNATURE-----

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 24 Nov 2014 12:37:24 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in&gt; wrote:

>     Hello,
>  
>  Please see
>    -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>  
>  Last week this was discussed in the FST meeting and on the
>  fedora-devel list subsequently. General consensus seems to be that it
>  is okay to disable remote 'root' login via sshd(8). Above feature
>  request is for the same.
>  
>  If you have any comments/suggestions/inputs, please feel free share
>  them or edit the feature page as required.
>  
I think it is a really bad idea, it will break many things for me
personally and I am sure others also. this is because I set a root
password at install time but do not create a user, I then ssh to the
box and join it to my ipa domain for user authentication. I will now be
unable to do so.

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJUkExqAAoJEH7ltONmPFDREwwP/j7+/POacUtGpnp/lF1rsKjy
> vkoNFMSk0OtxaaVWzh6D+Bphi4IGUapGGNqQEXGum4VFPsW5rnf9nPlEspp7YjkJ
> PXgtk64LJIU47hk2+2ckOr0sIWz3n+tUdLxhydlwNQ3gl+NqA7e/FLCn6USRhUKo
> 4vB6x4+0x8gKjcVv0Z/amapE1RPCwu79MU/ahJ6Hwjr0VpB+MifOgdc6zdr2Rffl
> WXr5ITiWaaobN60yhy4XWBmBc75u/DB2mMKChwwBUH0U7kKuKYCz1tfT0N3RZ2bS
> Wv78BJVrQp8C3xtyueSJTb7+DFrp1V3JsY6yJYbngpf+tSvWOw9xT4/Ier8x9V7q
> vpPSw+FFZMg3fWbaMSz1b+nP546ieU/h2PcfaIWw0P/1YwtzXo1TjKnD/QhhWu1E
> 4bag8wQ7cYE5Sr067kgqNnnQ1buZ0ACiK6ux2NqNe8+z2BOZ5OceLKIla5WgLcXF
> k9S6PIqJuM+CE+TrPZqwzSM2oTHTLIi7kJUmUf5B46oulfBD220j1Fo/obvq5iA8
> LBoHC53T+FGfF6PbHk3/DqguKdBFmXT5HgTkjWs7h6igUy9z6oE0radJCHHgxAUK
> bHzWdR39KsWo3G8C7ux/w4+/aQwoN0FA2pwmqorY6H8xjou1GYu7dfKpGCnBsrBy
> QqLnqoP2CVO1GoAetYJN
> =U7WI
> -----END PGP SIGNATURE-----
>

[Kurt Seifried]

Good point, this totally breaks anyone not using local authentication, I
think based on that this feature change really needs to be blocked.

On 16/12/14 08:14 AM, Dennis Gilmore wrote:
>  On Mon, 24 Nov 2014 12:37:24 +0000 (UTC)
>  P J P <pj.pandit(a)yahoo.co.in&gt; wrote:
>  
> >    Hello,
>  
> > Please see
> >   -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>  
> > Last week this was discussed in the FST meeting and on the
> > fedora-devel list subsequently. General consensus seems to be that it
> > is okay to disable remote 'root' login via sshd(8). Above feature
> > request is for the same.
>  
> > If you have any comments/suggestions/inputs, please feel free share
> > them or edit the feature page as required.
>  
>  I think it is a really bad idea, it will break many things for me
>  personally and I am sure others also. this is because I set a root
>  password at install time but do not create a user, I then ssh to the
>  box and join it to my ipa domain for user authentication. I will now be
>  unable to do so.
>  
>  Dennis
>  --
>  security mailing list
>  security(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/security
>   
-- 
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

[Simo Sorce]

On Mon, 24 Nov 2014 12:37:24 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in&gt; wrote:

>     Hello,
>  
>  Please see
>    -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>  
>  Last week this was discussed in the FST meeting and on the
>  fedora-devel list subsequently. General consensus seems to be that it
>  is okay to disable remote 'root' login via sshd(8). Above feature
>  request is for the same.
>  
>  If you have any comments/suggestions/inputs, please feel free share
>  them or edit the feature page as required. 
As said before this is not ok, it must be conditional to whether or not
a user has been created during the install.

If you cannot make it conditional then this feature should not proceed,
as it will simply break stuff for questionable gains in perceived
security.

After all, only power-users should use SSH so you could as well propose
we do not even start sshd by default. But we do, because it is used, so
breaking it is not a good idea.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[P J P]

>  On Tuesday, 16 December 2014 9:10 PM, Kurt Seifried wrote:
>  Good point, this totally breaks anyone not using local authentication, I
>  think based on that this feature change really needs to be blocked.
>  
>  
>  On 16/12/14 08:14 AM, Dennis Gilmore wrote:
> > I think it is a really bad idea, it will break many things for me
> > personally and I am sure others also. this is because I set a root
> > password at install time but do not create a user, I then ssh to the
> > box and join it to my ipa domain for user authentication. I will now be
> > unable to do so.
>   
>  
>  On Tuesday, 16 December 2014 9:19 PM, Simo Sorce wrote:
>  As said before this is not ok, it must be conditional to whether or not
>  a user has been created during the install. 

  Sure, idea is to make it conditional and not break thing too rough. In that, during the
boot process the user could be prompted to create a non-root account, to which he/she can
choose not to create one, in which case they would be warned about/against it.

>  After all, only power-users should use SSH so you could as well
> propose
>  we do not even start sshd by default. But we do, because it is used, so
>  breaking it is not a good idea. 

  Exactly! All the use cases above and similar others are typical power user's ones,
who can easily re-enable remote root login as and when required.

---
Regards
   -Prasad
http://feedmug.com

[Simo Sorce]

On Tue, 16 Dec 2014 17:21:00 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in&gt; wrote:

>  > On Tuesday, 16 December 2014 9:10 PM, Kurt Seifried wrote:
>  > Good point, this totally breaks anyone not using local
>  > authentication, I think based on that this feature change really
>  > needs to be blocked.
>  > 
>  > 
>  > On 16/12/14 08:14 AM, Dennis Gilmore wrote:
>  >> I think it is a really bad idea, it will break many things for me
>  >> personally and I am sure others also. this is because I set a root
>  >> password at install time but do not create a user, I then ssh to
>  >> the box and join it to my ipa domain for user authentication. I
>  >> will now be unable to do so.
>  > 
>  
>  >
>  
>  > On Tuesday, 16 December 2014 9:19 PM, Simo Sorce wrote:
>  > As said before this is not ok, it must be conditional to whether or
>  > not a user has been created during the install.
>  
>  
>    Sure, idea is to make it conditional and not break thing too rough.
>  In that, during the boot process the user could be prompted to create
>  a non-root account, to which he/she can choose not to create one, in
>  which case they would be warned about/against it. 
The thing need to be done during install, my servers boot unattended.

>  > After all, only power-users should use SSH so you could as well
>  > propose we do not even start sshd by default. But we do, because it
>  > is used, so breaking it is not a good idea.
>  
>    Exactly! All the use cases above and similar others are typical
>  power user's ones, who can easily re-enable remote root login as and
>  when required. 
No the key-word here is "easily", which is misguided.
It is not *easy* to have to jump through hoops to get a KVM/spice
connection to log in through the console to then go and change an
option.

It is not easy and it is not automatable, so you break a ton of
deployment/qa/automation scripts people rely on.

Unless you properly account for this I do not think you really have
consensus here.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[P J P]

>  On Tuesday, 16 December 2014 10:57 PM, Simo Sorce wrote:
>  The thing need to be done during install, my servers boot unattended.
>   
>  No the key-word here is "easily", which is misguided.
>  It is not *easy* to have to jump through hoops to get a KVM/spice
>  connection to log in through the console to then go and change an
>  option.
>  
>  It is not easy and it is not automatable, so you break a ton of
>  deployment/qa/automation scripts people rely on. 
 

  Sure, I agree. I'm not sure how these VM images are created and deployed,
but there must be some way to handle such cases,

  ex -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204663.html

As said before, intention is not to break things too rough and bother users.
But to make things secure while keeping them usable. If they are not usable,
what good is that security?

---
Regards
   -Prasad
http://feedmug.com

[Reindl Harald]

Am 17.12.2014 um 17:05 schrieb P J P:
> > On Tuesday, 16 December 2014 10:57 PM, Simo Sorce wrote:
> > The thing need to be done during install, my servers boot unattended.
>
> > No the key-word here is "easily", which is misguided.
> > It is not *easy* to have to jump through hoops to get a KVM/spice
> > connection to log in through the console to then go and change an
> > option.
> >
> > It is not easy and it is not automatable, so you break a ton of
> > deployment/qa/automation scripts people rely on.
>
>  Sure, I agree. I'm not sure how these VM images are created and deployed,
>  but there must be some way to handle such cases,
>
>  ex -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204663.html
>
>  As said before, intention is not to break things too rough and bother users.
>  But to make things secure while keeping them usable. If they are not usable,
>  what good is that security? 
Anaconda should just ask for sshd yes/no with defaults to no and in that 
case not enable the service at all

* forcing me to create a non-root user is a nogo
   there are machines where you never connect except for admin tasks

* "PermitRootLogin no" is idiotic  in any case because the safe setting
   "PermitRootLogin without-password" exists and enforces a private key
   while there is no public key without generate and install it

* well, and you need a first time root login with password to
   import such a key and then disable password login

hence just don't enable the service on each and every machine and ask 
the user if he needs a ssh server at install time - i know, in times 
where it's not popular to ask a user for anything not likely to happen

what will not work is magically guess the users intention and provide 
secure defaults at the same time, not now and not in the future

*ask users* and default to *no* because if someone say "yes" by 
intention it's his own responsibility to secure it

and *do not* touch existing configurations, never, in no context

i have seen networks going down because stupid named-maintainers decided 
to mangle "named.conf" by add dnssec options unasked with regular yum 
updates

[Simo Sorce]

On Wed, 17 Dec 2014 16:05:43 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in&gt; wrote:

>  > On Tuesday, 16 December 2014 10:57 PM, Simo Sorce wrote:
>  > The thing need to be done during install, my servers boot
>  > unattended.
>  > 
>  
>  > No the key-word here is "easily", which is misguided.
>  > It is not *easy* to have to jump through hoops to get a KVM/spice
>  > connection to log in through the console to then go and change an
>  > option.
>  > 
>  > It is not easy and it is not automatable, so you break a ton of
>  > deployment/qa/automation scripts people rely on.
>   
>  
>    Sure, I agree. I'm not sure how these VM images are created and
>  deployed, but there must be some way to handle such cases,
>  
>    ex ->
>  https://lists.fedoraproject.org/pipermail/devel/2014-November/204663.html 
These are specific cases, the problem is not crippling the general case.

>  As said before, intention is not to break things too rough and
> bother
>  users. But to make things secure while keeping them usable. If they
>  are not usable, what good is that security? 
Exactly, removing root access by default is not usable.
You can make it easy to disable it after the fact, or you can have
detection mechanisms to see if there are other ways into the system.

But you have to work to implement them, not block access by default and
then go tell people there are workarounds.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[P J P]

   Hi,

>  On Wednesday, 17 December 2014 11:55 PM, Simo Sorce  wrote:
>  https://lists.fedoraproject.org/pipermail/devel/2014-November/204663.html
>  These are specific cases, the problem is not crippling the general case. 
  General case?


As said before, I'm not sure how the VM images are created and deployed,
the tool I use to create minimal install VMs is

  this -> https://github.com/kashyapc/virt-scripts/blob/master/create-guest-qcow2.bash

%post --erroronfail

# Enable remote root login via sshd(8)
sed -i 's/^#PermitRootLogin/PermitRootLogin/' /etc/ssh/sshd_config
%end


And adding the above small patch to the kickstart file, enables the remote root login.


---

Regards
   -Prasad
http://feedmug.com