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
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.
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
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
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
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'.
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.)
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
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@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
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@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
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-that-s... [2] http://labs.sucuri.net/dump/sshd_bruteforce_list.txt?_ga=1.53033320.11590932...
On Tue, Nov 25, 2014 at 8:05 AM, Brandon Vincent Brandon.Vincent@asu.edu 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
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
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"
-----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@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
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
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
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.
(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
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.
-----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@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 24 Nov 2014 12:37:24 +0000 (UTC) P J P pj.pandit@yahoo.co.in 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
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@yahoo.co.in 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security
On Mon, 24 Nov 2014 12:37:24 +0000 (UTC) P J P pj.pandit@yahoo.co.in 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.
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
On Tue, 16 Dec 2014 17:21:00 +0000 (UTC) P J P pj.pandit@yahoo.co.in 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.
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
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
On Wed, 17 Dec 2014 16:05:43 +0000 (UTC) P J P pj.pandit@yahoo.co.in 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.
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
security@lists.fedoraproject.org
-
Brandon Vincent -
Dennis Gilmore -
Eric Christensen -
Hubert Kario -
Kurt Seifried -
Matthew Miller -
Miloslav Trmač -
P J P -
Petr Lautrbach -
Reindl Harald -
Richard Z -
Simo Sorce -
Tomas Mraz -
Tristan Santore