Hello,
Sshd(8) daemon by default allows remote users to login as root.
1. Is that really necessary? 2. Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
--- Regards -Prasad http://feedmug.com
On Fri, Nov 21, 2014 at 12:41 PM, P J P pj.pandit@yahoo.co.in wrote:
Hello,Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
- Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
Being a Fedora user on my personal machine as well as maintainer of a few Fedora machines in production environment, I would gladly welcome this. Many people do disable root login anyway. Having it default would be a positive step from security stand point.
On Fri, 21 Nov 2014 08:11:27 +0100, P J P wrote:
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
Almost all of my Fedora installations are test VMs where any security is irrelevant.
Just my use case, not saying if it is good or bad in general.
Jan
On 11/21/2014 08:34 AM, Jan Kratochvil wrote:
On Fri, 21 Nov 2014 08:11:27 +0100, P J P wrote:
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
Almost all of my Fedora installations are test VMs where any security is irrelevant.
Just my use case, not saying if it is good or bad in general.
I think it's a valid use case, but rather poorly supported at the moment. For example, there should be completely seemless SSH login from virt-manager for user-manageable virtual machines (both as root and the user).
My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on.
On Friday, 21 November 2014 1:24 PM, Florian Weimer wrote:
On 11/21/2014 08:34 AM, Jan Kratochvil wrote: Almost all of my Fedora installations are test VMs where any security is irrelevant.
Okay. But does enabling root login offer any significant benefit in that? IOW, if it's disabled by default, would it cause any significant inconvenience/troubles?? If not, it better be disabled by default.
I think it's a valid use case, but rather poorly supported at the moment. For example, there should be completely seemless SSH login from virt-manager for user-manageable virtual machines (both as root and the user).
My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on.
You mean off? Or that we disable it by default and enable it while setting up a new VM?
--- Regards -Prasad http://feedmug.com
On 11/21/2014 09:04 AM, P J P wrote:
My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on.
You mean off? Or that we disable it by default and enable it while setting up a new VM?
The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
On Fr, 2014-11-21 at 09:11 +0100, Florian Weimer wrote:
On 11/21/2014 09:04 AM, P J P wrote:
My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on.
You mean off? Or that we disable it by default and enable it while setting up a new VM?
The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
There is "PermitRootLogin without-password" too ...
cheers. Gerd
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote:
On 11/21/2014 09:04 AM, P J P wrote:
My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on.
You mean off? Or that we disable it by default and enable it while setting up a new VM?
The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
Virt-builder has a new '--ssh-inject' feature (in F22 only).
$ virt-builder fedora-20 --ssh-inject root
would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see:
http://libguestfs.org/virt-builder.1.html
Rich.
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
Virt-builder has a new '--ssh-inject' feature (in F22 only).
$ virt-builder fedora-20 --ssh-inject root
would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see:
Excellent! :)
So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
Thank you. ---
Regards -Prasad http://feedmug.com
Am 22.11.2014 um 09:24 schrieb P J P:
So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
Sorry for being late to the party.
I'm ok with no root login assuming that one can ssh into the machine (and become root somehow) after an install (this is along the lines of what Harald Reindl mentioned yesterday).
Seems that this means there must be some other user account on the system (or just use "PermitRootLogin without-password" which is my favorite option right now anyway). I guess you'll take care of that?
fs
On Saturday, 22 November 2014 4:29 PM, Felix Schwarz wrote I'm ok with no root login assuming that one can ssh into the machine (and become root somehow) after an install (this is along the lines of what Harald Reindl mentioned yesterday).
Yes, true. One would definitely need a non-user access to the system. Maybe by compulsory/default non-root user account creation.
Seems that this means there must be some other user account on the system (or just use "PermitRootLogin without-password" which is my favorite option right now anyway). I guess you'll take care of that?
Yes, we'll ensure that noone is locked out of their systems after a fresh install or upgrade.
Thank you. --- Regards -Prasad http://feedmug.com
Hi
On Sat, Nov 22, 2014 at 7:24 AM, P J P wrote:
Yes, we'll ensure that noone is locked out of their systems after a fresh install or upgrade.
This seems pretty tricky to ensure. Anaconda doesn't enforce an additional user because that could be done via the initial setup or gnome initial setup. IIRC, the interactions between them were pretty non obvious already.
Rahul
On Saturday, 22 November 2014 9:28 PM, Rahul Sundaram wrote:
This seems pretty tricky to ensure. Anaconda doesn't enforce an additional user because that could be done via the initial setup or gnome initial setup. IIRC, the interactions between them were pretty non obvious already.
Yes, true. We need to talk to them about it yet; still in the process. And that's why I was wondering if it needs to be a fully fledged feature? or just talking to upstream maintainers would do it? --- Regards -Prasad http://feedmug.com
Hi
Yes, true. We need to talk to them about it yet; still in the process. And that's why I was wondering if it needs to be a fully fledged feature? or just talking to upstream maintainers would do it?
I would suggesting going through the feature process. Although the config file change itself is trivial, there are multiple components that require coordination with several teams (Anaconda, Fedora Security team, openSSH, GNOME etc), testing and documentation. Having FESCo review a proposal is useful as well.
Rahul
On Sunday, 23 November 2014 1:59 AM, Rahul Sundaram wrote:
I would suggesting going through the feature process. Although the config file change itself is trivial, there are multiple components that require coordination with several teams (Anaconda, Fedora Security team, openSSH, GNOME etc), testing and documentation. Having FESCo review a proposal is useful as well.
Right, makes sense. I'll do that. I'm from Fedora Security Team above; that is where this topic/discussion came up and lead to this thread. Thank you. --- Regards -Prasad http://feedmug.com
On Monday, 24 November 2014 2:59 PM, P J P wrote:
On Sunday, 23 November 2014 1:59 AM, Rahul Sundaram wrote: I would suggesting going through the feature process... Having FESCo review a proposal is useful as well.
Right, makes sense. I'll do that.
Please see -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
--- Regards -Prasad http://feedmug.com
On Sat, 22 Nov 2014 08:24:32 +0000 (UTC) P J P pj.pandit@yahoo.co.in wrote:
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
Virt-builder has a new '--ssh-inject' feature (in F22 only).
$ virt-builder fedora-20 --ssh-inject root
would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see:
Excellent! :)
So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
Thank you.
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
Simo.
On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce simo@redhat.com wrote:
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
This has been the reason this hasn't been changed the last few times someone proposed to change it.
I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
This seems a more reasonable place to look to change this, I agree.
kevin
On Tue, 25 Nov 2014 08:23:22 -0700 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce simo@redhat.com wrote:
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
This has been the reason this hasn't been changed the last few times someone proposed to change it.
I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage.
My machines get joined to an IPA domain as soon as they are finished installing, I do *not* want a local user, it would be a liability.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
This seems a more reasonable place to look to change this, I agree.
kevin
On Tuesday, 25 November 2014 9:07 PM, Simo Sorce wrote: My machines get joined to an IPA domain as soon as they are finished installing, I do *not* want a local user, it would be a liability.
Well, I think this is more specific case for which remote 'root' login could be enabled by user.
--- Regards -Prasad http://feedmug.com
On Tuesday, 25 November 2014 8:53 PM, Kevin Fenzi wrote:
On Tue, 25 Nov 2014 09:56:59 -0500
Simo Sorce wrote:
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
This has been the reason this hasn't been changed the last few times someone proposed to change it.
I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
This seems a more reasonable place to look to change this, I agree.
True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that.
--- Regards -Prasad http://feedmug.com
On Tue, Nov 25, 2014 at 03:45:08PM +0000, P J P wrote:
True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that.
Keep in mind that in cloud, cloud-init does the same thing (instead of firstboot).
Hello Matthew,
On Tuesday, 25 November 2014 9:21 PM, Matthew Miller wrote: Keep in mind that in cloud, cloud-init does the same thing (instead of firstboot).
Ah I see, cool! --- Regards -Prasad http://feedmug.com
On 11/25/2014 09:45 AM, P J P wrote:
On Tuesday, 25 November 2014 8:53 PM, Kevin Fenzi wrote:
On Tue, 25 Nov 2014 09:56:59 -0500
Simo Sorce wrote:
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
This has been the reason this hasn't been changed the last few times someone proposed to change it.
I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
This seems a more reasonable place to look to change this, I agree.
True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that.
no need to create a user account in *all* installs
I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's,
so you propose when I reiinstall any of them create a user account in each of them,
that will cause boot the first time change to permit root login and delete the *forced* user account
and the server is hosted remotely, so if anything is wrong with it I can only access via ssh
so this *feature change* is no simple,
Hi,
On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's,
so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account
and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple,
True, it is complex.
Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5).
(Just a thought) --- Regards -Prasad http://feedmug.com
On Tue, 25 Nov 2014 17:05:59 +0000 (UTC) P J P pj.pandit@yahoo.co.in wrote:
Hi,
On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's,
so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account
and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple,
True, it is complex.
Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5).
(Just a thought)
If the user is not created you do not change the sshd_config defaults and let root log in. Simple, and does not break current kickstarts.
Simo.
On 25.11.2014 18:25, Simo Sorce wrote:
On Tue, 25 Nov 2014 17:05:59 +0000 (UTC) P J P pj.pandit@yahoo.co.in wrote:
Hi,
On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's,
so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account
and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple,
True, it is complex.
Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5).
(Just a thought)
If the user is not created you do not change the sshd_config defaults and let root log in. Simple, and does not break current kickstarts.
+1 This is a good idea. I maintain a lot of throw-away VMs which are installed automatically and creating yet another local account just to make someone happy would be really annoying.
On 11/25/2014 11:05 AM, P J P wrote:
Hi,
On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's,
so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account
and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple,
True, it is complex.
Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5).
(Just a thought)
Regards -Prasad http://feedmug.com
thanks, in my multiple re installs, I can live with the following:
an user prompt to create a user account and press no or setting an one more option in kickstart to prevent create a user account and change myself the ssh default to permit rootlogin to yes
but not with:
creating a user account by default logging with that account, change the sshd default to yes logoff logging with root delete the user account
On Tue, Nov 25, 2014 at 10:23 AM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce simo@redhat.com wrote:
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
This has been the reason this hasn't been changed the last few times someone proposed to change it.
I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
This seems a more reasonable place to look to change this, I agree.
kevin
No user config *and no console access* is where it breaks down. Most people who run real servers use either virtualization, which provides a form of console access, or remote KVM's, or have hands and eyes.
On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
On Sat, 22 Nov 2014 08:24:32 +0000 (UTC) P J P wrote:
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
Virt-builder has a new '--ssh-inject' feature (in F22 only).
$ virt-builder fedora-20 --ssh-inject root
would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see:
Excellent! :)
So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
Thank you.
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
It seems to me that we could tweak this somewhat: "only if a user account was created OR remote users have been configured"
On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit i.grok@comcast.net wrote:
On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
On Sat, 22 Nov 2014 08:24:32 +0000 (UTC) P J P wrote:
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
Virt-builder has a new '--ssh-inject' feature (in F22 only).
$ virt-builder fedora-20 --ssh-inject root
would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see:
Excellent! :)
So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
Thank you.
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
It seems to me that we could tweak this somewhat: "only if a user account was created OR remote users have been configured"
And in months that start with the letter "q", but not odd numbed weekdays, and if I ate a tuna fish sandwich for lunch, but not if I'm wearing white socks, and only on alternate years with a prime number, etc, etc., etc.
Look, this is a basic system configuration. It's not "Cripple Mr. Onion". Pick *one* setting, and let people know from that whether they'll need to manipulate their local environments for their particular subtle needs.
And for those who don't read Terry Pratchett stories, http://discworld.wikia.com/wiki/Cripple_Mr_Onion
----- Original Message -----
On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit i.grok@comcast.net wrote:
On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
On Sat, 22 Nov 2014 08:24:32 +0000 (UTC) P J P wrote:
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too.
Virt-builder has a new '--ssh-inject' feature (in F22 only).
$ virt-builder fedora-20 --ssh-inject root
would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see:
Excellent! :)
So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
Thank you.
We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible.
If you want to remove root access that should be conditionally done at firstboot only if a user account was created.
It seems to me that we could tweak this somewhat: "only if a user account was created OR remote users have been configured"
And in months that start with the letter "q", but not odd numbed weekdays, and if I ate a tuna fish sandwich for lunch, but not if I'm wearing white socks, and only on alternate years with a prime number, etc, etc., etc.
Look, this is a basic system configuration. It's not "Cripple Mr. Onion". Pick *one* setting, and let people know from that whether they'll need to manipulate their local environments for their particular subtle needs.
And for those who don't read Terry Pratchett stories, http://discworld.wikia.com/wiki/Cripple_Mr_Onion
Exactly! The more I think about this Change the more I am having an opinion that we should reject it altogether. In fact this change does not really bring any real security improvement because for the Workstation the sshd is already disabled completely by default and for the other products the people who are installing them can be expected to know what they are doing.
Also disabling root access does not improve security against targeted attacks because in such cases the user name can be quite easily inferred. So basically this feature is just a 'marketing' improvement and not worth the hassle.
Tomas Mraz
Hello Tomas,
On Thursday, 27 November 2014 3:05 PM, Tomas Mraz wrote:
----- Original Message ----- On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit wrote:
Look, this is a basic system configuration. It's not "Cripple Mr. Onion". Pick *one* setting, and let people know from that whether they'll need to manipulate their local environments for their particular subtle needs.
Exactly! The more I think about this Change the more I am having an opinion that we should reject it altogether. In fact this change does not really bring any real security improvement because for the Workstation the sshd is already disabled completely by default and for the other products the people who are installing them can be expected to know what they are doing.
That's not a prudent expectation.
Also disabling root access does not improve security against targeted attacks because in such cases the user name can be quite easily inferred. So basically this feature is just a 'marketing' improvement and not worth the hassle.
I disagree.
Just because it is easy to infer non-root user names does not mean we tell people it is 'root'. Secondly, it might be easy for you to infer such names, not for everyone. The increased difficulty level that is added by not allowing remote root login could help to thwart lot of real & automated attacks.[1] Thirdly, it need not have to be entirely about security, it's also about picking the right default configuration. Same as disabling sshd(8) in Workstation by default. As Scott wrote above
...Pick *one* setting, and let people know from that...
This feature, like any other, requires users to tweak their current practices to suite the new defaults. That is no reason to not do it; Because in the longer run it is only beneficial.
[1] https://lists.fedoraproject.org/pipermail/security/2014-November/002031.html --- Regards -Prasad http://feedmug.com
Am 27.11.2014 um 12:13 schrieb P J P:
Just because it is easy to infer non-root user names does not mean we tell people it is 'root'. Secondly, it might be easy for you to infer such names, not for everyone. The increased difficulty level that is added by not allowing remote root login could help to thwart lot of real & automated attacks.[1] Thirdly, it need not have to be entirely about security, it's also about picking the right default configuration. Same as disabling sshd(8) in Workstation by default. As Scott wrote above
so why not consider disable sshd at all and make a checkbox in Anaconda "ssh support yes/no" because after somebody says "yes" it's his clearly decision and he is responsible to secure it with key-only auth
i guess the answer will be "because too many options in the installer will harm" which i can't support - to less options IMHO harm forcing the user to look what is setup and how
On Thursday, 27 November 2014 4:49 PM, Reindl Harald wrote: so why not consider disable sshd at all and make a checkbox in Anaconda "ssh support yes/no" because after somebody says "yes" it's his clearly decision and he is responsible to secure it with key-only auth
Sure these are options, which need to be evaluated against their pros and cons.
For the 'Disable remote root login' option, this evaluation has been more positive than negative. Cases wherein it is negative, is mostly due to the tweaking that users would have to incorporate in their workflow, ex. explicitly enable remote root login after creating a new VM. This is easily doable because these users are fairly experienced ones. Idea is not to punish them for it, but to depend on their expertise rather than to expect that unknown users would/should know how to safe guard their systems.
Overall this feature adds more value to Fedora, than its perceived short term cost. --- Regards -Prasad http://feedmug.com
On Thu, Nov 27, 2014 at 8:06 AM, P J P pj.pandit@yahoo.co.in wrote:
On Thursday, 27 November 2014 4:49 PM, Reindl Harald wrote: so why not consider disable sshd at all and make a checkbox in Anaconda "ssh support yes/no" because after somebody says "yes" it's his clearly decision and he is responsible to secure it with key-only auth
Sure these are options, which need to be evaluated against their pros and cons.
For the 'Disable remote root login' option, this evaluation has been more positive than negative. Cases wherein it is negative, is mostly due to the tweaking that users would have to incorporate in their workflow, ex. explicitly enable remote root login after creating a new VM. This is easily doable because these users are fairly experienced ones. Idea is not to punish them for it, but to depend on their expertise rather than to expect that unknown users would/should know how to safe guard their systems.
Overall this feature adds more value to Fedora, than its perceived short term cost.
I agree, from a basic security standpoint, that it's the simplest change with the largest return on investment.
On 27/11/14 14:52, Nico Kadel-Garcia wrote: On Thu, Nov 27, 2014 at 8:06 AM, P J P pj.pandit@yahoo.co.in wrote:
Overall this feature adds more value to Fedora, than its perceived short term cost.
I agree, from a basic security standpoint, that it's the simplest change with the largest return on investment.
At some loss of usability. To often we hear "This is better for security, therefore we should do it" without considering the usability trade-off.
Andrew.
On Wednesday, 24 December 2014 3:07 PM, Andrew Haley wrote: At some loss of usability. To often we hear "This is better for security, therefore we should do it" without considering the usability trade-off.
It'll help if you could define this some loss of usability. If it is about remotely installed VM images, it's also discussed
here -> https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html
--- Regards -Prasad http://feedmug.com
On 24 Dec 2014, at 09:29, P J P wrote:
On Wednesday, 24 December 2014 3:07 PM, Andrew Haley wrote: At some loss of usability. To often we hear "This is better for security, therefore we should do it" without considering the usability trade-off.
It'll help if you could define this some loss of usability. If it is about remotely installed VM images, it's also discussed
here -> https://lists.fedoraproject.org/pipermail/security/2014- December/002061.html
Remotely installed on bare metal.
On Wednesday, 24 December 2014 11:01 PM, Mike Pinkerton wrote: Remotely installed on bare metal.
I see. Is there a provision that you could edit the kick-start file? Or supply parameters to it?? If so, it could be possible to enable remote root login post install. If not, let's see how we could address that.
Which tool is it? --- Regards -Prasad http://feedmug.com
On 11/21/2014 09:04 AM, P J P wrote:
On Friday, 21 November 2014 1:24 PM, Florian Weimer wrote:
On 11/21/2014 08:34 AM, Jan Kratochvil wrote: Almost all of my Fedora installations are test VMs where any security is irrelevant.
Okay. But does enabling root login offer any significant benefit in that? IOW, if it's disabled by default, would it cause any significant inconvenience/troubles?? If not, it better be disabled by default.
For example for me it would be some inconvenience. I also use a lot of Fedora VMs for testing and none of them has regular user, just root.
However I can see the benefits of disabling root login by default. Especially from the security point of view. I think it would be a good move.
Regards, Tomas
I think it's a valid use case, but rather poorly supported at the moment. For example, there should be completely seemless SSH login from virt-manager for user-manageable virtual machines (both as root and the user).
My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on.
You mean off? Or that we disable it by default and enable it while setting up a new VM?
Regards -Prasad http://feedmug.com
2014-11-21 8:11 GMT+01:00 P J P pj.pandit@yahoo.co.in:
Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
- Lot of users use their systems as root, without even creating a
non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
IIRC, the main reason for PermitRootLogin being enabled by default was to prevent a remote server from becoming inaccessible in cases such as a network mounted /home suddenly becoming unavailable.
Regards Christian
El 2014-11-21 08:49, Christian Rose escribió:
2014-11-21 8:11 GMT+01:00 P J P pj.pandit@yahoo.co.in:
Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
- Lot of users use their systems as root, without even creating
a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
IIRC, the main reason for PermitRootLogin being enabled by default was to prevent a remote server from becoming inaccessible in cases such as a network mounted /home suddenly becoming unavailable.
Also, the creation of a user is not enforced at installation, so you'll need to login as root in those cases
Am 21.11.2014 um 08:11 schrieb P J P:
Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
- Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
normally if you care for security you disable password logins at all, setup key-authentication and "PermitRootLogin without-password"
many machines i maintain only have a root account for login why? because they are servers for specific tasks and *any* non-root login would be followed by "su - root" anyways and for automated rsync scripts backing up data only root has access you need it also
for all of that you need a initial ssh login in most cases (except you work with a CD/DVD containing the key in case of a local install)
On 11/21/2014 09:42 AM, Reindl Harald wrote:
why? because they are servers for specific tasks and *any* non-root login would be followed by "su - root" anyways and for automated rsync scripts backing up data only root has access you need it also
For rsync-as-root use cases my usual approach is to create another account with userid=0 and login with ssh on this account. It is not root, but it has the same powers (because the numeric uid is the only thing it really matters).
Just wanted to share the trick.
Best regards.
Am 21.11.2014 um 11:55 schrieb Roberto Ragusa:
On 11/21/2014 09:42 AM, Reindl Harald wrote:
why? because they are servers for specific tasks and *any* non-root login would be followed by "su - root" anyways and for automated rsync scripts backing up data only root has access you need it also
For rsync-as-root use cases my usual approach is to create another account with userid=0 and login with ssh on this account. It is not root, but it has the same powers (because the numeric uid is the only thing it really matters).
Just wanted to share the trick
thanks, but that would alert in lynis checks
"PermitRootLogin without-password" after setup key-authentication should be the first action anyways - however i am neutral to any default here since on physical machines no problem and most remote machines are setup as virtual machine and so "local access"
the only important thing is to *really* make sure that there was a different account created - otherwise it could lead to a locked out installation in case of network setup after the first boot ______________________________________________________________
Lynis:
[+] Users, Groups and Authentication ------------------------------------ - Search administrator accounts [ OK ] - Checking for non-unique UIDs [ OK ] - Checking consistency of group files (grpck) [ OK ] - Checking non unique group ID's [ OK ] - Checking non unique group names [ OK ]
Am 21.11.2014 um 12:05 schrieb Reindl Harald:
Am 21.11.2014 um 11:55 schrieb Roberto Ragusa:
On 11/21/2014 09:42 AM, Reindl Harald wrote:
why? because they are servers for specific tasks and *any* non-root login would be followed by "su - root" anyways and for automated rsync scripts backing up data only root has access you need it also
For rsync-as-root use cases my usual approach is to create another account with userid=0 and login with ssh on this account. It is not root, but it has the same powers (because the numeric uid is the only thing it really matters).
Just wanted to share the trick
thanks, but that would alert in lynis checks
"PermitRootLogin without-password" after setup key-authentication should be the first action anyways - however i am neutral to any default here since on physical machines no problem and most remote machines are setup as virtual machine and so "local access"
not entirely neutral
"PermitRootLogin without-password" instead "PermitRootLogin no" has the same effect until "authorized_keys" got configured but avoids people going mad why the key-auth-setup don't work :-)
On 2014-11-21, 10:55 GMT, Roberto Ragusa wrote:
For rsync-as-root use cases my usual approach is to create another account with userid=0 and login with ssh on this account.
Proper way is actually to use command parameter in authorized_keys on server and for example https://ftp.samba.org/pub/unpacked/rsync/support/rrsync (or /usr/share/doc/rsync-*/support/rrsync)
The only thing attacker gets after cracking to the server is rsync prompt.
Best,
Matěj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 21 Nov 2014 07:11:27 +0000 (UTC) P J P pj.pandit@yahoo.co.in wrote:
Hello,Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
- Lot of users use their systems as root, without even creating a
non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
I think its a bad idea, but I say so as a user that when installing a new system, especially a remove vm will log in as root via ssh and join the machine post install to my ipa domain.
Dennis
On Sun, Nov 23, 2014 at 7:44 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 21 Nov 2014 07:11:27 +0000 (UTC) P J P pj.pandit@yahoo.co.in wrote:
Hello,Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
- Lot of users use their systems as root, without even creating a
non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
I think its a bad idea, but I say so as a user that when installing a new system, especially a remove vm will log in as root via ssh and join the machine post install to my ipa domain.
Dennis
This is an old, old, subject and debate in the SSH community. Every time people try to change defaults, it can and *wll* break existing practices, even if the defaults are a security problem and should have been changed a decade ago.
Personally? I'd *love* to see the default allow root direct login directly only from ""localhost". That means a 'Match Host' change to re-enable PermitRootLogin only if the connection is from localhost, which is a bit more sophisticated than just turning PermitRootlLogin on or off. Plus, I don't know if you've looked lately, but some people *really* screw up "localhost" settings in /etc/hosts as they try to get clever with shoving the FQDN into the loopback IP addresses, and hilarity ensues.
On 11/21/2014 08:11 AM, P J P wrote:
Hello,Sshd(8) daemon by default allows remote users to login as root.
- Is that really necessary?
The original bug report [1] was kept opened mainly due to the lack of adding user functionality in anaconda. This is no more true, anaconda has ability to add an user although it's not enforced.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=89216
- Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that.
There are several use cases when local non-root users are not needed at all as others already pointed out.
The change itself is simple however the problem is more complex overall. Here are some thoughts I have about the change:
- administrators are alerted when they use weak password for root by anaconda
- Fedora Workstation and Live installations don't enable sshd.service
- even if the default was 'PermitRootLogin without-password' you would need to inject an ssh key and when you are able to inject a key, you are able to change the default configuration
- I personally use several Fedora systems without non-root users in local network.
- default sudoers uses password of an user for authentication, so even when I have a non-root user in wheel group, I only need one user's password to become root
- how much users of these enforced users will be 'user' or 'test'?
Petr
On Tue, Nov 25, 2014 at 09:20:35PM +0100, Petr Lautrbach wrote:
There are several use cases when local non-root users are not needed at all as others already pointed out.
Including in some cases where there should both be no root password _and_ no local non-system users.
The change itself is simple however the problem is more complex overall. Here are some thoughts I have about the change:
- administrators are alerted when they use weak password for root by
anaconda
This has long been the case. However, if it explains _why_, I forget, for the same reason that this never works. (Yeah yeah whatever, I just want to install my system now and keep using "godmode" as my root password just like I always have so I don't forget it.)
[more snipped]
- default sudoers uses password of an user for authentication, so even
when I have a non-root user in wheel group, I only need one user's password to become root
This is also the case already.
-
Aditya Patawari -
Andrew Haley -
Christian Rose -
Dennis Gilmore -
Felix Schwarz -
Florian Weimer -
Gabriel Ramirez -
Gerd Hoffmann -
Jan Kratochvil -
Juan Orti Alcaine -
Kevin Fenzi -
Matthew Miller -
Matěj Cepl -
Mike Pinkerton -
Nico Kadel-Garcia -
P J P -
Petr Lautrbach -
Petr Spacek -
Rahul Sundaram -
Reindl Harald -
Richard W.M. Jones -
Roberto Ragusa -
Scott Schmit -
Simo Sorce -
Tomas Hozza -
Tomas Mraz