Hello,
> On Monday, 12 January 2015 4:09 PM, Ian Malone wrote:
> > On 12 January 2015 at 09:20, Milan Keršláger
>> 4) Blocking root access means forcing admins to log as normal user and
>> then do su/sudo and providing root password, which is far less secure
>> than disable root password aut
On 12 January 2015 at 09:20, Milan Keršláger wrote:
>> Hello,
>>
> 4) Blocking root access means forcing admins to log as normal user and
> then do su/sudo and providing root password, which is far less secure
> than disable root password authentication and allow login to root with
> SSH key
> 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
> usef
> 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
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
> 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
remo
On 27/11/14 14:52, Nico Kadel-Garcia wrote:
On Thu, Nov 27, 2014 at 8:06 AM, P J P 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 investmen
On Thu, Nov 27, 2014 at 8:06 AM, P J P 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 se
> 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 op
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
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
- Original Message -
> On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit wrote:
> > On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
> >> On Sat, 22 Nov 2014 08:24:32 + (UTC) P J P wrote:
> >> > > On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
> >> > >> On Fri
On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit wrote:
> On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
>> On Sat, 22 Nov 2014 08:24:32 + (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, Flo
On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
> On Sat, 22 Nov 2014 08:24:32 + (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 au
On 25.11.2014 18:25, Simo Sorce wrote:
> On Tue, 25 Nov 2014 17:05:59 + (UTC)
> 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 th
On Tue, Nov 25, 2014 at 10:23 AM, 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
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 i
On 11/21/2014 08:11 AM, P J P wrote:
> Hello,
>
> Sshd(8) daemon by default allows remote users to login as root.
>
> 1. 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
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 i
On Tue, 25 Nov 2014 17:05:59 + (UTC)
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 reiinst
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 c
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 be
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fed
> 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.
On Tue, Nov 25, 2014 at 03:45:08PM +, 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
> 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 has
On Tue, 25 Nov 2014 08:23:22 -0700
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'
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 d
On Sat, 22 Nov 2014 08:24:32 + (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_conf
> 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://fedoraproje
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), t
On Sun, Nov 23, 2014 at 7:44 PM, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 21 Nov 2014 07:11:27 + (UTC)
> P J P wrote:
>
>> Hello,
>>
>> Sshd(8) daemon by default allows remote users to login as root.
>>
>> 1. Is that really necessary?
>> 2. L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Nov 2014 07:11:27 + (UTC)
P J P wrote:
> 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-r
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 chang
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, t
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 init
> 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
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
> 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
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 disa
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/
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
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
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 approa
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 s
Am 21.11.2014 um 08:11 schrieb P J P:
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
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
El 2014-11-21 08:49, Christian Rose escribió:
2014-11-21 8:11 GMT+01:00 P J P :
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,
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 h
> 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 disab
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 V
2014-11-21 8:11 GMT+01:00 P J P :
> 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 logi
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 m
On Fri, Nov 21, 2014 at 12:41 PM, P J P wrote:
> 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,
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.
55 matches
Mail list logo
