6:42 a.m.
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security Team
To disable remote root login facility in sshd(8) by default.
== Detailed Description ==
Sshd(8) daemon allows remote users to login as 'root' by default. This
provides remote attackers an option to brute force their way into a system.
Empirically it is observed that many users use their systems via 'root' login,
without creating non-root user and often have weak passwords for this mighty
account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which controls
sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root
login by setting PermitRootLogin=no would help to harden Fedora systems,
moving it an inch closer towards 'secure by default' future. Users can have
non-root accounts with weak passwords too, yet disabling remote root login
keeps an attacker a step away from getting full control on a system. There is
another option of disabling user login via password and require usage of
cryptographic keys for the same. But that could a next step in future.
Please see -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
== Scope ==
* Proposal owners: to communicate with the Fedora maintainers of packages:
Anaconda, OpenSSH, GNOME, etc.
* Other developers: packages like Anaconda, GNOME etc. need to update their
workflow to enable compulsory non-root user account creation and ensure good
password strength for it.
* Release engineering: installer needs to ensure creation of non-root user
account with strong password. Similarly, all Fedora images must be created
with a non-root user account.
* Policies and guidelines: unknown yet.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
7:42 a.m.
On Thu, 8 Jan 2015, Jaroslav Reznik wrote:
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security Team
To disable remote root login facility in sshd(8) by default.
I still disagree with this feature.
== Detailed Description ==
Sshd(8) daemon allows remote users to login as 'root' by default. This
provides remote attackers an option to brute force their way into a system.
If you want to fight that, you need to set PasswordAuthentication no and
insist that people start using ssh keypairs instead.
Singling out root is not affective against system compromises caused by
brutce forcing passwords. While it might take a little longer for an
attacker to guess username+password (how many of you have a
username of more than 6 characters) once the non-root user password is
brute-forced they will most likely gain root via either passwordless
sudo or by creating some ~/bin/su wrapper that steals the password when
the real user logs on.
The defense against password attacks is to not permit password authentication.
Disallowing root access will interfere with legitimate root logins, for
example automated backup logins, or remote administration tools like
puppet or ansible that require root access.
Paul
8:46 a.m.
Le Thursday 08 January 2015 08:42:45 Paul Wouters a écrit :
If you want to fight that, you need to set PasswordAuthentication no
and
insist that people start using ssh keypairs instead.
Would not the following satisfy everybody?
Match User root
PasswordAuthentication no
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
8:52 a.m.
Once upon a time, Laurent Rineau <laurent.rineau__fedora(a)normalesup.org> said:
Le Thursday 08 January 2015 08:42:45 Paul Wouters a écrit :
> If you want to fight that, you need to set PasswordAuthentication no and
> insist that people start using ssh keypairs instead.
Would not the following satisfy everybody?
Match User root
PasswordAuthentication no
Simpler version (if the change is desired):
PermitRootLogin without-password
--
Chris Adams <linux(a)cmadams.net>
9:35 a.m.
Am 08.01.2015 um 15:52 schrieb Chris Adams:
Once upon a time, Laurent Rineau
<laurent.rineau__fedora(a)normalesup.org> said:
> Le Thursday 08 January 2015 08:42:45 Paul Wouters a écrit :
>> If you want to fight that, you need to set PasswordAuthentication no and
>> insist that people start using ssh keypairs instead.
>
> Would not the following satisfy everybody?
>
> Match User root
> PasswordAuthentication no
Simpler version (if the change is desired):
PermitRootLogin without-password
that was suggested multiple times here instead "no" and i don't get why
the topic insists to turn around "PermitRootLogin=no" after so many weeks
3:01 p.m.
On Thursday 08 January 2015 08:52:22 Chris Adams wrote:
Simpler version (if the change is desired):
PermitRootLogin without-password
BTW, Debian introduced this default for the upcoming Debian/jessie.
Ref: Review for "PermitRootLogin without-password" change
[https://lists.debian.org/debian-ssh/2014/03/msg00024.html]
So another small benefit is increased uniformity in Linux and less surprises for new
admins.
--
Oron Peled Voice: +972-4-8228492
oron(a)actcom.co.il http://users.actcom.co.il/~oron
"A standard for copy protection is as premature as a standard for
teleportation."
--- Noted computer security expert and Princeton University Professor Edward Felten.
9:13 a.m.
On 01/08/2015 08:42 AM, Paul Wouters wrote:
On Thu, 8 Jan 2015, Jaroslav Reznik wrote:
> == Detailed Description ==
> Sshd(8) daemon allows remote users to login as 'root' by default. This
> provides remote attackers an option to brute force their way into a
> system.
If you want to fight that, you need to set PasswordAuthentication no and
insist that people start using ssh keypairs instead.
Singling out root is not affective against system compromises caused by
brutce forcing passwords.
There's another aspect of this, namely
accountability. In realistic
environments usually several people have admin privileges and
password-based root access is hard to manage---e.g. you need to change
root password everywhere when the sysadmin team changes.
The defense against password attacks is to not permit password
authentication.
Disallowing root access will interfere with legitimate root logins, for
example automated backup logins, or remote administration tools like
puppet or ansible that require root access.
For the automation cases I like Chris
Adams' suggestion:
PermitRootLogin without-password
9:37 a.m.
On Thu, 8 Jan 2015, Przemek Klosowski wrote:
If you want to fight that, you need to set
PasswordAuthentication no and
insist that people start using ssh keypairs instead.
Singling out root is not affective against system compromises caused by
brutce forcing passwords.
There's another aspect of this, namely accountability.
There are many aspects in the global discussio of ssh keys versus sudo
versus passwords. I was trying to stick to the feature request and its
justification. Using root with ssh keys has a perfectly fine audit trail
that shows whether you or I logged in as root using ssh. We don't need
the sudo audit trail for that.
In realistic environments usually several people
have admin privileges and password-based root access is hard to manage---e.g. you need to
change root
password everywhere when the sysadmin team changes.
I don't think anyone is arguing in favour of keeping root password based
logins as the default. It's just too dangerous.
The defense against password attacks is to not permit password
authentication.
Disallowing root access will interfere with legitimate root logins, for
example automated backup logins, or remote administration tools like
puppet or ansible that require root access.
For the automation cases I like Chris Adams' suggestion:
PermitRootLogin without-password
I'm also fine with that. However, that does not address the ssh scripts
that are trying to login as various well-known or short usernames, most
of which will have sudo rights once broken. While this feature is named
"Set sshd(8) PermitRootLogin=no" what is really meant is "disable
password logins leading to root access due to dictionary attacks".
So if we truly want to address this feature, we should also disallow
non-root user password based ssh logins.
Paul
11:28 p.m.
On 01/08/2015 04:37 PM, Paul Wouters wrote:
So if we truly want to address this feature, we should also disallow
non-root user password based ssh logins.
Do I get this right? You want to disallow
any remote logins (which
nowadays means using ssh)?
How are people supposed to perform remote dist-upgrades rsp. remote
adminstration?
Ralf
11:52 p.m.
> So if we truly want to address this feature, we should also
disallow
> non-root user password based ssh logins.
Do I get this right? You want to disallow any remote logins (which
nowadays means using ssh)?
No, he means that ssh connections should require a pre-shared key. My
systems are set up that way, you can't just ssh in from anywhere, you
can only ssh in from machines that have your private key. If you try
to log in without a pre-shared key, it won't prompt you for your unix
password, it will just fail.
8:14 a.m.
On Fri, 9 Jan 2015, DJ Delorie wrote:
>> So if we truly want to address this feature, we should also
disallow
>> non-root user password based ssh logins.
>
> Do I get this right? You want to disallow any remote logins (which
> nowadays means using ssh)?
No, he means that ssh connections should require a pre-shared key.
Actually, i meant keypair based authentication with ssh using
authorized_keys (which are NOT preshared keys - it is public key
authentication)
My systems are set up that way, you can't just ssh in from
anywhere, you
can only ssh in from machines that have your private key. If you try
to log in without a pre-shared key, it won't prompt you for your unix
password, it will just fail.
If your public key authentication fails, it still prompts you for a
password but even if you have set a password it will reject it. This is
to prevent leaking configuration information (eg to avoid telling
attackers whether or not password based logins are allowed in the
machine)
Paul
8:22 a.m.
Am 09.01.2015 um 15:14 schrieb Paul Wouters:
If your public key authentication fails, it still prompts you for a
password but even if you have set a password it will reject it. This is
to prevent leaking configuration information (eg to avoid telling
attackers whether or not password based logins are allowed in the
machine)
not true if your server is correctly configured and enforces key-auth
[root@rawhide ~]# ssh root(a)local.rhsoft.net
Permission denied (publickey).
[root@rawhide ~]#
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
X11Forwarding no
RSAAuthentication yes
PubkeyAuthentication yes
PermitEmptyPasswords no
PermitRootLogin without-password
8:32 a.m.
On Fri, Jan 9, 2015 at 4:14 PM, Paul Wouters <paul(a)nohats.ca> wrote:
My systems are set up that way, you can't just ssh in from
anywhere, you
> can only ssh in from machines that have your private key. If you try
> to log in without a pre-shared key, it won't prompt you for your unix
> password, it will just fail.
>
If your public key authentication fails, it still prompts you for a
password but even if you have set a password it will reject it. This is
to prevent leaking configuration information (eg to avoid telling
attackers whether or not password based logins are allowed in the
machine)
I got a little confused here. I also have my server systems set up to only
use keys. Is it possible to have that along with a "dummy" password prompt
that always fails? If yes, which directives in sshd configuration
accomplish that?
8:51 a.m.
Am 09.01.2015 um 15:32 schrieb Alexander Ploumistos:
On Fri, Jan 9, 2015 at 4:14 PM, Paul Wouters wrote:
My systems are set up that way, you can't just ssh in from
anywhere, you
can only ssh in from machines that have your private key. If
you try
to log in without a pre-shared key, it won't prompt you for your
unix
password, it will just fail.
If your public key authentication fails, it still prompts you for a
password but even if you have set a password it will reject it. This is
to prevent leaking configuration information (eg to avoid telling
attackers whether or not password based logins are allowed in the
machine)
I got a little confused here. I also have my server systems set up to
only use keys. Is it possible to have that along with a "dummy" password
prompt that always fails? If yes, which directives in sshd configuration
accomplish that?
you achieve nothing than cluttered logs from continued dictionary
attacks with such a setup even if it would be possible and that has the
security implication burry interesting lines in noise
with the response like below a smart zombie would just stop
[root@rawhide ~]# ssh root(a)local.rhsoft.net
Permission denied (publickey).
[root@rawhide ~]#
8:59 a.m.
On Fri, Jan 9, 2015 at 4:51 PM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
you achieve nothing than cluttered logs from continued dictionary
attacks
with such a setup even if it would be possible and that has the security
implication burry interesting lines in noise
Oh, I agree with you, but it would be quite nice to have in a honeypot,
combined with sshd listening on port 22, so I'm still curious if it is
feasible (and how).
9:07 a.m.
Am 09.01.2015 um 15:59 schrieb Alexander Ploumistos:
On Fri, Jan 9, 2015 at 4:51 PM, Reindl Harald wrote:
you achieve nothing than cluttered logs from continued dictionary
attacks with such a setup even if it would be possible and that has
the security implication burry interesting lines in noise
Oh, I agree with you, but it would be quite nice to have in a honeypot,
combined with sshd listening on port 22, so I'm still curious if it is
feasible (and how)
for that i would seek a dedicated honeypot-service listening on port 22
with it's own logging and have the real sshd with key-only auth on a
non-default port
https://code.google.com/p/kippo/
https://github.com/desaster/kippo
that has also the benefit even in case of a bug in sshd itself that you
have all the crap on a different code base not be real sshd at all
9:56 a.m.
On Fri, Jan 9, 2015 at 5:07 PM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
for that i would seek a dedicated honeypot-service listening on port
22
with it's own logging and have the real sshd with key-only auth on a
non-default port
https://code.google.com/p/kippo/
https://github.com/desaster/kippo
that has also the benefit even in case of a bug in sshd itself that you
have all the crap on a different code base not be real sshd at all
Thanks for the links, I had only used Kojoney in the past. I will give it a
go as soon as possible. But now I have another question, well actually it
is the same one, but from a different point of view: Is it possible to
misconfigure sshd in such a way that a client who tries to connect to the
server from an unauthorized system keeps typing their username and
password, wondering why they can't get in? If yes, which directives in
sshd_config should be changed to avoid this problem?
7:43 a.m.
On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote:
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security Team
To disable remote root login facility in sshd(8) by default.
== Detailed Description ==
Sshd(8) daemon allows remote users to login as 'root' by default. This
provides remote attackers an option to brute force their way into a system.
Empirically it is observed that many users use their systems via 'root' login,
without creating non-root user and often have weak passwords for this mighty
account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which controls
sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root
login by setting PermitRootLogin=no would help to harden Fedora systems,
moving it an inch closer towards 'secure by default' future. Users can have
non-root accounts with weak passwords too, yet disabling remote root login
keeps an attacker a step away from getting full control on a system. There is
another option of disabling user login via password and require usage of
cryptographic keys for the same. But that could a next step in future.
Please see ->
https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
== Scope ==
* Proposal owners: to communicate with the Fedora maintainers of packages:
Anaconda, OpenSSH, GNOME, etc.
* Other developers: packages like Anaconda, GNOME etc. need to update their
workflow to enable compulsory non-root user account creation and ensure good
password strength for it.
* Release engineering: installer needs to ensure creation of non-root user
account with strong password. Similarly, all Fedora images must be created
with a non-root user account.
* Policies and guidelines: unknown yet.
Can we clarify something here? Is this a request to change the defaults
globally for all Products/nonproduct installs?
I would argue that it could be sensible to do this for Workstation and
non-product installs, but not for Server and Cloud.
In the Server case, nearly every deployment is headless. Disabling root
login to ssh by default would mean that many people would have no way to
get into the system at all. (Yes, we could force the creation of a
non-root user at install time, but this user would by necessity be an
administrator capable of becoming root via sudo, so the distinction
is... fuzzy). The only other approach I could see for the headless
servers would be mandating the enrollment in an identity domain at
installation time (such as to FreeIPA or Active Directory).
Neither of those approaches is anything like ideal, so I would argue
that Server should continue to operate with the SSH root login being
available by default, but perhaps add documentation to the install guide
recommending to disable it if other accounts are available; perhaps even
by adding a simple kickstart directive (but no UI element) to accomplish
this.
We can also consider opening an RFE against realmd, so that if the
machine becomes enrolled in a domain, it disables the remote root login
by default. I'm not sure about that, however.
In the case of Cloud, I think the point is basically moot, since
cloud-init should be handling all the relevant setup for this in any
case.
tl;dr:
Let's make this change happen with a per-product config default, with
Workstation and Non-product setups disabling root SSH login by default.
Server should leave SSH login enabled (arguably conditional on whether
or not the user enrolls in a domain).
7:48 a.m.
On Thu, Jan 08, 2015 at 08:43:48AM -0500, Stephen Gallagher wrote:
Can we clarify something here? Is this a request to change the
defaults
globally for all Products/nonproduct installs?
I would argue that it could be sensible to do this for Workstation and
non-product installs, but not for Server and Cloud.
In the Server case, nearly every deployment is headless. Disabling root
login to ssh by default would mean that many people would have no way to
get into the system at all. (Yes, we could force the creation of a
non-root user at install time, but this user would by necessity be an
administrator capable of becoming root via sudo, so the distinction
is... fuzzy). The only other approach I could see for the headless
servers would be mandating the enrollment in an identity domain at
installation time (such as to FreeIPA or Active Directory).
Having a non-root account with sudo is already more secure because the
attacker would have to guess the username in addition to the password.
Neither of those approaches is anything like ideal, so I would argue
that Server should continue to operate with the SSH root login being
available by default, but perhaps add documentation to the install guide
recommending to disable it if other accounts are available; perhaps even
by adding a simple kickstart directive (but no UI element) to accomplish
this.
I disagree. I think requiring a non-root account w/Admin to be
created is the best way to go.
7:56 a.m.
On Thu, 2015-01-08 at 08:48 -0500, Chuck Anderson wrote:
On Thu, Jan 08, 2015 at 08:43:48AM -0500, Stephen Gallagher wrote:
> Can we clarify something here? Is this a request to change the defaults
> globally for all Products/nonproduct installs?
>
> I would argue that it could be sensible to do this for Workstation and
> non-product installs, but not for Server and Cloud.
>
> In the Server case, nearly every deployment is headless. Disabling root
> login to ssh by default would mean that many people would have no way to
> get into the system at all. (Yes, we could force the creation of a
> non-root user at install time, but this user would by necessity be an
> administrator capable of becoming root via sudo, so the distinction
> is... fuzzy). The only other approach I could see for the headless
> servers would be mandating the enrollment in an identity domain at
> installation time (such as to FreeIPA or Active Directory).
Having a non-root account with sudo is already more secure because the
attacker would have to guess the username in addition to the password.
That's a perfect example of "security through obscurity". You are making
the false assumption that just because the username isn't 'root', it is
somehow difficult to identify. I'll grant you, this will make it harder
for a simple automated script-kiddie to get in, but it won't hamper a
targeted attack very much.
> Neither of those approaches is anything like ideal, so I would
argue
> that Server should continue to operate with the SSH root login being
> available by default, but perhaps add documentation to the install guide
> recommending to disable it if other accounts are available; perhaps even
> by adding a simple kickstart directive (but no UI element) to accomplish
> this.
I disagree. I think requiring a non-root account w/Admin to be
created is the best way to go.
That is functionally equivalent to a root account. Once the user has the
password, they will just use 'sudo' with that same password. The battle
has been lost. The *only* change that this effects is to add some
guesswork to the username.
8:40 a.m.
On Thu, Jan 8, 2015 at 8:43 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>
> Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security Team
>
> To disable remote root login facility in sshd(8) by default.
>
> == Detailed Description ==
> Sshd(8) daemon allows remote users to login as 'root' by default. This
> provides remote attackers an option to brute force their way into a system.
> Empirically it is observed that many users use their systems via 'root'
login,
> without creating non-root user and often have weak passwords for this mighty
> account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which
controls
> sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root
> login by setting PermitRootLogin=no would help to harden Fedora systems,
> moving it an inch closer towards 'secure by default' future. Users can have
> non-root accounts with weak passwords too, yet disabling remote root login
> keeps an attacker a step away from getting full control on a system. There is
> another option of disabling user login via password and require usage of
> cryptographic keys for the same. But that could a next step in future.
>
> Please see ->
https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
>
> == Scope ==
> * Proposal owners: to communicate with the Fedora maintainers of packages:
> Anaconda, OpenSSH, GNOME, etc.
> * Other developers: packages like Anaconda, GNOME etc. need to update their
> workflow to enable compulsory non-root user account creation and ensure good
> password strength for it.
> * Release engineering: installer needs to ensure creation of non-root user
> account with strong password. Similarly, all Fedora images must be created
> with a non-root user account.
> * Policies and guidelines: unknown yet.
Can we clarify something here? Is this a request to change the defaults
globally for all Products/nonproduct installs?
I would argue that it could be sensible to do this for Workstation and
non-product installs, but not for Server and Cloud.
IIRC, the Cloud images don't have a root password set, which means you
can't log in as root at all by default. They have their cloud_init
thing, which is supposed to copy ssh keys onto the image. So unless
I'm confused (which is possible because my understanding is...
cloudy), the Cloud product is essentially already more strict than
this feature proposes.
Let's make this change happen with a per-product config default,
with
Workstation and Non-product setups disabling root SSH login by default.
Server should leave SSH login enabled (arguably conditional on whether
or not the user enrolls in a domain).
We can take this back to Workstation for discussion I guess.
josh
10:10 a.m.
On Thu, 2015-01-08 at 08:43 -0500, Stephen Gallagher wrote:
In the Server case, nearly every deployment is headless. Disabling
root
login to ssh by default would mean that many people would have no way to
get into the system at all. (Yes, we could force the creation of a
non-root user at install time, but this user would by necessity be an
administrator capable of becoming root via sudo, so the distinction
is... fuzzy).
It might be fuzzy but I don't think it's meaningless. Consider ssh's
X11 forwarding. Prior to CVE-2013-19{81,97} libX11 had bugs where it
would trust the server's replies to be correctly formatted, which meant
the _server_ could exploit the _client_. Since in X the server is the
display, this means if I can commandeer the user session then I can
exploit the machine being ssh'd _to_.
Cisco routers don't log you in directly to enable mode, even if there's
no password. OSX runs your session as a user even though it gives you
sudo by default. What's so different about Fedora Server that we should
ignore common best practice?
The only other approach I could see for the headless
servers would be mandating the enrollment in an identity domain at
installation time (such as to FreeIPA or Active Directory).
And in this scenario we should absolutely disable PermitRootLogin.
- ajax
10:20 a.m.
On Thu, 2015-01-08 at 11:10 -0500, Adam Jackson wrote:
On Thu, 2015-01-08 at 08:43 -0500, Stephen Gallagher wrote:
> In the Server case, nearly every deployment is headless. Disabling root
> login to ssh by default would mean that many people would have no way to
> get into the system at all. (Yes, we could force the creation of a
> non-root user at install time, but this user would by necessity be an
> administrator capable of becoming root via sudo, so the distinction
> is... fuzzy).
It might be fuzzy but I don't think it's meaningless. Consider ssh's
X11 forwarding. Prior to CVE-2013-19{81,97} libX11 had bugs where it
would trust the server's replies to be correctly formatted, which meant
the _server_ could exploit the _client_. Since in X the server is the
display, this means if I can commandeer the user session then I can
exploit the machine being ssh'd _to_.
Cisco routers don't log you in directly to enable mode, even if there's
no password. OSX runs your session as a user even though it gives you
sudo by default. What's so different about Fedora Server that we should
ignore common best practice?
The difference is that it's presently uncommon for users to install a
non-root *local* user account on the system. Most people will use 'root'
to get the system bootstrapped into being able to talk to a central
identity system (some flavor of Active Directory, FreeIPA or LDAP) and
then manage sudo rules from there.
Requiring us to ship with a new local user would mean a problematic
UID/GID overlap in a LOT of environments. (Since the vast majority of
companies just dump their previous /etc/passwd files into LDAP without
changing IDs, the UID 500 or 1000 is probably already in use and is now
essentially a backdoor root account).
So I stick with my original statement: if we enroll in a domain during
installation (using realmd), we can disable remote root logins and trust
that the authn/z provided by that domain handles privilege escalation
appropriately. If we are NOT in a domain right from the start, it's
potentially unsafe to introduce another user and that should be left to
the admin to resolve interactively.
(And for those of you who might suggest just using a sub-500 ID for this
special user, that has its own set of issues around the history of the
PAM stack and would be highly problematic).
> The only other approach I could see for the headless
> servers would be mandating the enrollment in an identity domain at
> installation time (such as to FreeIPA or Active Directory).
And in this scenario we should absolutely disable PermitRootLogin.
I don't think we disagree here. The only problem of course is one of
bootstrapping: how do you set up a FreeIPA domain controller on the
first machine...
12:29 p.m.
On Thu, 08 Jan 2015 11:10:36 -0500
Adam Jackson <ajax(a)redhat.com> wrote:
> The only other approach I could see for the headless
> servers would be mandating the enrollment in an identity domain at
> installation time (such as to FreeIPA or Active Directory).
And in this scenario we should absolutely disable PermitRootLogin.
So that if you have issues with the connector, you have to reboot the
machine and be physically present to fix anything.
Not really a grand plan IMO.
I may be ok with allowing only passwoedless by default, though I still
think this feature should be conditional to whether there are other
local accounts or not.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:52 p.m.
> > The only other approach I could see for the headless
> > servers would be mandating the enrollment in an identity domain at
> > installation time (such as to FreeIPA or Active Directory).
>
> And in this scenario we should absolutely disable PermitRootLogin.
So that if you have issues with the connector, you have to reboot the
machine and be physically present to fix anything.
Not really a grand plan IMO.
Earlier in the discussions I was told that this is not really an issue: in production,
about every server with remote access also has a KVM.
Mirek
1:38 p.m.
On Thu, 2015-01-08 at 13:52 -0500, Miloslav Trmač wrote:
> > > The only other approach I could see for the headless
> > >
servers would be mandating the enrollment in an identity domain at > >
> installation time (such as to FreeIPA or Active Directory). > > > >
And in this scenario we should absolutely disable PermitRootLogin. > >
So that if you have issues with the connector, you have to reboot the >
machine and be physically present to fix anything. > > Not really a
grand plan IMO.
Earlier in the discussions I was told that this is not really an issue:
in production, about every server with remote access also has a KVM.
Mirek
I don't think that's necessarily true. I've seen plenty of sites where
they have a literal, physical "crash cart" they have to wheel out to
plug in when remote access is broken.
2:34 p.m.
On 8 January 2015 at 11:52, Miloslav Trmač <mitr(a)redhat.com> wrote:
> > > The only other approach I could see for the headless
> > > servers would be mandating the enrollment in an identity domain at
> > > installation time (such as to FreeIPA or Active Directory).
> >
> > And in this scenario we should absolutely disable PermitRootLogin.
>
> So that if you have issues with the connector, you have to reboot the
> machine and be physically present to fix anything.
>
> Not really a grand plan IMO.
Earlier in the discussions I was told that this is not really an issue: in
production, about every server with remote access also has a KVM.
Mirek
I would say that whoever told you that was being way too optimistic
Just in Fedoraproject's 150 servers we have run into quite a few common
issues.
0) Every KVM requires Java. Some only work with java-1.4 or java-1.5 or
java6 or.. And the current Fedora version isn't supported. Java
implementation has quirks which sometimes repeat keys, skip keys, drop
keys, etc. Easy to figure out in regular commands, impossible with hidden
root passwords. Java implementation does not accept pasteing from
clipboard. Passwords longer than 8 characters end up being multiple
attempts.
1) System has KVM. KVM has decided not to work with client for some reason.
[bad connector, the KVM is taking a smoke break and will work after it has
been physically rebooted, etc]
2) System does not allow for KVM. It is serial only... repeat the above two
problems we run into KVM just replace with serial.
3) System is not connected to any KVM but uses off-line management (drac,
asm, imm, etc). Repeat 0/1 for those.
In most of the cases, we end up requiring someone to go to the system
physically and doing some initial work if we run into any of 0-3. Of course
that works great if you have a physical server. We virtualize most of our
servers which ends up with even more weird problems of trying to get
working.
This isn't just Fedora's systems.. I know of large clusters of boxes where
they have a 'monkey tender' whose job is pretty much going around all day
doing this for some system somewhere because KVM works 99% of the time and
when you have over 100 servers you end up with some percentage not working.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
4:19 p.m.
Am 08.01.2015 um 21:34 schrieb Stephen John Smoogen:
In most of the cases, we end up requiring someone to go to the
system
physically and doing some initial work if we run into any of 0-3. Of
course that works great if you have a physical server. We virtualize
most of our servers which ends up with even more weird problems of
trying to get working
than you do something wrong
especially om virtualized systems remote management is far easier
because you have *one* remote console and if it is regular tested and
all clients have the needed access you reach 100,1000,10000 virtual
servers without any exception
but back to topic: yes it is *way* too optimistic assume KVM or similar
everywhere - for a small business you typically have a *server* as
router/firewall *because* you want to avoid the security problems of
make crap without regular updates directly reachable from the internet
and that includes:
* SOHO routers
* KVM devices
* any embedded device
* VMware consoles
so guess what there is running: a ordinary Linux setup (in my case)
Fedora and the only way to access some of them hundrets of kilometers
away is just SSH
4:54 p.m.
On 8 January 2015 at 15:19, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 08.01.2015 um 21:34 schrieb Stephen John Smoogen:
> In most of the cases, we end up requiring someone to go to the system
> physically and doing some initial work if we run into any of 0-3. Of
> course that works great if you have a physical server. We virtualize
> most of our servers which ends up with even more weird problems of
> trying to get working
>
than you do something wrong
Of course I do Harald. Very few of us are perfect. Thank you for reminding
me of my failures. It has made me a better person.
especially om virtualized systems remote management is far easier
because
you have *one* remote console and if it is regular tested and all clients
have the needed access you reach 100,1000,10000 virtual servers without any
exception
Another thread, but it would be useful if you explained how this is
accomplished.
but back to topic: yes it is *way* too optimistic assume KVM or
similar
everywhere - for a small business you typically have a *server* as
router/firewall *because* you want to avoid the security problems of make
crap without regular updates directly reachable from the internet and that
includes:
* SOHO routers
* KVM devices
* any embedded device
* VMware consoles
so guess what there is running: a ordinary Linux setup (in my case) Fedora
and the only way to access some of them hundrets of kilometers away is just
SSH
this we agree on.
--
Stephen J Smoogen.
5:09 p.m.
Am 08.01.2015 um 23:54 schrieb Stephen John Smoogen:
On 8 January 2015 at 15:19, Reindl Harald wrote:
Am 08.01.2015 um 21:34 schrieb Stephen John Smoogen:
In most of the cases, we end up requiring someone to go to the
system
physically and doing some initial work if we run into any of 0-3. Of
course that works great if you have a physical server. We virtualize
most of our servers which ends up with even more weird problems of
trying to get working
than you do something wrong
Of course I do Harald. Very few of us are perfect. Thank you for
reminding me of my failures. It has made me a better person.
i ignore the cynicism :-)
especially om virtualized systems remote management is far
easier
because you have *one* remote console and if it is regular tested
and all clients have the needed access you reach 100,1000,10000
virtual servers without any exception
Another thread, but it would be useful if you explained how this is
accomplished.
in my "serious" environments which are all virtualized it is simple:
* a central VMware vCenter Server for the HA cluster
* that thing is sadly a windows machine, don't matter
because it's only purpose is to run a RDP session
and all day long the VMware client connected to the
vCenter
* for sure you can achieve the same with pure open-source
well, and if it comes to connections:
* normally VPN over one of the guests
* as fallback SSH-Forwarding to 3389 from one of the guests
dedicated for that and on a different host another guest
which is allowed to connect to the admin machine on 3389
* if you once get a RDP connection wether via VPN or fallback
to SSH forwarding you have a single management interface to
watch and maintain the cluster including a virtual console
to each VM with a single klick
* the virtual console is from the view of the guest the same
as if you would sit in front of it - enter root-pwd and
you are in a from the guests from local terminal
* there is even a Linux based vCenter server running itself on
top of the HA cluster and so have also failover, not sure
about the client access just because the current admin server
is running since summer 2008 up-to-date and unchanged
finally the only thing i need to take care of is having the same
hypervisor versions on the bare metal hosts, if a host goes down
the guests are started from a available one like after a power outage
if the host get unreachable over the network the hosts are configured to
issue a clean shutdown command on the guests because the bare metal
hypervisor will start them within a few minutes on a remaining host
well, as said, you can for sure achieve the same with pure open source
but since i have to maintain all the stuff practically alone i prefer a
froma trusted local vendor supported solution for virtualization,
hardware and shared storage
but back to topic: yes it is *way* too optimistic assume KVM or
similar everywhere - for a small business you typically have a
*server* as router/firewall *because* you want to avoid the security
problems of make crap without regular updates directly reachable
from the internet and that includes:
* SOHO routers
* KVM devices
* any embedded device
* VMware consoles
so guess what there is running: a ordinary Linux setup (in my case)
Fedora and the only way to access some of them hundrets of
kilometers away is just SSH
this we agree on
11:56 a.m.
On 01/08/2015 06:09 PM, Reindl Harald wrote:
in my "serious" environments which are all virtualized it is simple:
* a central VMware vCenter Server for the HA cluster
* that thing is sadly a windows machine, don't matter
because it's only purpose is to run a RDP session
and all day long the VMware client connected to the
vCenter
* for sure you can achieve the same with pure open-source
Right, just a SMOP....
NOT.
Actually, even with vCenter (which we also have) getting a console is
not a foregone conclusion. It is a browser plugin which actually right
now does not work for me on my linux desktop.
On second thought, perhaps you're suggesting what I often do, RDP to a
windows machine with vCenter, which does work, but is less than elegant:
RDP from machine 1 to a virtual machine 2, accessing a hypervisor
running on physical host 3 that accesses a virtual machine 4.
1:31 p.m.
Once upon a time, Przemek Klosowski <przemek.klosowski(a)nist.gov> said:
Actually, even with vCenter (which we also have) getting a console
is not a foregone conclusion. It is a browser plugin which actually
right now does not work for me on my linux desktop.
Hmm, the Fedora Project isn't using RHEV/oVirt, which supports VNC and
SPICE for consoles? :)
My method of managing physical servers is to make sure they all have at
least basic IPMI with serial-over-LAN and BIOS-serial-console support,
and then configure the boot loader and bare-metal Linux with serial
consoles. Dell iDRAC or SuperMicro with remote KVM is a bonus (allows
virtual media and such). All the IPMI/etc. interfaces are on a private
VLAN accessible through a jump host or VPN (because lots of them are
out-of-date embedded Linux with security issues). Then I have an oVirt
cluster for VMs, so I can pull up a SPICE console.
That covers my needs, except for legacy stuff at customer locations, but
we're working to get that stuff replaced too (with same IPMI/iDRAC/etc.
requirement).
--
Chris Adams <linux(a)cmadams.net>
8:50 p.m.
On Thu, Jan 08, 2015 at 01:34:14PM -0700, Stephen John Smoogen wrote:
We virtualize most of our
servers which ends up with even more weird problems of trying to get
working.
Could you expand on these problems you have with virtualized systems?
I wrote a tool called virt-rescue which should handle many problematic
situations. And virtualized systems should have reliable serial ports
(if not - please file a bug!) But we are always looking to improve
the tools.
http://libguestfs.org/virt-rescue.1.html
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
2:04 p.m.
On 8 Jan 2015, at 13:52, Miloslav Trmač wrote:
>>> The only other approach I could see for the headless
>>> servers would be mandating the enrollment in an identity domain at
>>> installation time (such as to FreeIPA or Active Directory).
>>
>> And in this scenario we should absolutely disable PermitRootLogin.
>
> So that if you have issues with the connector, you have to reboot the
> machine and be physically present to fix anything.
>
> Not really a grand plan IMO.
Earlier in the discussions I was told that this is not really an
issue: in production, about every server with remote access also
has a KVM.
Often not the case in small business or third party hosted
environments. Without remote ssh, box is unmanageable.
Even if you want to do key-based authentication rather than password,
you still need to use password initially to get the key onto the
remote box.
--
Mike Pinkerton
11:01 a.m.
On Saturday, 10 January 2015 1:34 AM, Mike Pinkerton wrote:
Even if you want to do key-based authentication rather than password,
you still need to use password initially to get the key onto the
remote box.
True!
---
Regards
-Prasad
http://feedmug.com
2:57 a.m.
>>>> The only other approach I could see for the headless
>>>> servers would be mandating the enrollment in an identity domain at
>>>> installation time (such as to FreeIPA or Active Directory).
>>>
>>>
>>> And in this scenario we should absolutely disable PermitRootLogin.
>>
>>
>> So that if you have issues with the connector, you have to reboot the
>> machine and be physically present to fix anything.
>>
>> Not really a grand plan IMO.
>
>
> Earlier in the discussions I was told that this is not really an issue: in
> production, about every server with remote access also has a KVM.
Often not the case in small business or third party hosted environments.
Without remote ssh, box is unmanageable.
Even if you want to do key-based authentication rather than password, you
still need to use password initially to get the key onto the remote box.
If you use cloud-init you can specify an initial public key that it
inserts against, or even auto enrol it in a central auth system like
IPA and hence not ever need a password.
Peter
2:56 a.m.
Hello,
On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
>> Earlier in the discussions I was told that this is not really an issue: in
>> production, about every server with remote access also has a KVM.
>
> Often not the case in small business or third party hosted environments.
> Without remote ssh, box is unmanageable.
>
> Even if you want to do key-based authentication rather than password, you
> still need to use password initially to get the key onto the remote box.
If you use cloud-init you can specify an initial public key that it
inserts against, or even auto enrol it in a central auth system like
IPA and hence not ever need a password.
So, the major issue(or blocker should we say?) is the virtualized deployments. If there
is no solution in sight, maybe last resort is to enable remote root login, possibly in the
'%post' install section of the kick-start file.
Does it seem like an appropriate solution?
---
Regards
-Prasad
http://feedmug.com
3:40 a.m.
No, this is not good idea as I wrote few minutes ago because it does not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity
I wonder why no-one responded like me, because this was discussed many
times ago. Well maybe many times since 1995 (when SSH was born) and
maybe I'm a little bit old so I read it many times again and again.
It seems like SSH does not make padding sufficiently, but this changes
nothing on what I wrote.
Disabling root loging does not solve the problem and it profides only
false feeling of security.
M.K.
Dne 12.1.2015 v 09:56 P J P napsal(a):
Hello,
> On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
>>> Earlier in the discussions I was told that this is not really an issue: in
>>> production, about every server with remote access also has a KVM.
>> Often not the case in small business or third party hosted environments.
>> Without remote ssh, box is unmanageable.
>>
>> Even if you want to do key-based authentication rather than password, you
>> still need to use password initially to get the key onto the remote box.
> If you use cloud-init you can specify an initial public key that it
> inserts against, or even auto enrol it in a central auth system like
> IPA and hence not ever need a password.
So, the major issue(or blocker should we say?) is the virtualized deployments. If there
is no solution in sight, maybe last resort is to enable remote root login, possibly in the
'%post' install section of the kick-start file.
Does it seem like an appropriate solution?
---
Regards
-Prasad
http://feedmug.com
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
4:48 a.m.
Hi,
That's not security through obscurity. It's a way to limit the exposure to
a brute force attack with an a privileged account.
Also this allows the user uses a different account so remote attacks that
user is unknown and can not be used to brute force delimiting more
exposure.
Most instances cloud providers do this basically, like EC2 where the normal
user for a predefined fedora cloud instance is 'fedora' (
public key-based authentication).
Whenever possible need to limit remote access, and one of the most
important points are the privileges of these remote access.
It must be guaranteed a minimum of security for all users
(Desktop/Cloud/Whatever).
Should be the responsibility of the administrator to enable this remote
access.
--
Francisco Alonso.
http://twitter.com/revskills
PGP: 0xE2E64DCA
--
On Mon, Jan 12, 2015 at 10:40 AM, Milan Keršláger <milan.kerslager(a)pslib.cz>
wrote:
No, this is not good idea as I wrote few minutes ago because it does
not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity
I wonder why no-one responded like me, because this was discussed many
times ago. Well maybe many times since 1995 (when SSH was born) and
maybe I'm a little bit old so I read it many times again and again.
It seems like SSH does not make padding sufficiently, but this changes
nothing on what I wrote.
Disabling root loging does not solve the problem and it profides only
false feeling of security.
M.K.
Dne 12.1.2015 v 09:56 P J P napsal(a):
> Hello,
>
>> On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
>>>> Earlier in the discussions I was told that this is not really an
issue: in
>>>> production, about every server with remote access also has a KVM.
>>> Often not the case in small business or third party hosted
environments.
>>> Without remote ssh, box is unmanageable.
>>>
>>> Even if you want to do key-based authentication rather than password,
you
>>> still need to use password initially to get the key onto the remote
box.
>> If you use cloud-init you can specify an initial public key that it
>> inserts against, or even auto enrol it in a central auth system like
>> IPA and hence not ever need a password.
> So, the major issue(or blocker should we say?) is the virtualized
deployments. If there is no solution in sight, maybe last resort is to
enable remote root login, possibly in the '%post' install section of the
kick-start file.
>
> Does it seem like an appropriate solution?
> ---
> Regards
> -Prasad
> http://feedmug.com
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Francisco Alonso.
http://twitter.com/revskills
PGP: 0xE2E64DCA
--
5:45 a.m.
Hello Milan,
On Monday, 12 January 2015 3:11 PM, Milan Keršláger wrote:
No, this is not good idea as I wrote few minutes ago because it does not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity
I disagree. First of all, there is no _obscurity_ in it. Obscurity would have been if we
just changed name of the 'root' user to something else, say Admin/Superuser/Batman
etc.
This feature _restricts_ remote root access to a machine. It is a preventive measure; Just
like having SELinux or firewall or disabling services which are not used. Look at it as
being analogous to two factor authentication. It involves two steps to gain remote root
access to a machine, instead of one. This preventive measure can thwart real brute force
attacks. Which is a net gain in terms of safety to users.
Disabling root loging does not solve the problem and it profides only
Which problem? It seems you've different understanding of its purpose.
On Monday, 12 January 2015 4:18 PM, Francisco Alonso wrote:
That's not security through obscurity. It's a way to limit
the exposure to a brute force attack with an a privileged account.
Also this allows the user uses a different account so remote
attacks that user is unknown and can not be used to brute
force delimiting more exposure.
Exactly!
Thank you.---
Regards
-Prasad
http://feedmug.com
6:28 a.m.
You pointed to SELinux and two factor authentication to be like your
solution (ie disabling root login), but these tools (SELinux/twofactor
auth.) are build to completly mitigate the attack (the attacker is
unable to perform the needed action in any way).
You are (instead of completly mitigating), only raising complexity a
little bit (ie not completly avoiding), which is what is "Security
through obscurity" about (ie. by hiding source code, the attacker only
solve more complex problem - debugging machine code).
One more time: The system can be cracked by BF attack only if there is a
weak (root) password.
If you disable remote root login (bacause users are using weak crackable
password), you are saying to the user: "Happily use simple password
because you are safe even that!". And because when admin password could
be simple then the user password will be more simpler (this is
average-user-logic) and the BF against the system will succeed more
easily (even the login name will need to be guessed or picked by another
way). So your solution is potentionally more dangerous than current
situation.
If you want to avoid the problem (ie avoid BF crack-in), disabling
remote root login is not the right way, this is simply not enough, this
does not solve the problem. There are better solutions I wrote about
already (prefferrably to not expose SSH to the wild by default).
Milan
Dne 12.1.2015 v 12:45 P J P napsal(a):
Hello Milan,
> On Monday, 12 January 2015 3:11 PM, Milan Keršláger wrote:
> No, this is not good idea as I wrote few minutes ago because it does not
> improve security, it just provide feeling of better security, see:
> https://en.wikipedia.org/wiki/Security_through_obscurity
I disagree. First of all, there is no _obscurity_ in it. Obscurity would have been if
we just changed name of the 'root' user to something else, say
Admin/Superuser/Batman etc.
This feature _restricts_ remote root access to a machine. It is a preventive measure;
Just like having SELinux or firewall or disabling services which are not used. Look at it
as being analogous to two factor authentication. It involves two steps to gain remote root
access to a machine, instead of one. This preventive measure can thwart real brute force
attacks. Which is a net gain in terms of safety to users.
> Disabling root loging does not solve the problem and it profides only
Which problem? It seems you've different understanding of its purpose.
On Monday, 12 January 2015 4:18 PM, Francisco Alonso wrote:
> That's not security through obscurity. It's a way to limit
> the exposure to a brute force attack with an a privileged account.
> Also this allows the user uses a different account so remote
> attacks that user is unknown and can not be used to brute
> force delimiting more exposure.
Exactly!
Thank you.---
Regards
-Prasad
http://feedmug.com
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
7:05 a.m.
On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
You are (instead of completly mitigating), only raising complexity a
little bit (ie not completly avoiding), which is what is "Security
through obscurity" about (ie. by hiding source code, the attacker only
solve more complex problem - debugging machine code).
One more time: The system can be cracked by BF attack only if there is a
weak (root) password.
Sure. As guessed, you misunderstood the intention. The feature is _not_ a remedy against
brute force attacks. But it is a remedy for keeping such attackers from gaining
'root' access on remote machines. The feature says,
"...Disabling remote root login by setting PermitRootLogin=no would help to harden
Fedora systems, moving it an inch closer towards 'secure by default' future. Users
can have non-root accounts with weak passwords too, yet disabling remote root login keeps
an attacker a step away from getting full control on a system..."
The feature helps to _harden_ Fedora systems. Same as filtering traffic via firewall or
restricting undue access via SELinux etc.
If you disable remote root login (bacause users are using weak
crackable
password), you are saying to the user: "Happily use simple password
because you are safe even that!". And because when admin password could
be simple then the user password will be more simpler (this is
average-user-logic) and the BF against the system will succeed more
easily (even the login name will need to be guessed or picked by another
way). So your solution is potentionally more dangerous than current
situation.
That is a lot of speculation and hypothesis. In now way does this feature imply or
indicate to users that they can use weak passwords.
If you want to avoid the problem (ie avoid BF crack-in), disabling
remote root login is not the right way, this is simply not enough, this
does not solve the problem. There are better solutions I wrote about
already (prefferrably to not expose SSH to the wild by default).
Again, issue being addressed is not of brute force attacks. But that of such attacks
resulting in gaining 'root' access to remote machines. They are two distinct
issues.
---
Regards
-Prasad
http://feedmug.com
8:46 a.m.
On 01/12/2015 08:05 AM, P J P wrote:
Again, issue being addressed is not of brute force attacks. But that
of such attacks resulting in gaining 'root' access to remote machines.
They are two distinct issues.
There still needs to be an administrative access to the system, and the
most common implementation by enabling 'sudo' on the non-privileged
account. So, in a sense you are both right: this feature is just a small
step rather than a security panaceum, but it does bring real
improvements in several areas:
- increases difficulty of the attack by banning stupid automated BF
attacks on root
- improves accountability for administrative actions (we know which
admin messed up :)
- allows more granularity in granting elevated privileges across a set
of machines and admins
9:02 a.m.
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
There still needs to be an administrative access to the system, and
the most common implementation by enabling 'sudo'
on the non-privileged account. So, in a sense you are both right: this feature is just a
small step rather than a
security panaceum, but it does bring real improvements in several areas:
Disagree :P
- increases difficulty of the attack by banning stupid automated BF
attacks on root
do you use PrzemekKlosowski as your username on your fedora? I doubt it.
It is more likely to be przemek, klosowski or pklosowski. In fact, often
this is revealed in mail headers (eg "sendmail invoked by user paul").
More often, people will have 2 to 4 character usernames.
So this information is far from secret, and easilly guessable. Compared
to the dictionary this does in fact not make the problem any harder at
all. However, you have made legitimate automated root logins much harder
now, like me calling rsync as root for backups, which are not easilly
done wrapped in sudo :P
- improves accountability for administrative actions (we know which
admin messed up :)
Nonsense. for non-malicious logins, sudo leaves as much as a trail as
sshd which tells you which credentials were used to login. For malicious
logins, once root access is obtained via password-less sudo, the
evidence is removed from the logs. sudo offering a better audit trail is
a misconception that's been around for years.
- allows more granularity in granting elevated privileges across a
set of machines and admins
Nothing in the current setup is preventing you from allowing non-root
remote access. Blocking direct root access does not "allow more granularity".
You already have all the granularity if you want to use it.
Paul
10:51 a.m.
On Monday, 12 January 2015 8:32 PM, Paul Wouters wrote:
do you use PrzemekKlosowski as your username on your fedora? I doubt it.
It is more likely to be przemek, klosowski or pklosowski. In fact, often
this is revealed in mail headers (eg "sendmail invoked by user paul").
More often, people will have 2 to 4 character usernames.
So this information is far from secret, and easilly guessable.
Agreed Paul, yet it does not mean cracking them would be as easy as slicing knife
through butter. That too for every awkward joe trying their hands at it. It sounds like
all one has to do is just guess the username, and it's game over. It is _not_! There
is user's password, and root account's password. Not every non-root user has
sudo(1) access. Besides when they use browser based mail clients, such information is
less likely to be disclosed.
As said before, few might be able to crack it, but others would _fail_ at it. And that
failure is our net gain. Secondly, this restriction would encourage people to use non-root
user accounts and help spread awareness about having strong passwords. Thirdly, as said in
another thread, if we resort to using keys based authentication for 'root'
account, it would lead to people using same mechanism for other accounts too.
Overall in the long term, today's small change will have better cumulative returns.
Compared to the dictionary this does in fact not make the problem any
harder at
all. However, you have made legitimate automated root logins much harder
now, like me calling rsync as root for backups, which are not easilly
done wrapped in sudo :P
I wonder why rsync needs root account? If it's not easily done wrapped in sudo, why
is brute forcing unknown username, its password and then root account relatively easier?
(rhetorical questions, don't answer)
Point is, if one must have to have only 'root' account in their set-up, they can
always enable remote 'root' login by setting PermitRootLogin=yes. Just like how
people flush firewall rules. There are various ways of doing that.
Let's try to figure out how we could facilitate that with more convenience, rather
than looping over same arguments about how the feature improves security or not.
For malicious logins, once root access is obtained via password-less
sudo,
the evidence is removed from the logs.
What..automatically? Or the assumption is that the attacker is the smartest soul on
earth??
---
Regards
-Prasad
http://feedmug.com
11:48 a.m.
On Mon, 12 Jan 2015, P J P wrote:
Agreed Paul, yet it does not mean cracking them would be as easy as
slicing knife through butter. That too for every awkward joe trying their hands at it. It
sounds like all one has to do is just guess the username, and it's game over.
Exactly! Then we are back at the level of "need to brutce force a
password" just like in the root case.
There is user's password, and root account's password. Not
every non-root user has sudo(1) access. Besides when they use browser based mail clients,
such information is less likely to be disclosed.
For most compromises, root is not needed. Most hacking attempts are
attempts for resources (cpu, bandwidth) not anything requiring root.
As said before, few might be able to crack it, but others would
_fail_ at it. And that failure is our net gain.
I understand the net gain (a factor of about 1000 for commonly used
usernames) in a botnet attack. In other words, a tiny tiny net gain.
Anyway. I'm not against blocking password root. I'm against blocking
root with ssh keys. Which has nothing to do with bruce forcing,
other than being collateral damage with PermitRootLogin=no.
Secondly, this restriction would encourage people to use non-root
user accounts and help spread awareness about having strong passwords.
What if I told you Neo, that there are no strong passwords?
Passwords are weak. Some are less weak than others. I'd rather
teach people to use ssh keys for remote access and only restrict
passwords to console/physical access. That would be a good
security lesson to teach.
Thirdly, as said in another thread, if we resort to using keys based
authentication for 'root' account, it would lead to people using same mechanism
for other accounts too.
Excellent! even less password guessing possible!
Overall in the long term, today's small change will have better
cumulative returns.
And again, ignoring the collateral damage. As people suggested, keep ssh
key based root logins allowed.
> Compared to the dictionary this does in fact not make the problem
any harder at
> all. However, you have made legitimate automated root logins much harder
> now, like me calling rsync as root for backups, which are not easilly
> done wrapped in sudo :P
I wonder why rsync needs root account?
Because it is making a backup of files, some of which are only readable
by root?
If it's not easily done wrapped in sudo, why is brute forcing
unknown username, its password and then root account relatively easier? (rhetorical
questions, don't answer)
That's okay, I answered it twice already in this email :P
Point is, if one must have to have only 'root' account in
their set-up, they can always enable remote 'root' login by setting
PermitRootLogin=yes. Just like how people flush firewall rules. There are various ways of
doing that.
1) you want to disable password logins for root
2) you paint the bikeshed green
3) people tell you they can't get into the bikeshead
4) you say, but it's safer green!
Let's try to figure out how we could facilitate that with more
convenience, rather than looping over same arguments about how the feature improves
security or not.
You can accomplish disabling password based remote root logins by
disabling password based remote root logins:
PermitRootLogin without-password
This matches exactly what the feature is supposed to protect against -
bruce forced password attacks against root. I have not heard anyone
in this thread yet saying this is unacceptable, except for your vague
claim of 'it would lead to people using same mechanism for other
accounts too' (which I interpret as good, not bad)
> For malicious logins, once root access is obtained via
password-less sudo,
> the evidence is removed from the logs.
What..automatically? Or the assumption is that the attacker is the smartest soul on
earth??
It's not my argument. You brought in the "sudo is superior over ssh
authenticated key logins for auditing reasons" argument. It's not mine.
Paul
12:18 p.m.
Hello Paul,
On Monday, 12 January 2015 11:18 PM, Paul Wouters wrote:
What if I told you Neo, that there are no strong passwords?
Passwords are weak. Some are less weak than others. I'd rather
teach people to use ssh keys for remote access and only restrict
passwords to console/physical access. That would be a good
security lesson to teach.
Sure, I'm all for it.
> Thirdly, as said in another thread, if we resort to using keys
based
authentication for 'root' account, it would lead to people using same
mechanism for other accounts too.
Excellent! even less password guessing possible!
Exactly!
And again, ignoring the collateral damage. As people suggested, keep
ssh
key based root logins allowed.
Sure, that's absolutely fine with me. It seems maybe you missed my earlier email
wherein I said, how we restrict remote 'root' access is negotiable.
-> https://lists.fedoraproject.org/pipermail/devel/2015-January/206224.html
So 'PermitRootLogin=without-password' is good too.
You can accomplish disabling password based remote root logins by
disabling password based remote root logins:
PermitRootLogin without-password
This matches exactly what the feature is supposed to protect against -
bruce forced password attacks against root. I have not heard anyone
in this thread yet saying this is unacceptable, except for your vague
claim of 'it would lead to people using same mechanism for other
accounts too' (which I interpret as good, not bad)
He..he..yes, even I meant it as an added advantage. As said before,
'PermitRootLogin=without-passoword' is fine for me too. :)
So, if everybody agrees with 'PermitRootLogin=without-password' as the _default_
sshd(8) configuration, maybe we could discuss about other workflow issues,
that might crop up as result.
---
Regards
-Prasad
http://feedmug.com
3:39 p.m.
> - improves accountability for administrative actions (we know
which admin
> messed up :)
Nonsense. for non-malicious logins, sudo leaves as much as a trail as
sshd which tells you which credentials were used to login. For malicious
logins, once root access is obtained via password-less sudo, the
evidence is removed from the logs.
… which is why good large-scale setups immediately send logs away from the machine to a
dedicated log host.
True, given our current design, which does not block the log in on successful log
write/flush, this becomes a race between sending the logs and the attacker logging in and
trying to abort the log sending operation.
Also I realize that many (single-user and small data center) setups do not have such a log
host; still, the OS should be designed to make such auditing at least possible, and making
it easy enough to eliminate direct logins to the root account (whether using a password or
a key) would go in that direction.
Mirek
4:48 p.m.
First of all, I agree with you that PermitRootLogin without-password is
preferable.
The discussion I am interested in is whether direct password root login
should remain enabled.
On 01/12/2015 10:02 AM, Paul Wouters wrote:
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
> - improves accountability for administrative actions (we know which
> admin messed up :)
Nonsense. for non-malicious logins, sudo leaves as much as a trail as
sshd which tells you which credentials were used to login.
With root logins, all you have on the client machine is the IP the
connection originated from. If people have to get in on their own
accounts, those accounts leave audit trails, on multiple systems.
More importantly, there is one root for all users---if one user needs to
be blocked (e.g. sysadmin quits), the only solution is to change the
root password everywhere. Individual accounts can be controlled
independently, especially in setups with centralized account management
like Kerberos/IPA.
> - allows more granularity in granting elevated privileges across a
> set of machines and admins
Nothing in the current setup is preventing you from allowing non-root
remote access. Blocking direct root access does not "allow more
granularity".
You already have all the granularity if you want to use it.
But if the
single-password root is enabled, why would anyone use those
granular methods?
5:07 p.m.
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
First of all, I agree with you that PermitRootLogin without-password
is preferable.
Good :)
The discussion I am interested in is whether direct password root
login should remain enabled.
With root logins, all you have on the client machine is the IP the
connection originated from.
$ ssh root@localhost
Last failed login: Mon Jan 12 17:25:40 EST 2015 from 61.174.50.244 on ssh:notty
There were 3862 failed login attempts since the last successful login.
Last login: Sat Jan 10 11:36:43 2015 from thinkpad.nohats.ca
root@bofh:~# tail /var/log/audit/audit.log
type=CRYPTO_SESSION msg=audit(1421103620.649:1371831): pid=7380 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start
direction=from-client cipher=aes128-ctr ksize=128 mac=hmac-md5-etm(a)openssh.com spid=7381
suid=74 rport=60353 laddr=127 exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1
terminal=? res=success'
type=CRYPTO_SESSION msg=audit(1421103620.649:1371832): pid=7380 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start
direction=from-server cipher=aes128-ctr ksize=128 mac=hmac-md5-etm(a)openssh.com spid=7381
suid=74 rport=60353 laddr=127 exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1
terminal=? res=success'
type=USER_AUTH msg=audit(1421103620.721:1371833): pid=7380 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey_auth
rport=60353 acct="root" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1
terminal=? res=success'
type=USER_AUTH msg=audit(1421103620.721:1371834): pid=7380 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=key algo=ssh-dss
size=1024 fp=13:67:ff:08:9d:8d:4a:32:77:3e:0a:09:81:a6:bc:4a rport=60353
acct="root" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=?
res=success'
type=USER_ACCT msg=audit(1421103620.741:1371835): pid=7380 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:accounting
acct="root" exe="/usr/sbin/sshd" hostname=bofh.nohats.ca addr=::1
terminal=ssh res=success'
type=CRYPTO_KEY_USER msg=audit(1421103620.742:1371836): pid=7380 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy
kind=session fp=? direction=both spid=7381 suid=74 rport=60353 laddr=127.0.0.1 lport=22
exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=? res=success'
Note the: fp=13:67:ff:08:9d:8d:4a:32:77:3e:0a:09:81:a6:bc:4a
paul@bofh:~$ ssh-keygen -l -f .ssh/id_nohats
1024 13:67:ff:08:9d:8d:4a:32:77:3e:0a:09:81:a6:bc:4a paul(a)nohats.ca
(DSA)
Looks like me :)
More importantly, there is one root for all users---if one user needs
to be blocked (e.g. sysadmin quits), the only
solution is to change the root password everywhere. Individual accounts can be controlled
independently, especially in
setups with centralized account management like Kerberos/IPA.
Yes, I am not advocating root passwords :)
- allows more granularity in granting elevated privileges
across a set of machines and admins
That is true, but honestly the number of ways to get out of a restricted
sudo command list are pretty extensive. If you give them one command as
root you almost always give them a way to get a root shell.
Nothing in the current setup is preventing you from allowing
non-root
remote access. Blocking direct root access does not "allow more
granularity".
You already have all the granularity if you want to use it.
But if the single-password root is enabled, why would anyone use those granular methods?
I said install ssh keys for root, not passwords.
Paul
10:27 a.m.
Dne 12.1.2015 v 15:46 Przemek Klosowski napsal(a):
There still needs to be an administrative access to the system, and
the
most common implementation by enabling 'sudo' on the non-privileged
account. So, in a sense you are both right: this feature is just a small
step rather than a security panaceum, but it does bring real
improvements in several areas:
- increases difficulty of the attack by banning stupid automated BF
attacks on root
- improves accountability for administrative actions (we know which
admin messed up :)
- allows more granularity in granting elevated privileges across a set
of machines and admins
No. It improves nothing. This is step backward.
It gaves bad signal to the user ("strong root password is not needed").
It does not mitigate the BF attack. The original and main reason was to
mitigate BF even "P J P <pjp(a)fedoraproject.org>" told us here that not.
See his writings here:
https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html,
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
This is simply very bad security misconception.
The PJP told us that this is like SELinux or firewal. But firewall block
all trafic. But SELinux does not allow to obey the rules it raises. And
"PermitRootLogin=no" still allows BF and still allows easily to login as
another user and do su/sudo even maybe (!!!) not so easily (which is
hard to prove as I demonstrated before because it will lead to use much
less quality passords for root and normal users too).
All this rumor is trying to tell us that it improves security, but does
not. It provides false feeling of improved security and this is very
dangerous (ie. like does Security through Obscurity). If you really want
to improve security and mitigate BF attacks against root, do this:
A) do not run SSHD by default
B) install a script by default to bann repeated login failures
(there are many around here, just test them and ship one).
These are real steps forward as it will really mitigate BF for all
accounts in the system.
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
11:02 a.m.
Delimit the remote access to users with privilege is not in any case
based Security
through Obscurity. Obviously the best option for delimiting access is
disabled by default SSH. I consider before taking such drastic measures
that may affect users of cloud, is more than reasonable disable access to
users with administrative permissions.I will not go on reasonable local
situations like using custom rules for SELinux or firewall rules (when the
firewall disabled by default).
Delimiting access to SSH is not only through the LAN/Internet network, it
is also important to prevent a local user where SELinux rules or whatever will
not let you make a su/sudo/whatever - root. And They can simply ssh localhost.
- Do not run sshd by default:
It would be great in the installation this was an option to enable it.
Better to go step by step and see what happen with the users and how this
affect them without drastic changes.
- Install a script like fail2ban: So you need a default firewall enabled (
What do we have? I know another thread about fw disabled by default..).
This really affects more an a user than disable remote root login.
Do we want to help the user to have a secure distribution by default?
Let's start by being aware that we must define certain things that are
not commonly
used. Is more common users with weak passwords than users using ssh as root
or using rsync..
On Mon, Jan 12, 2015 at 5:27 PM, Milan Keršláger <milan.kerslager(a)pslib.cz>
wrote:
Dne 12.1.2015 v 15:46 Przemek Klosowski napsal(a):
> There still needs to be an administrative access to the system, and the
> most common implementation by enabling 'sudo' on the non-privileged
> account. So, in a sense you are both right: this feature is just a small
> step rather than a security panaceum, but it does bring real
> improvements in several areas:
>
> - increases difficulty of the attack by banning stupid automated BF
> attacks on root
> - improves accountability for administrative actions (we know which
> admin messed up :)
> - allows more granularity in granting elevated privileges across a set
> of machines and admins
No. It improves nothing. This is step backward.
It gaves bad signal to the user ("strong root password is not needed").
It does not mitigate the BF attack. The original and main reason was to
mitigate BF even "P J P <pjp(a)fedoraproject.org>" told us here that not.
See his writings here:
https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html,
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
This is simply very bad security misconception.
The PJP told us that this is like SELinux or firewal. But firewall block
all trafic. But SELinux does not allow to obey the rules it raises. And
"PermitRootLogin=no" still allows BF and still allows easily to login as
another user and do su/sudo even maybe (!!!) not so easily (which is
hard to prove as I demonstrated before because it will lead to use much
less quality passords for root and normal users too).
All this rumor is trying to tell us that it improves security, but does
not. It provides false feeling of improved security and this is very
dangerous (ie. like does Security through Obscurity). If you really want
to improve security and mitigate BF attacks against root, do this:
A) do not run SSHD by default
B) install a script by default to bann repeated login failures
(there are many around here, just test them and ship one).
These are real steps forward as it will really mitigate BF for all
accounts in the system.
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Francisco Alonso.
http://twitter.com/revskills
PGP: 0xE2E64DCA
--
11:20 a.m.
On Monday, 12 January 2015 10:06 PM, Milan Keršláger wrote:
No. It improves nothing. This is step backward.
It gaves bad signal to the user ("strong root password is not needed").
Wrong interpretation.
It does not mitigate the BF attack. The original and main reason was
to
mitigate BF even "P J P <pjp(a)fedoraproject.org>" told us here
that not.
No! Again, intention is to keep malicious users from gaining 'root' access via
BF attacks. It is quite similar to why we run services as non-root users, instead of root.
If at all break-in happens, it is still a non-root user.
The PJP told us that this is like SELinux or firewal. But firewall
block
all trafic. But SELinux does not allow to obey the rules it raises. And
"PermitRootLogin=no" still allows BF
Which part of 'PermitRootLoing=yes|no' says anything about what to do with
non-root account? It is not a mitigation for brute force attacks. The option merely says
whether to allow remote root login or not.
(which is hard to prove as I demonstrated before because it will lead
to use much
less quality passords for root and normal users too).
That's a hypothesis.
If you really want to improve security and mitigate BF attacks
against root, do this:
A) do not run SSHD by default
That's a non-option.
B) install a script by default to bann repeated login failures
(there are many around here, just test them and ship one).
MaxAuthTries option could help with that.
---
Regards
-Prasad
http://feedmug.com
1:39 p.m.
Dear PJP, in the ship, there is a hole. You are waving the flag
"unsinkable" instead to stop the flow and screaming: "The flow could be
stopped later!".
You dismiss my arguments without argument, just dismiss them. Unbelievable.
Is this about security or about your ego? Could do you agree that we
should be worry about other things you claimed first? Are you able to
underestand that your shoot badly missed the point? Seems not and this
is why the security disasters happened all the time.
Milan
Dne 12.1.2015 v 18:20 P J P napsal(a):
> On Monday, 12 January 2015 10:06 PM, Milan Keršláger wrote:
> No. It improves nothing. This is step backward.
> It gaves bad signal to the user ("strong root password is not needed").
Wrong interpretation.
> It does not mitigate the BF attack. The original and main reason was to
> mitigate BF even "P J P <pjp(a)fedoraproject.org>" told us here
> that not.
No! Again, intention is to keep malicious users from gaining 'root' access via
BF attacks. It is quite similar to why we run services as non-root users, instead of root.
If at all break-in happens, it is still a non-root user.
> The PJP told us that this is like SELinux or firewal. But firewall block
> all trafic. But SELinux does not allow to obey the rules it raises. And
> "PermitRootLogin=no" still allows BF
Which part of 'PermitRootLoing=yes|no' says anything about what to do with
non-root account? It is not a mitigation for brute force attacks. The option merely says
whether to allow remote root login or not.
> (which is hard to prove as I demonstrated before because it will lead to use much
> less quality passords for root and normal users too).
That's a hypothesis.
> If you really want to improve security and mitigate BF attacks against root, do
this:
> A) do not run SSHD by default
That's a non-option.
> B) install a script by default to bann repeated login failures
> (there are many around here, just test them and ship one).
MaxAuthTries option could help with that.
---
Regards
-Prasad
http://feedmug.com
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
1:46 p.m.
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger <milan.kerslager(a)pslib.cz> wrote:
...snip...
Hey Milan.
I understand you have a strong opinion on this topic as does pjp.
This is however no reason to bring personal attacks into things.
Please focus on the technical discussion.
kevin
1:52 p.m.
Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger <milan.kerslager(a)pslib.cz> wrote:
> ...snip...
Hey Milan.
I understand you have a strong opinion on this topic as does pjp.
This is however no reason to bring personal attacks into things.
Oh well. I'm stupid! Sorry. Or... really did I said something like this?
To not have technical argument is ok as seems.
This is not about security and never was. Shame.
Please focus on the technical discussion.
kevin
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
1:56 p.m.
On 12 January 2015 at 12:52, Milan Keršláger <milan.kerslager(a)pslib.cz>
wrote:
Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
> On Mon, 12 Jan 2015 20:39:35 +0100
> Milan Keršláger <milan.kerslager(a)pslib.cz> wrote:
>
> ...snip...
>>
>
> Hey Milan.
>
> I understand you have a strong opinion on this topic as does pjp.
>
> This is however no reason to bring personal attacks into things.
>
Oh well. I'm stupid! Sorry. Or... really did I said something like this?
No one said you are stupid. You are just taking comments too personally.
To not have technical argument is ok as seems.
This is not about security and never was. Shame.
It is to pjp. Try seeing it from his point of view and if you can't then
don't respond.
Please focus on the technical discussion.
>
> kevin
>
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
11:37 a.m.
On 01/12/2015 08:52 PM, Milan Keršláger wrote:
Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
> On Mon, 12 Jan 2015 20:39:35 +0100
> Milan Keršláger <milan.kerslager(a)pslib.cz> wrote:
>
>> ...snip...
>
> Hey Milan.
>
> I understand you have a strong opinion on this topic as does pjp.
>
> This is however no reason to bring personal attacks into things.
Oh well. I'm stupid! Sorry. Or... really did I said something like this?
To not have technical argument is ok as seems.
Milan, calm down. You may not be stupid and no one has suggested so by
now. But you may be perceived as troll in this thread.
Seems you misunderstand the difference between hypothesis and
demonstrating something. All you have made is a claim based on water. No
facts. No technical arguments. Just. An. Opinion. Have I missed
something more than that?
I will paraphrase you: Is this about security or about your ego?
It is not to say I disagree with your opinion that simply disabling root
login is bad idea.
Not because it would make things less secure. With password logins
enabled the bar is so low it is not easy to make it lower. (May be it
does not apply for an average Fedora user but definitely does for an
average computer user which Fedora now tries to target with some changes.)
But because it is a hindrance. IMHO when contemplating incompatible
change of the default let's make it worth the trouble and make the
default really secure by disabling password logins completely and for
all accounts.
I would love to see an Security spoke added to Anaconda where one could
override level of security and particular details like this.
-- Martian
This is not about security and never was. Shame.
> Please focus on the technical discussion.
>
> kevin
12:46 p.m.
On 13 January 2015 at 10:37, Marian Csontos <mcsontos(a)redhat.com> wrote:
On 01/12/2015 08:52 PM, Milan Keršláger wrote:
> Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
>
>> On Mon, 12 Jan 2015 20:39:35 +0100
>> Milan Keršláger <milan.kerslager(a)pslib.cz> wrote:
>>
>> ...snip...
>>>
>>
>> Hey Milan.
>>
>> I understand you have a strong opinion on this topic as does pjp.
>>
>> This is however no reason to bring personal attacks into things.
>>
>
> Oh well. I'm stupid! Sorry. Or... really did I said something like this?
> To not have technical argument is ok as seems.
>
Milan, calm down. You may not be stupid and no one has suggested so by
now. But you may be perceived as troll in this thread.
Seems you misunderstand the difference between hypothesis and
demonstrating something. All you have made is a claim based on water. No
facts. No technical arguments. Just. An. Opinion. Have I missed something
more than that?
I will paraphrase you: Is this about security or about your ego?
Please back off as you are not helping either. Your phrasing above is a
personal attack versus a technical conversation and will just make a person
defensive versus actually help them see any problems.
Thank you
--
Stephen J Smoogen.
4:51 p.m.
Am Montag, den 12.01.2015, 17:20 +0000 schrieb P J P:
> If you really want to improve security and mitigate BF attacks
against root, do this:
> A) do not run SSHD by default
That's a non-option.
This is actually implemented in Workstation, i.e. the sshd.service is
not enabled by default when installing from the Workstation Live CD (or
any other live CD, I think). The explanation I once got for this can be
found in [0]. I guess this is also what most users of Workstation would
expect.
On the other hand, when using the server netinst image (which, despite
its name, is a generic installation image) to install Workstation, you
end up with an enabled sshd.service after installation.
Maybe this difference can be addressed together with what ever is
decided upon in this discussion? I think having some consistency here
would be good.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=869848#c6
--
Volker
5:51 a.m.
On Tuesday, 13 January 2015 4:24 AM, Volker Sobek wrote:
Maybe this difference can be addressed together with what ever is
decided upon in this discussion? I think having some consistency here
would be good.
IMO, the install image consistency issues need to be handled separately and could not be
clubbed with this feature/change.
---
Regards
-Prasad
http://feedmug.com
7:18 a.m.
Am Dienstag, den 13.01.2015, 11:51 +0000 schrieb P J P:
> On Tuesday, 13 January 2015 4:24 AM, Volker Sobek wrote:
> Maybe this difference can be addressed together with what ever is
> decided upon in this discussion? I think having some consistency here
> would be good.
IMO, the install image consistency issues need to be handled separately and could not
be clubbed with this feature/change.
Agreed, I just wanted to bring this difference to everyone's attention
since it's a closely related issue. If, e.g. the outcome here was to
disable ssh by default, it would resolve this difference as well, that's
why I used 'together' here.
--
Volker
12:28 p.m.
On 12 January 2015 at 06:05, P J P <pj.pandit(a)yahoo.co.in> wrote:
> On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
> You are (instead of completly mitigating), only raising complexity a
> little bit (ie not completly avoiding), which is what is "Security
> through obscurity" about (ie. by hiding source code, the attacker only
> solve more complex problem - debugging machine code).
>
> One more time: The system can be cracked by BF attack only if there is a
> weak (root) password.
Sure. As guessed, you misunderstood the intention. The feature is _not_
a remedy against brute force attacks. But it is a remedy for keeping such
attackers from gaining 'root' access on remote machines. The feature says,
I don't see how this is the case. All we have done is move the first line
of the root-kit script to calling sudo via the password that was used to
open the account up. Since many of Linux systems are single user boxes.. it
is most likely going to work. If it fails then the majority of them just
dump the warning email in /var/spool/mail/root which never gets read (from
the number of boxes I have had to clean up).
And from looking at the sophistication of various worms these days.. they
are a lot smarter about guessing who owns the box and then trying various
smart choices (since Fedora will select ssmoogen as my name it has shown up
more often in brute forces by systems which I own).
"...Disabling remote root login by setting PermitRootLogin=no
would help
to harden Fedora systems, moving it an inch closer towards 'secure by
default' future. Users can have non-root accounts with weak passwords too,
yet disabling remote root login keeps an attacker a step away from getting
full control on a system..."
The feature helps to _harden_ Fedora systems. Same as filtering traffic
via firewall or restricting undue access via SELinux etc.
> If you disable remote root login (bacause users are using weak crackable
> password), you are saying to the user: "Happily use simple password
> because you are safe even that!". And because when admin password could
> be simple then the user password will be more simpler (this is
> average-user-logic) and the BF against the system will succeed more
> easily (even the login name will need to be guessed or picked by another
> way). So your solution is potentionally more dangerous than current
> situation.
That is a lot of speculation and hypothesis. In now way does this
feature imply or indicate to users that they can use weak passwords.
I was going to say it is an informed speculation.. I have actually had to
interview various people about weak passwords and why they chose them and
the largest excuse is "Well I don't need to have a strong password for
this.. its not like its root." [I have had this from Phd's in computer
science who thought it would be too hard for a script kiddie to know to use
sudo to get access.. and then had a lot of compromised computers. This was
in 2003-2004 so it is not a new problem.]
> If you want to avoid the problem (ie avoid BF crack-in),
disabling
> remote root login is not the right way, this is simply not enough, this
> does not solve the problem. There are better solutions I wrote about
> already (prefferrably to not expose SSH to the wild by default).
Again, issue being addressed is not of brute force attacks. But that of
such attacks resulting in gaining 'root' access to remote machines. They
are two distinct issues.
They are only two distinct issues with dumb scripts which get smarter as
soon as the malware authors realize that they need to add some logic for
sudo or su access. Once there is a connection between the factors they are
linked.
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
12:58 p.m.
On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote:
I don't see how this is the case. All we have done is move the
first line of the root-kit script to calling sudo via the password
that was used to open the account up. Since many of Linux systems
are single user boxes.. it is most likely going to work. If it fails
then the majority of them just dump the warning email in
/var/spool/mail/root which never gets read (from the number of boxes
I have had to clean up).
Sorry, I didn't get it. Running root-kit script implies you already
have access to a machine. And the user has sudo(1) access enabled.
>And from looking at the sophistication of various worms these
days..
they are a lot smarter about guessing who owns the box and then trying
various smart choices (since Fedora will select ssmoogen as my name it
has shown up more often in brute forces by systems which I own).
That's possible. But the proposed feature is not meant to address this issue.
I was going to say it is an informed speculation.. I have actually had
to
interview various people about weak passwords and why they chose them and
the largest excuse is "Well I don't need to have a strong password for
this.. its not like its root."
Yes, that is quite common. Which is precisely why we need to set hardened
default configurations.
---
Regards
-Prasad
http://feedmug.com
1:13 p.m.
On 12 January 2015 at 11:58, P J P <pj.pandit(a)yahoo.co.in> wrote:
On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote:
>I don't see how this is the case. All we have done is move the
>first line of the root-kit script to calling sudo via the password
>that was used to open the account up. Since many of Linux systems
>are single user boxes.. it is most likely going to work. If it fails
>then the majority of them just dump the warning email in
>/var/spool/mail/root which never gets read (from the number of boxes
> I have had to clean up).
Sorry, I didn't get it. Running root-kit script implies you already
have access to a machine. And the user has sudo(1) access enabled.
Sorry if I am misunderstanding but the feature is to address brute forcing
the root account so that they do not get root access to the server. I am
saying that this isn't a speed-bump because they are already trying to
brute force all the accounts on the system and so if they get one, they
will become root as they already have the password for the account. Thus I
do not see how it solves the first problem.
>>And from looking at the sophistication of various worms these
days..
>they are a lot smarter about guessing who owns the box and then trying
>various smart choices (since Fedora will select ssmoogen as my name it
>has shown up more often in brute forces by systems which I own).
That's possible. But the proposed feature is not meant to address this
issue.
I was going to say it is an informed speculation.. I have actually had to
>interview various people about weak passwords and why they chose them and
>the largest excuse is "Well I don't need to have a strong password for
>this.. its not like its root."
Yes, that is quite common. Which is precisely why we need to set hardened
default configurations.
I do not disagree. I just think that the sophistication of the malware
robots is high enough that saying the above does not help hardening without
further changes. [Adding a password creation tool to anaconda and
gnome-first-boot to help people create 'stronger' passwords would seem to
do more in hardening.]
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
11:17 p.m.
On Tuesday, 13 January 2015 1:10 AM, Stephen John Smoogen wrote:
Sorry if I am misunderstanding but the feature is to address brute
forcing the root account so that they do not get root access to the server.
Right.
I am saying that this isn't a speed-bump because they are already
trying
to brute force all the accounts on the system and so if they get one,
they will become root as they already have the password for the account.
Thus I do not see how it solves the first problem.
Well, it prevents the direct brute-forcing of root accounts. The feature
does not address brute forcing of the non-root accounts and its further
implications. Secondly, usage of ssh keys for remote 'root' access,
with 'PermitRootLogin=without-password' would provide better returns in
the long term.
I do not disagree. I just think that the sophistication of the
malware
robots is high enough that saying the above does not help hardening
without further changes. [Adding a password creation tool to anaconda
and gnome-first-boot to help people create 'stronger' passwords would
seem to do more in hardening.]
They already have that, no? When you set password, it shows a bar
meant to indicate password strength, IIRC.
---
Regards
-Prasad
http://feedmug.com
9:16 a.m.
On 12 Jan 2015, at 03:56, P J P wrote:
Hello,
> On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
>>> Earlier in the discussions I was told that this is not really an
>>> issue: in
>>> production, about every server with remote access also has a KVM.
>>
>> Often not the case in small business or third party hosted
>> environments.
>> Without remote ssh, box is unmanageable.
>>
>> Even if you want to do key-based authentication rather than
>> password, you
>> still need to use password initially to get the key onto the
>> remote box.
>
> If you use cloud-init you can specify an initial public key that it
> inserts against, or even auto enrol it in a central auth system like
> IPA and hence not ever need a password.
So, the major issue(or blocker should we say?) is the virtualized
deployments. If there is no solution in sight, maybe last resort is
to enable remote root login, possibly in the '%post' install
section of the kick-start file.
Not just virtualized deployments, but also in remote installs on bare
metal.
--
Mike Pinkerton
11:02 a.m.
On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote:
Not just virtualized deployments, but also in remote installs on bare
metal.
Okay and the '%post' install section trick won't help there?
IIUC, it'd depend on which tool/application is used to do such remote installations
and if they provide means to customise/tweak the final install.
---
Regards
-Prasad
http://feedmug.com
11:57 a.m.
On 12 Jan 2015, at 12:02, P J P wrote:
> On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote:
> Not just virtualized deployments, but also in remote installs on bare
> metal.
Okay and the '%post' install section trick won't help there?
IIUC, it'd depend on which tool/application is used to do such
remote installations and if they provide means to customise/tweak
the final install.
Sure, if the tool provides the ability to tweak the install to enable
password-based root login, then one can log in after installation,
upload keys, configure sshd, etc. The question is whether the tool
that is available has that ability. Over the years, I have attempted
many of the remote installation methods described in the Fedora
Installation Guide. Not all of them work when you don't control the
remote network.
--
Mike Pinkerton
12:28 p.m.
On Monday, 12 January 2015 11:27 PM, Mike Pinkerton wrote:
Sure, if the tool provides the ability to tweak the install to enable
password-based root login, then one can log in after installation,
upload keys, configure sshd, etc. The question is whether the tool
that is available has that ability. Over the years, I have attempted
many of the remote installation methods described in the Fedora
Installation Guide. Not all of them work when you don't control the
remote network.
Right, I understand. We'll still have time till F22 release to sort out these issues
in tools.
As said in the previous mail, if we agree on PermitRootLogin=without-password as the
_default_ sshd(8) configuration, then next step would be to communicate the affected tools
and workflow maintainers to make required changes to account for the sshd(8) configuration
change.
---
Regards
-Prasad
http://feedmug.com
1:57 a.m.
Hi,
Often not the case in small business or third party hosted
environments. Without remote ssh, box is unmanageable.
Even if you want to do key-based authentication rather than password,
you still need to use password initially to get the key onto the
remote box.
Just curious: Is it possible to configure sshd to disallow passwd
auth in case it finds a valid (correct permissions etc.)
$HOME/.ssh/authorized_keys ?
cheers,
Gerd
1:03 p.m.
----- Original Message -----
> = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
In the Server case, nearly every deployment is headless. Disabling
root
login to ssh by default would mean that many people would have no way to
get into the system at all. (Yes, we could force the creation of a
non-root user at install time, but this user would by necessity be an
administrator capable of becoming root via sudo, so the distinction
is... fuzzy).
No, there is an important conceptual distinction between logging in as a “hard-coded
technical account named root“ and logging in as a real person (or a bacula/ansible service
account, even if ultimately root-privileged through some mechanism), as soon as more than
one person has administrative access: attribution and accountability.
OTOH, the security distinction between brute-forcing (constant “root”+password) or
(username+password) is trivial enough that I don’t think the change as proposed makes
sense.
The only other approach I could see for the headless
servers would be mandating the enrollment in an identity domain at
installation time (such as to FreeIPA or Active Directory).
Neither of those approaches is anything like ideal,
I think we should eventually end up forcing _all_ logins (both remote and local) to
actually identify a security principal (i.e. have a local user set up or a domain
membership as a required step during installation). You are right that at this moment
this would not go smoothly; we should make it smooth enough first, and then just remove
the root password altogether to force going through a real account first.
(https://lists.fedoraproject.org/pipermail/security/2014-December/002039.html )
We can also consider opening an RFE against realmd, so that if the
machine becomes enrolled in a domain, it disables the remote root login
by default. I'm not sure about that, however.
That seems like a fairly confusing combination of a mechanism (realmd as a tool “for
joining domains”) and distribution policy (Fedora prevents/recommends not to use logins
directly as root).
Mirek
5:30 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 08 Jan 2015 08:43:48 -0500
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
>
> Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security
> Team
>
> To disable remote root login facility in sshd(8) by default.
>
> == Detailed Description ==
> Sshd(8) daemon allows remote users to login as 'root' by default.
> This provides remote attackers an option to brute force their way
> into a system. Empirically it is observed that many users use their
> systems via 'root' login, without creating non-root user and often
> have weak passwords for this mighty account. sshd_config(5) has an
> option 'PermitRootLogin=yes|no' which controls sshd(8) behaviour;
> it is set to be 'Yes' by default. Disabling remote root login by
> setting PermitRootLogin=no would help to harden Fedora systems,
> moving it an inch closer towards 'secure by default' future. Users
> can have non-root accounts with weak passwords too, yet disabling
> remote root login keeps an attacker a step away from getting full
> control on a system. There is another option of disabling user
> login via password and require usage of cryptographic keys for the
> same. But that could a next step in future.
>
> Please see ->
> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
>
> == Scope ==
> * Proposal owners: to communicate with the Fedora maintainers of
> packages: Anaconda, OpenSSH, GNOME, etc.
> * Other developers: packages like Anaconda, GNOME etc. need to
> update their workflow to enable compulsory non-root user account
> creation and ensure good password strength for it.
> * Release engineering: installer needs to ensure creation of
> non-root user account with strong password. Similarly, all Fedora
> images must be created with a non-root user account.
> * Policies and guidelines: unknown yet.
Can we clarify something here? Is this a request to change the
defaults globally for all Products/nonproduct installs?
I would argue that it could be sensible to do this for Workstation and
non-product installs, but not for Server and Cloud.
I actually disagree here. I for one do non-product installs on both
server and desktop environments. I set a root password at install time
and post install join the machine to my ipa domain to get user accounts
sorted. I often need to setup dns entries post install for joining the
domain to work. while the desktop machines I can log in directly as
root, the servers are generally virtual machines that are headless.
In the Server case, nearly every deployment is headless. Disabling
root login to ssh by default would mean that many people would have
no way to get into the system at all. (Yes, we could force the
creation of a non-root user at install time, but this user would by
necessity be an administrator capable of becoming root via sudo, so
the distinction is... fuzzy). The only other approach I could see for
the headless servers would be mandating the enrollment in an identity
domain at installation time (such as to FreeIPA or Active Directory).
that is not always possible
Neither of those approaches is anything like ideal, so I would
argue
that Server should continue to operate with the SSH root login being
available by default, but perhaps add documentation to the install
guide recommending to disable it if other accounts are available;
perhaps even by adding a simple kickstart directive (but no UI
element) to accomplish this.
there likely needs to be options in kickstart and the installer for
enabling the different types of options people could want
We can also consider opening an RFE against realmd, so that if the
machine becomes enrolled in a domain, it disables the remote root
login by default. I'm not sure about that, however.
In the case of Cloud, I think the point is basically moot, since
cloud-init should be handling all the relevant setup for this in any
case.
tl;dr:
Let's make this change happen with a per-product config default, with
Workstation and Non-product setups disabling root SSH login by
default. Server should leave SSH login enabled (arguably conditional
on whether or not the user enrolls in a domain).
lets make this something configurable at install time
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUrxMOAAoJEH7ltONmPFDRESsQAKLnVk0FfStm/Zr9arNnatCP
OwFwfOhgWP8KwHxEE9ZN+RKnjv2HY6dE5CC3bsaJob2aSkyQXxxHgH+LO3KowEqf
BO1YM0gjiVYINoNi3Kl4juHy3otvO9x5sw6p9yPv//yIHy0e6gkq9mfAdx+2MFoK
An5ysrj+9t4fj1ojUk7Q5+lKnd7Gl5B2veEr8XgDaTlSvgOoTEa7FCfyP6klSJk7
3SYwzYredY9fcNa/cZg8wRiuKIovg+SpXVFqR1aG7Fgu3VAgo4pShSRV/Yt3GdLh
lOJYd7l/u5fGEtZt2D3+sVRfHZcilD8WtplcUnzvsOEbecKpSZnEBa7+tlWLE/2/
FwFvSf3vx3jeWXqSTkNTM0qFfenj/JGoO1XtXmPrgFDjwZebHUU/yDGXe6XdbyiU
8gx08F85JbwDH09AE0MItVsEl4Gm1cMUIDLa4vrkpH234C444zumM2dIDJTx0Vt+
essJTQl4hu1bhEPWFdPwDRUmTJILBFwLRlvxohPLA/wBBG5Wsn6Ue6sKbV9PoBoP
znJQh7eEm5Jh7ddizC2xk4EMTD1wNnELBfbPEBoH/5JPXUwtAHTZOW1KilvR0R90
94Go6PIPA4GlewbRy1KLSPYR8ThK9+lVLsQgH3VQQJ39QMEZpMMmhfR8Nsl6k4sg
Eci/9pKxw+OHPPBp83ey
=MeRb
-----END PGP SIGNATURE-----
2:53 a.m.
Hello,
I'm writing a common reply for consolidation and brevity. I'll try to cover all
the concerns raised so far.
- Idea behind this feature is to keep malicious users from gaining 'root' access
to remote systems. Restricting remote root login increases the difficulty level in that,
which could thwart significant chunk of attacks. Guessing non-root user name is doable,
but still involves the complexity/work involved in doing that, which is _not same_ for all
malicious users. Few might be able to crack it, while others would _fail_ at it.
- The 'method' used to restrict remote root access is negotiable. Ie. disable it
completely by setting PermitRootLogin=no OR disable remote root login via password by
setting PermitRootLogin=without-password. Either one would serve the purpose, but also
have implications on other workflows.
- Major concern so far is how this feature could break existing workflows. That is genuine
and can be addressed adequately. As said earlier in other threads, intention is certainly
_not_ to trouble users, but raise the security bar of Fedora systems a notch higher.
- Second tune is that the feature does not add any security. That is like saying having a
security guard at the entrance adds no value, because atrocities still continue to happen
around us. IMO, this feature certainly adds more value to Fedora than its perceived short
term cost.
Major use-cases discussed so far, across multiple threads are:
1. Local installations: wherein a user can navigate through the installation process as
prompted by the Anaconda installer. The system being installed could be local or remote.
The variant being installed could be server or workstation.
2. Automated installation: wherein a user can not navigate through the installation steps.
The variant could be sever or workstation.
3. Cloud installations: wherein cloud images are built via automation tools with
predefined configurations. Mostly these don't have(or need) non-root user account.
Towards a better solution:
PermitRootLogin=no
* If we disable remote 'root' access, non-root user access becomes imperative.
- Anaconda & cloud_init tools already facilitate creation of non-root user
accounts.
- Creation of one non-root account could be made mandatory.
- Omission of non-root account creation could show discretionary warning.
- Omission of such user account creation could conditionally enable remote root access.
PermitRootLogin=without-password
* If we restrict remote 'root' access, exporting of ssh keys becomes imperative.
- Cloud_init tool seems to have facilities for that.
- Anaconda installer's state on this is not known yet.
- Such systems would still need non-root user access.
* Remote root access can be enabled in the '%post' install section of the
kick-start file.
- https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html
Either approach entails some modifications to the current workflows. Though it seems
PermitRootLogin=no could do with lesser than 'without-password' option. As said in
the feature page,
"...There is another option of disabling root login via password and require usage
of cryptographic keys for the same. But that could be a next step in future."
Please see:
-> https://www.piratepad.ca/p/ssh-remoterootloigin
I have collated the above details on this pad. Please feel free to edit it as required.
Your comments/suggestions are most welcome. Once again, intention is _not_ to trouble
users, but to ensure their safety by default.
Thank you.
---Regards
-Prasad
http://feedmug.com
3:36 p.m.
- The 'method' used to restrict remote root access is
negotiable. Ie. disable
it completely by setting PermitRootLogin=no OR disable remote root login
via password by setting PermitRootLogin=without-password.
(The general theme of this mail: Being flexible is fine, and establishing this through
this discussion is great; however, ultimately the Change proposal needs to document the
_specific outcome_ of that discussion.²)
- Major concern so far is how this feature could break existing
workflows.
That is genuine and can be addressed adequately.
“Can be” or “will be”? How? It is vaguely worrying that the Change proposal explicitly
lists only the most trivial task to do (change a sshd.conf option) and is only fairly
generic about how other parts of the OS and users need to and/or will adapt.
PermitRootLogin=no
* If we disable remote 'root' access, non-root user access becomes
imperative.
- Anaconda & cloud_init tools already facilitate creation of non-root user
accounts.
- Creation of one non-root account could be made mandatory.
- Omission of non-root account creation could show discretionary warning.
- Omission of such user account creation could conditionally enable remote
root access.
“Could conditionally“… With my FESCo hat on, during the Change Checkpoints FESCo will
need to know whether the Change is sufficiently complete or whether to fall back to the
contingency plan. Having a “Could conditionally” nailed down to yes or no would prevent
general unhappiness if the respective package maintainers thought that they have done the
right thing and FESCo during review suddenly decided that the right thing is the
opposite.
Separately from the general theme above,
- Second tune is that the feature does not add any security. That is
like
saying having a security guard at the entrance adds no value, because
atrocities still continue to happen around us.
The requirement to know a user name, which is in most cases just an automatable task¹
nobody is trying to prevent or make harder, is not really the same as a requirement to
bypass a security mechanism (subdue a guard or guess a password). It’s been about 10
years already since I have witnessed an automated password guessing bot carrying a list of
user names and real names from previously infected systems as a “crib sheet” for guessing
on new systems; this is not a hypothetical thing that bot authors are too dumb or lazy to
do. So this proposal only helps if we hope that a bot won’t try the right user name;
calling this security by obscurity is not too wide off the mark.
Mirek
10:53 p.m.
On Tuesday, 13 January 2015 3:06 AM, Miloslav Trmač wrote:
(The general theme of this mail: Being flexible is fine, and establishing this
through this discussion is great; however, ultimately the Change proposal needs
to document the _specific outcome_ of that discussion.²)
I understand, I'll do that.
“Can be” or “will be”? How? It is vaguely worrying that the Change
proposal
explicitly lists only the most trivial task to do (change a sshd.conf option)
and is only fairly generic about how other parts of the OS and users need to
and/or will adapt.
Well, part of it was due to unknown use-cases of how users would be affected by this
change. Otherwise, immediate straight forward effect is that users would have to create
& use non-root accounts first. I've tried to collate more details
here -> https://www.piratepad.ca/p/ssh-remoterootloigin
“Could conditionally“… With my FESCo hat on, during the Change
Checkpoints
FESCo will need to know whether the Change is sufficiently complete or whether
to fall back to the contingency plan. Having a “Could conditionally” nailed
down to yes or no would prevent general unhappiness if the respective package
maintainers thought that they have done the right thing and FESCo during review
suddenly decided that the right thing is the opposite.
Right, I understand. It's 'could conditionally' because it's still early
stage proposed change in workflow.
So this proposal only helps if we hope that a bot won’t try the right
user name;
calling this security by obscurity is not too wide off the mark.
I beg to differ here a little. Because nothing is stopping them from trying non-root
accounts now and even with 'without-password' option, nothing changes for non-root
accounts. The proposed change and use of 'PermitRootLogin' option is only to
restrict remote 'root' access. IMO that's not obscurity.
So, we do seem to have consensus(at least no opposition) for
'PermitRootLogin=without-password' option. I'll update the feature page with
it and details about the specific use-cases.
Thank you.
---
Regards
-Prasad
http://feedmug.com
10 a.m.
Hello Miloslav, all
On Tuesday, 13 January 2015 10:26 AM, P J P wrote:
So, we do seem to have consensus(at least no opposition) for
'PermitRootLogin=without-password' option. I'll update the feature
page with it and details about the specific use-cases.
I have updated the feature page with the due changes as discussed and suggested so far.
Please see:
-> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
Please feel free to edit the feature page as required. If you find something amiss or
unclear, please let me know, I'll fix it. As always, your comments and suggestions are
most welcome! :)
Thank you.
---
Regards
-Prasad
http://feedmug.com
10:13 a.m.
Hello,
Please see: (shared by 'fenrus02' on IRC)
-> https://stribika.github.io/2015/01/04/secure-secure-shell.html
Here are few more recommendations for sshd(8) configurations, mostly pertaining to
encryption algorithms.
Does it make sense to incorporate any of the suggestions from there?
---
Regards
-Prasad
http://feedmug.com
10:34 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 13 Jan 2015 04:53:43 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in> wrote:
> On Tuesday, 13 January 2015 3:06 AM, Miloslav Trmač wrote:
> (The general theme of this mail: Being flexible is fine, and
> establishing this through this discussion is great; however,
> ultimately the Change proposal needs to document the _specific
> outcome_ of that discussion.²)
I understand, I'll do that.
> “Can be” or “will be”? How? It is vaguely worrying that the
> Change proposal explicitly lists only the most trivial task to do
> (change a sshd.conf option) and is only fairly generic about how
> other parts of the OS and users need to and/or will adapt.
Well, part of it was due to unknown use-cases of how users would be
affected by this change. Otherwise, immediate straight forward effect
is that users would have to create & use non-root accounts first.
I've tried to collate more details
here -> https://www.piratepad.ca/p/ssh-remoterootloigin
> “Could conditionally“… With my FESCo hat on, during the Change
> Checkpoints FESCo will need to know whether the Change is
> sufficiently complete or whether to fall back to the contingency
> plan. Having a “Could conditionally” nailed down to yes or no
> would prevent general unhappiness if the respective package
> maintainers thought that they have done the right thing and FESCo
> during review suddenly decided that the right thing is the opposite.
Right, I understand. It's 'could conditionally' because it's still
early stage proposed change in workflow.
> So this proposal only helps if we hope that a bot won’t try the
> right user name; calling this security by obscurity is not too wide
> off the mark.
I beg to differ here a little. Because nothing is stopping them
from trying non-root accounts now and even with 'without-password'
option, nothing changes for non-root accounts. The proposed change
and use of 'PermitRootLogin' option is only to restrict remote 'root'
access. IMO that's not obscurity.
So, we do seem to have consensus(at least no opposition) for
'PermitRootLogin=without-password' option. I'll update the feature
page with it and details about the specific use-cases.
There is no consensus on that. I do not do enough installs that I use
kickstart so can not put a key in place. On a freshly installed system
I have to log in as root with a password to do configuration. I
strongly suspect that I am not alone here. You need to talk to the
anaconda team and work out a plan to deal with all the different
options. up to and including having the current defaults exist when
only a root account is configured with only a password for
authentication. I suspect that to properly support making changes here
it needs to be strongly tied into anaconda changes that manage the
initial sshd config file.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUtUkxAAoJEH7ltONmPFDRuo0QAKhPOBWtsbPVQwwiPbMG6IcU
rKFh3ItDN5MmTiomGfOiyTKNg9aiOq+nygeC+imMr8gmRIASey3kYNaUAGZsdO3Y
3nq5c3YJyv2rcesRJFCsvu6Odr5KhcOTSOJeMrbbCuT/WvOOK49NPBxIkA5DiDUY
UZlKt7FHEAKj5kEdstGgkRKtZrU89TLZd0LG0Ko/HJSkkA5QRopE28z5DOxzD0gr
1Jr5LLbXBVy2ZNYZQY3rUDmbz1w+qZfRz1mPKR+SVsy+BzxYkrCazM8Qd57aJsWz
lb+LAg24sLamax4wiTRJ2FG8XyQ9HmrofpKaYiuRM5xtZG8yHXr0JGKbxEjKJqUv
H8GsFmGnuRQpH/usb7uVTMnF7AAlcAo1YpUrOUuSlPtizXq86hu4rAm95JxrQetI
L31o0Bmf56JptO3hCAPVuqCiUKv4Qbzgj5x0Qljgm8tCdzaWhVIiuqg9WBGovGYT
ajlNNjSYLhLswPf37q6E1O2IkPd5a8VlJ/+oGXcm2YcVAlY2lhrufNEb8QmnebxM
5wnX+wB4tx6+7V5MypfDH66UrxGz4YkIJKFvEcy21bBO1f7savyzOgJA/0yk1UNJ
U6889pxdhjrrRYPD9YI9HMaGxuZxrCRmGhWwrPWm3fpLMFFh0Qvi320O+nWuvRd4
08m+hckd0KadFeFqwsE1
=3RoX
-----END PGP SIGNATURE-----
11:09 a.m.
Hello Dennis,
On Tuesday, 13 January 2015 10:05 PM, Dennis Gilmore wrote:
There is no consensus on that.
Well, no opposition as such either. How is it done otherwise,
do we conduct votes to establish consensus, is that a usual practice?
I do not do enough installs that I use kickstart so can not put
a key in place. On a freshly installed system I have to log in
as root with a password to do configuration. I strongly suspect
that I am not alone here. You need to talk to the anaconda team
and work out a plan to deal with all the different options.
up to and including having the current defaults exist when only a root
account is configured with only a password for authentication. I suspect
that to properly support making changes here it needs to be strongly
tied into anaconda changes that manage the initial sshd config file.
True. I plan
to talk to them about the proposed workflow changes;
One of which caters to the case wherein only 'root' user is needed.
"Omission of such user account should prompt user if they wish to enable remote
'root' login and set the parameter appropriately." OR Other way could be to
just enable remote 'root' login when no non-root account is created by the user.
Let's see, they might have other suggestions.
---Regards
-Prasad
http://feedmug.com
2:59 p.m.
On Tue, 13 Jan 2015 17:09:16 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in> wrote:
Hello Dennis,
> On Tuesday, 13 January 2015 10:05 PM, Dennis Gilmore wrote:
> There is no consensus on that.
Well, no opposition as such either.
Sorry this is false.
You got enough emails telling you this change is undesirable, that's
the definition of opposition and means you have no _consensus_.
Simo.
How is it done otherwise,
do we conduct votes to establish consensus, is that a usual practice?
> I do not do enough installs that I use kickstart so can not put
> a key in place. On a freshly installed system I have to log in
> as root with a password to do configuration. I strongly suspect
> that I am not alone here. You need to talk to the anaconda team
> and work out a plan to deal with all the different options.
> up to and including having the current defaults exist when only a
> root account is configured with only a password for authentication.
> I suspect that to properly support making changes here it needs to
> be strongly tied into anaconda changes that manage the initial sshd
> config file.
True. I plan to talk to them about the proposed workflow changes;
One of which caters to the case wherein only 'root' user is needed.
"Omission of such user account should prompt user if they wish to
enable remote 'root' login and set the parameter appropriately." OR
Other way could be to just enable remote 'root' login when no
non-root account is created by the user.
Let's see, they might have other suggestions.
---Regards
-Prasad
http://feedmug.com
--
Simo Sorce * Red Hat, Inc * New York
11:53 p.m.
Hello Simo,
On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote:
Sorry this is false. You got enough emails telling you this
change is undesirable, that's the definition of opposition
and means you have no _consensus_.
IIUC, that was for disabling remote root access completely with
'PermitRootLogin=no'.
As the 'PermitRootLoing=without-password' option seems more preferred. As for the
emails,
many folks have also said that it is a useful change.
IMO, the ones opposing are those who fear their current setups/practices would break.
Because they need remote 'root' access in their set-up. Which is a genuine
use-case.
And to support it, we could provide an option to enable remote root access with
'PermitRootLogin=Yes', based on the the user's response to Anaconda at install
time,
as was suggested in previous email. However, let's not assume _all_ Fedora users have
this use-case.
- IMHO, the change helps to harden Fedora systems and raise the security bar
a notch higher. It is similar to how we run services as non-root user instead
of 'root' user.
- The proposed change of using ssh keys for remote 'root' access introduces
that mechanism to a wider audience, which in turn would help increase its
usage in the future. Hence bring more value in the long term.
- IMO, it is beneficial to supply hardened default configurations, because
they protect maximum users and have greater impact, than otherwise. Security
is not a feature, it must be available by default.
- Of course that does not mean we overlook the usability aspect. As said before
intention is _not_ to trouble users, but increase their safety as much as we can.
Thank you.
---
Regards
-Prasad
http://feedmug.com
12:06 a.m.
On Tue, Jan 13, 2015 at 10:53 PM, P J P <pj.pandit(a)yahoo.co.in> wrote:
Hello Simo,
> On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote:
> Sorry this is false. You got enough emails telling you this
> change is undesirable, that's the definition of opposition
> and means you have no _consensus_.
IIUC, that was for disabling remote root access completely with
'PermitRootLogin=no'.
As the 'PermitRootLoing=without-password' option seems more preferred. As
for the emails,
many folks have also said that it is a useful change.
Assuming this applies to Server, with no change to Workstation (sshd
remains disabled by default, and 'PermitRootLogin=yes'). Otherwise I
predict the people who systemctl enable/start sshd and still can't get it
work are going to be irritated they have to also go edit a configuration
file. So they're going to be annoyed, and thwart the very thing the
proposal is trying to prevent. It's pretty unlikely these users are going
to instead learn to use key authentication. And if they aren't willing to
do that, why is it anyone else's responsibility to baby sit them?
--
Chris Murphy
8:31 a.m.
On Wed, 14 Jan 2015 05:53:23 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in> wrote:
Hello Simo,
> On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote:
> Sorry this is false. You got enough emails telling you this
> change is undesirable, that's the definition of opposition
> and means you have no _consensus_.
IIUC, that was for disabling remote root access completely with
'PermitRootLogin=no'. As the 'PermitRootLoing=without-password'
option seems more preferred. As for the emails, many folks have also
said that it is a useful change.
Ok, I state my opposition to without-password too inequivocably here.
Mostly because it is just the same as 'no', given there is no way, in a
regular install to seed a key into the root account.
IMO, the ones opposing are those who fear their current
setups/practices would break. Because they need remote 'root' access
in their set-up. Which is a genuine use-case. And to support it, we
could provide an option to enable remote root access with
'PermitRootLogin=Yes', based on the the user's response to Anaconda
at install time, as was suggested in previous email. However, let's
not assume _all_ Fedora users have this use-case.
Workstation do not even enable sshd (IIRC) so this impacts the server
images (cloud images already do their magic with sshd so I am not
counting them here), and server has different use cases and security
implications than a generic population.
- IMHO, the change helps to harden Fedora systems and raise the
security bar a notch higher. It is similar to how we run services as
non-root user instead of 'root' user.
I disagree that there is any similarity, and it doesn't bring security
up a notch, most ssh attempts already probe for multiple users,
preventing just root+password login is just cosmetics if
user+password+sudo can do the same operations when broken in.
If you want to do something effective against password guessing attack
there are a few much better (and easy to implement) methods:
1) require a longer root password, so that brute forcing just fail
2) implement throttling so that trying to log in as root is
slowed down considerably (and the related brute-force)
3) implement temporary black-listing, so that an IP that fails a
pre-set number of times simply gets black-list for a pre-set period of
time.
- The proposed change of using ssh keys for remote 'root'
access
introduces that mechanism to a wider audience, which in turn would
help increase its usage in the future. Hence bring more value in the
long term.
Except you have no mechanism to inject a key at installation time, you
would have to implement that first, *then* you can think of changing
the default.
- IMO, it is beneficial to supply hardened default configurations,
because they protect maximum users and have greater impact, than
otherwise. Security is not a feature, it must be available by default.
Security and Usability are always at odds, exceeding in one and
destroying the other is always as bad. The solution you propose only
minimally affect security, the security increase is really negligible.
But the usability is affected greatly, I think disproportionally, which
is why I am opposed to this change.
I am not against hardening, but this is just make things diofficult for
little to no gain.
- Of course that does not mean we overlook the usability aspect. As
said before intention is _not_ to trouble users, but increase their
safety as much as we can.
The intention may be not, then I'll call it poor execution/planning and
still oppose this move *at this time* unless there is proof we address
the usability problem first.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:22 a.m.
On 14 January 2015 at 14:31, Simo Sorce <simo(a)redhat.com> wrote:
On Wed, 14 Jan 2015 05:53:23 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in> wrote:
> IMO, the ones opposing are those who fear their current
> setups/practices would break. Because they need remote 'root' access
> in their set-up. Which is a genuine use-case. And to support it, we
> could provide an option to enable remote root access with
> 'PermitRootLogin=Yes', based on the the user's response to Anaconda
> at install time, as was suggested in previous email. However, let's
> not assume _all_ Fedora users have this use-case.
Workstation do not even enable sshd (IIRC) so this impacts the server
images (cloud images already do their magic with sshd so I am not
counting them here), and server has different use cases and security
implications than a generic population.
Not just workstation, spin images, it's a decision pre-dating workstation.
--
imalone
http://ibmalone.blogspot.co.uk
10:54 a.m.
Hi,
On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
Ok, I state my opposition to without-password too inequivocably here.
Mostly because it is just the same as 'no', given there is no way, in a
regular install to seed a key into the root account.
Except you have no mechanism to inject a key at installation time,
Sure. Could you please elaborate how would you like this key to be
injected into the 'root' account? Feature page does have a listed
workflow change:
"Anaconda installer OR maybe OpenSSH package needs to create
initial set of authentication keys for 'root' user."
It'll help if you could add your details to the ether pad, for
later reference.
here -> https://www.piratepad.ca/p/ssh-remoterootloigin
The intention may be not, then I'll call it poor
execution/planning and
still oppose this move *at this time* unless there is proof we address
the usability problem first.
We are still in the proposal state, not execution yet. IMO, before
we request the respective upstream developers to provide the needed
functionality, we need to state and agree on the usability requirements.
That'll be useful in the evaluation of the feature by the FES committee too.
Otherwise it's a chicken-and-egg problem.
I'd request all(those who are opposing) too describe their requirements in
the etherpad page above.
Thank you.
---
Regards
-Prasad
http://feedmug.com
11:14 a.m.
On Wed, 14 Jan 2015 16:54:09 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in> wrote:
Hi,
> On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> Ok, I state my opposition to without-password too inequivocably
> here. Mostly because it is just the same as 'no', given there is no
> way, in a regular install to seed a key into the root account.
>
> Except you have no mechanism to inject a key at installation time,
Sure. Could you please elaborate how would you like this key to be
injected into the 'root' account? Feature page does have a listed
workflow change:
"Anaconda installer OR maybe OpenSSH package needs to create
initial set of authentication keys for 'root' user."
Sorry,
but what is the point of this operation, wrt auth with keys issue ?
It'll help if you could add your details to the ether pad, for
later reference.
here -> https://www.piratepad.ca/p/ssh-remoterootloigin
> The intention may be not, then I'll call it poor execution/planning
> and still oppose this move *at this time* unless there is proof we
> address the usability problem first.
We are still in the proposal state, not execution yet. IMO, before
we request the respective upstream developers to provide the needed
functionality, we need to state and agree on the usability
requirements. That'll be useful in the evaluation of the feature by
the FES committee too. Otherwise it's a chicken-and-egg problem.
It *is* a chicken-egg issue to some degree.
I'd request all(those who are opposing) too describe their
requirements in the etherpad page above.
Being able to authenticate as root right after installation would be
the requirement for me.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11:33 a.m.
On Wednesday, 14 January 2015 10:44 PM, Simo Sorce wrote:
> "Anaconda installer OR maybe OpenSSH package needs to create
> initial set of authentication keys for 'root' user."
Sorry, but what is the point of this operation, wrt auth with keys issue ?
Well, it can be used it to export to other machines. It'll require you to
login as non-root user first.
Being able to authenticate as root right after installation would be
the requirement for me.
Right. But how would you inject a key for that?
If you must have only 'root' account in your set-up, remote root access
could be enabled by default. Feature page lists
...
"Omission of such user account should prompt user if they wish to
enable remote 'root' login, and set the parameter appropriately."
---
Regards
-Prasad
http://feedmug.com
11:34 a.m.
On Wed, 14 Jan 2015 16:54:09 +0000 (UTC)
P J P <pj.pandit(a)yahoo.co.in> wrote:
> > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> > Ok, I state my opposition to without-password too inequivocably
> > here. Mostly because it is just the same as 'no', given there is no
> > way, in a regular install to seed a key into the root account.
> >
> > Except you have no mechanism to inject a key at installation time,
>
> Sure. Could you please elaborate how would you like this key to be
> injected into the 'root' account? Feature page does have a listed
> workflow change:
>
> "Anaconda installer OR maybe OpenSSH package needs to create
> initial set of authentication keys for 'root' user."
That’s not how, to my knowledge, ssh keys are usually deployed; there is one private key
per user (or, for the paranoid, one private key per client machine / user’s home
directory), not one private key per the server one is connecting to. And creating a key
does not really solve the problem: how do the administrators get the key so that they can
connect?
> I'd request all(those who are opposing) too describe their
> requirements in the etherpad page above.
Being able to authenticate as root right after installation would be
the requirement for me.
Let’s be precise here; “able to authenticate as root” is an implementation detail; the
underlying requirement is something else. “Able to set up IPA”? “Able to run
administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a
root shell without any authentication ☺ ).
Mirek
11:55 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 14 Jan 2015 12:34:22 -0500 (EST)
Miloslav Trmač <mitr(a)redhat.com> wrote:
> On Wed, 14 Jan 2015 16:54:09 +0000 (UTC)
> P J P <pj.pandit(a)yahoo.co.in> wrote:
> > > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> > > Ok, I state my opposition to without-password too inequivocably
> > > here. Mostly because it is just the same as 'no', given there
> > > is no way, in a regular install to seed a key into the root
> > > account.
> > >
> > > Except you have no mechanism to inject a key at installation
> > > time,
> >
> > Sure. Could you please elaborate how would you like this key
> > to be injected into the 'root' account? Feature page does have a
> > listed workflow change:
> >
> > "Anaconda installer OR maybe OpenSSH package needs to create
> > initial set of authentication keys for 'root' user."
That’s not how, to my knowledge, ssh keys are usually deployed; there
is one private key per user (or, for the paranoid, one private key
per client machine / user’s home directory), not one private key per
the server one is connecting to. And creating a key does not really
solve the problem: how do the administrators get the key so that they
can connect?
> > I'd request all(those who are opposing) too describe their
> > requirements in the etherpad page above.
>
> Being able to authenticate as root right after installation would be
> the requirement for me.
Let’s be precise here; “able to authenticate as root” is an
implementation detail; the underlying requirement is something else.
“Able to set up IPA”? “Able to run administrative commands in
shell?” (e.g. we could just, as a part of firstboot, open a root
shell without any authentication ☺ ). Mirek
except that will not work when you do not have access to a console and
only have ssh access
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUtq2ZAAoJEH7ltONmPFDRzqsQAI59frCILBqB6zUWedryB5yp
378Wakimicon8HAHuUEqZb334246k4U3/d4FPaspGiqKtqSf2w1Y2nixFNdxGqor
mH5oyoToddasptFS2okRGh8IaPnZiBNXPVZ6emKrjeL+ln2DMsfSCPA9NN15AO/I
KllQ4j3YhDVm4qmL9a25pcNcPjUlIi1C6amR19eOkG7+788+7pMQ0yzcDcn3ow3O
F8u+j5bwPdPfwL/sEe6ZyGNgfHJEx+wtYCQjXMCQp3VkYHMkqHwkjR/q63l5TMtb
5SIFwzP6wmAaLvU3Nz4jEu8GWNQwm86cYIiEj1cRSN9muKffoIuJopKM1fchbveh
VuPH+FjZhvWShvN5tddaunOkGN2WtFJp8rgnWeVtT/09H+PbkzT3pigZt2OElnD/
49DWLork4uLOSuVPQvqMjMMsUbg1SLv9tB6AA45gtkEgkg+X256MdHUVK49HfOXS
ogCfgx7CfCPCd6cOEHx+exK3Xg9JlxqboIklR1pFyDLcyQUDkXaV0wrXq23hhrci
kLUpZ7yYTZwvHgKrQfQ99ael5alAHyCb/ZvWyAZyAoMeoJQKZoyCvNI5BWsVoGPQ
Ir1Z/nEGz2T/RbbpVrLvH5VzwkWY0hZyCEUwa+Wrh/LfyFBjxN6YM+YTdoPSI4Et
cifUPiu3gJqlrMnOJvyt
=nj7u
-----END PGP SIGNATURE-----
11:59 a.m.
On Wed, 14 Jan 2015 12:34:22 -0500 (EST)
Miloslav Trmač <mitr(a)redhat.com> wrote:
> > On Wed, 14 Jan 2015 16:54:09 +0000 (UTC)
> > P J P <pj.pandit(a)yahoo.co.in> wrote:
> > > I'd request all(those who are opposing) too describe their
> > > requirements in the etherpad page above.
> >
> > Being able to authenticate as root right after installation would be
> > the requirement for me.
>
> Let’s be precise here; “able to authenticate as root” is an
> implementation detail; the underlying requirement is something else.
> “Able to set up IPA”? “Able to run administrative commands in
> shell?” (e.g. we could just, as a part of firstboot, open a root
> shell without any authentication ☺ ). Mirek
except that will not work when you do not have access to a console and
only have ssh access
At this point/in this sub-discussion, I personally very much don’t care. Let’s collect
the requirements first.
Mirek
1:21 p.m.
On 14 Jan 2015, at 12:34, Miloslav Trmač wrote:
>> I'd request all(those who are opposing) too describe
their
>> requirements in the etherpad page above.
>
> Being able to authenticate as root right after installation would be
> the requirement for me.
Let’s be precise here; “able to authenticate as root” is an
implementation detail; the underlying requirement is something
else. “Able to set up IPA”? “Able to run administrative
commands in shell?” (e.g. we could just, as a part of firstboot,
open a root shell without any authentication
It seems that the boxes affected by this proposal are either
"product=server" or "product=nonproduct". For servers, immediately
after installing, I log in as root and run a set-up or configuration
script which, among other things, sets the box to a non-graphical
target and prevents firstboot from ever running. I'm not sure why
one would run firstboot on a server.
I also do something similar and prevent firstboot from running on
boxes set up as general desktops for office workers, etc., as I don't
want the first random user who logs into a box to be able to become
part of the wheel group and have access to sudo.
As far as I can see, firstboot is only useful on one's personal box.
--
Mike Pinkerton
3:13 p.m.
On Wed, 2015-01-14 at 16:54 +0000, P J P wrote:
Hi,
> On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> Ok, I state my opposition to without-password too inequivocably
> here. Mostly because it is just the same as 'no', given there is
> no way, in a regular install to seed a key into the root account.
>
> Except you have no mechanism to inject a key at installation time,
Sure. Could you please elaborate how would you like this key to be
injected into the 'root' account? Feature page does have a listed
workflow change:
"Anaconda installer OR maybe OpenSSH package needs to create
initial set of authentication keys for 'root' user."
It'll help if you could add your details to the ether pad, for later
reference.
Still, you can't just invoke features into existence by describing
them on a Change page. There needs to be a credible plan for actually
*doing* that work, yet so far as I can tell, none of the anaconda
developers is involved the Change proposal, nor has anyone said "I
will write the code to make this work".
In a project like Fedora, it doesn't always work out well to do things
the way this Change seems to be going: think of one change you want to
do, write up a Change for it, realize that lots of other things would
have to be done to make the change viable, and just write those things
into the Change as bullet points, and assume that somehow they'll be
made to happen if the change is approved.
Two other outcomes are more likely: 1) the Change will be rejected
because FESCo is worried about whether the necessary work will
actually get done, 2) the Change will get accepted but all the
necessary work won't actually get done, and the Change will have to be
backed out (wasting a lot of everyone's time), or the Change will go
in broken and everyone loses.
Basically, when proposing a Change, you need to make sure that you
have a plausible plan for all the necessary work to get done *ahead of
time* - i.e. you need actual people who have said "yes, I will do this
work, and I can believably commit to having it done in time". It
doesn't work, normally, to draw up a Change which requires work to be
done, then expect that you can get the Change accepted and resources
will somehow transpire to do the work.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:26 a.m.
I updated the change page with a small change to the User Experience
section. It now matches the effect of the updated proposal.
On Tue, Jan 13, 2015 at 11:34 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
I suspect that to properly support making changes here
it needs to be strongly tied into anaconda changes that manage the
initial sshd config file.
Would the ability to specify a public key (via the GUI or as a command
line option) suit your needs? This seems like the simplest approach
since it wouldn't require much logic, though it would still require
changes to anaconda. This would still allow us to proceed with
disabling password-based root login, but give users the option to keep
from locking themselves out of a remote machine post-install.
Thanks,
BC
--
Ben Cotton
11:46 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 13 Jan 2015 12:26:04 -0500
Ben Cotton <bcotton(a)fedoraproject.org> wrote:
I updated the change page with a small change to the User
Experience
section. It now matches the effect of the updated proposal.
On Tue, Jan 13, 2015 at 11:34 AM, Dennis Gilmore <dennis(a)ausil.us>
wrote:
> I suspect that to properly support making changes here
> it needs to be strongly tied into anaconda changes that manage the
> initial sshd config file.
Would the ability to specify a public key (via the GUI or as a command
line option) suit your needs? This seems like the simplest approach
since it wouldn't require much logic, though it would still require
changes to anaconda. This would still allow us to proceed with
disabling password-based root login, but give users the option to keep
from locking themselves out of a remote machine post-install.
I could make that work but it is far from ideal as I would need to make
sure that its available over a network connection. For one I would need
to remember the url to the key so that it can be fetched. currently I
set a password, run ssh-copy-id then ssh in and change the root
password to a more secure one. While I can vnc in to the console I
don't trust it to be secure. especially when I am doing it to machines
out on the internet.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUtVoAAAoJEH7ltONmPFDR8M8QANPt2kmDJTxqHg1wyGm6z7mp
A/OW0I4IiRhf4JXNWTfYNnjU528wL+j8jQlRjEhnik7sZVJs1nPvCjVNkdeCqgd/
jiLdvZfQxLeGRNtgzZRXQ/6hzXsU8NCgriMqm2KWQNb2bvoROWQwR/de+wsAqnld
QPfniPfFfnVcHIWL46F62h//QGx8yVFMePSMSuVrGKH6pyFvhN/6KtMa75e52l9B
aI/eJ7SbXL3eDn/5RYX3vJEa2VfXoi/A0NZfkHBmLzV89lJMgLKrQ7ksMoIHMMH7
gzMJb+jQQ8slSyzFy4OgXRimA4r+LWAaddZw7eZx62Ir6EMiUeD5S6HvTK9ItLdm
DEedVeXfIl002/LZJd8REYWcDBzmRdFAqMbUtvLuIbyM8I756y7wsOhkLiJyAXT4
uAaTwnA2xHZtkhUCg69WOyl5QBLt6UCTI9N+ju60M5LIe4MLRJ+/kRCDznyP9NeS
fOAO8Zjepo+wAUUsgH6cg8mYV4o14XJx8k0CWnH901G8i1yeEwzlARe4C3gO8Y1R
wFLYZTk2GfpNvKWIeOVwZB+3sidFQXkNnUiSI8ouLQt2UJm0IlCCTw6NuLY3LrTX
Ye/6m/WjEBAa+oyncHi2LRfsDcKWkmpXO+KCMPha/eQDL80Vp0XVQx+7uqPGDILX
Ua7KZdNyZfHaUE3EBEj4
=1/Eg
-----END PGP SIGNATURE-----
11:51 a.m.
On Tue, Jan 13, 2015 at 12:46 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
I could make that work but it is far from ideal as I would need to
make
sure that its available over a network connection. For one I would need
to remember the url to the key so that it can be fetched.
That's not quite what I had in mind, but I wasn't entirely clear. My
suggestion was that the text of the key itself would be provided, e.g.
--ssh-key="ssh-rsa AAAAB3N...ni31 bcotton@normal"
I'll grant that it's a little bit (a lot) ugly to do in a CLI, but it
seems like a reasonable compromise between the various goals and
constraints.
Thanks,
BC
--
Ben Cotton
12:14 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 13 Jan 2015 12:51:41 -0500
Ben Cotton <bcotton(a)fedoraproject.org> wrote:
On Tue, Jan 13, 2015 at 12:46 PM, Dennis Gilmore
<dennis(a)ausil.us>
wrote:
> I could make that work but it is far from ideal as I would need to
> make sure that its available over a network connection. For one I
> would need to remember the url to the key so that it can be fetched.
That's not quite what I had in mind, but I wasn't entirely clear. My
suggestion was that the text of the key itself would be provided, e.g.
--ssh-key="ssh-rsa AAAAB3N...ni31 bcotton@normal"
I'll grant that it's a little bit (a lot) ugly to do in a CLI, but it
seems like a reasonable compromise between the various goals and
constraints.
To me that is worse than giving a url where to fetch the key. it does
seem like a very good option for a kickstart install. I usually do
interactive installs but I do not trust that the console is secure I
take steps as soon as the install is done to tighten things up.
perhaps I should suck it up and just use kickstart. can you imagine
having to type the key into a box in an interactive install using vnc
over the internet? especially when that key is 8192 bits or bigger?
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUtWCfAAoJEH7ltONmPFDRbkMP/RgREBXmYLSg35GUi3lD64rU
o+hg9zR84uYAAYIilr6SgMlCiCrETvYDw4a9Hxf9zhsVu3Ge2knh5eEeWn8POO1S
y1dvbmocSWKks0miYa/IgWsBUCBPcpnWXzVHPXBuT/VfjLMqyyveS+eL5ZzvV3nm
Gc1ok/+ciQYMIQVR45WA6yBUrSVErIsdUtrxj+cBv5Ts/NTSC/km1CGNxREJ2p12
U2+tAv4FE1juw+4jnuWPLrw76i7sIVEtFKHzZ3Cnyc51sgulGUbSVZsT7Yt5Rt3c
tm7ZFrGuLLWYcVZbJSUl47HdgFzPH8IGECF8VPiEoHV0Zy4Ia46WJ6x8VCc2NQu2
pzQrH2/BhAMKbgxKPipvYqvbWWRal2uijC1BXyQgbLWHhx6r5qZdqESmAD1ThfIz
FIynVJ/6oTh4lWM5QS4f7XnBmLjY2j/tuo9W400QfGMvGe+wHSJsiiWO0qDKhrmz
IqDO1Q4EkY7RMZgCxcAvKZ0wfKJqord0oQpQJxnPhjjWRo3g9aPlDCOAu+4jgmQ6
jXZqDmAjWiBEqfU9NdEpr+VnDy+pQ8FCeHlYH4foAh3YFZjsr+SilgobBD1Bp/lo
brzticiOHjE+7irNdRqMP+TmYgzzebIQNi6dM4u42QcC1fgwZNspf4qte4d6XI3o
MKJdwDaSxe98HkQfKCfW
=+AQZ
-----END PGP SIGNATURE-----
8:39 a.m.
On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote:
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
The discussion got rather long, but I didn't see one particular aspect
discussed:
Remote users would not be allowed to login using 'root'
account with a
password. They would have to login using an SSH key or first connect
using a non-root account and then upgrade their privileges via sudo(8)
or su -.
Doesn't this make the systems actually _less_ secure?
I sometimes do risky things with my regular account. I often process
untrusted input I download from internet, often using tools that have
serious security issues discovered (it doesn't have to be just flash or
firefox, remember the binutils [1] or less [2] issues?). I'm sure many
of us are similarly careless with their non-privileged accounts.
[1] http://openwall.com/lists/oss-security/2014/10/23/5
[2] http://seclists.org/fulldisclosure/2014/Nov/74
There's a chance of a successful exploitation that would result in
obtaining my privileges. Sure, gaining access to my account is bad
enough, but if I run "su" or "sudo", they have root!
I'm never sure if I'm talking to the actual tool. Something could have
tampered with my shell and now is snooping for my password. The attacker
could have ptrace()d my shell and switched execve("/bin/su") for
execve("/tmp/uz_nejsu"). Or they could just have changed the $PATH in
my .profile. I wouldn't notice!
For this reason, I avoid privilege escalation when I need to conduct
privileged operations, but open a separate session. The sshd daemon
running with root privileges is more trustworthy to me than my user
session.
-1 for this change from me.
Disallowing root logins and requiring me to use my regular account puts
other users of the system in risk.
Thank you,
Lubo
9:22 a.m.
On 01/16/2015 03:39 PM, Lubomir Rintel wrote:
On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
The discussion got rather long, but I didn't see one particular aspect
discussed:
> Remote users would not be allowed to login using 'root' account with a
> password. They would have to login using an SSH key or first connect
> using a non-root account and then upgrade their privileges via sudo(8)
> or su -.
Doesn't this make the systems actually _less_ secure?
I sometimes do risky things with my regular account. I often process
untrusted input I download from internet, often using tools that have
serious security issues discovered (it doesn't have to be just flash or
firefox, remember the binutils [1] or less [2] issues?). I'm sure many
of us are similarly careless with their non-privileged accounts.
[1] http://openwall.com/lists/oss-security/2014/10/23/5
[2] http://seclists.org/fulldisclosure/2014/Nov/74
There's a chance of a successful exploitation that would result in
obtaining my privileges. Sure, gaining access to my account is bad
enough, but if I run "su" or "sudo", they have root!
I'm never sure if I'm talking to the actual tool. Something could have
tampered with my shell and now is snooping for my password. The attacker
could have ptrace()d my shell and switched execve("/bin/su") for
execve("/tmp/uz_nejsu"). Or they could just have changed the $PATH in
my .profile. I wouldn't notice!
For this reason, I avoid privilege escalation when I need to conduct
privileged operations, but open a separate session. The sshd daemon
running with root privileges is more trustworthy to me than my user
session.
-1 for this change from me.
-1 from me, too :)
Disallowing root logins and requiring me to use my regular account puts
other users of the system in risk.
Thank you,
Lubo
6:57 p.m.
On Fri, 2015-01-16 at 15:39 +0100, Lubomir Rintel wrote:
There's a chance of a successful exploitation that would result in
obtaining my privileges. Sure, gaining access to my account is bad
enough, but if I run "su" or "sudo", they have root!
Along these lines, someone pointed out a rather nasty attack vector
via sudo the other day:
http://blog.grdryn.me/blog/fedora/prank-alias-sudo-in-bash.html
so...you'd better remember to call it with \ every time...:)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:23 p.m.
On Fri, 2015-01-16 at 15:39 +0100, Lubomir Rintel wrote:
>
> There's a chance of a successful exploitation that would result in
> obtaining my privileges. Sure, gaining access to my account is bad
> enough, but if I run "su" or "sudo", they have root!
Along these lines, someone pointed out a rather nasty attack vector
via sudo the other day:
http://blog.grdryn.me/blog/fedora/prank-alias-sudo-in-bash.html
so...you'd better remember to call it with \ every time...:)
This is a „movie plot threat“, proposing a specific attack and a specific mitigation, but
doing nothing about the immediately available alternative attacks. For example, I could
edit ~/.profile to replace the running bash with a modified copy that ignores (or even
specifically hijacks) the \ in \sudo.
At a first glance it seems to me there in principle can’t be a way to protect against a
modified shell environment from within that environment because that environment can lie
to you about any system output, or to the system about any your input. (So even having a
trusted “antivirus service” running outside of the shell and protected against it wouldn’t
be useful because from the shell you could never be sure that you are talking to that
trusted service.¹)
Mirek
¹ Well, establish a TLS channel through the malicious shell directly to the antivirus…
Just no.
8:15 p.m.
On Mon, 2015-01-19 at 14:23 -0500, Miloslav Trmač wrote:
> On Fri, 2015-01-16 at 15:39 +0100, Lubomir Rintel wrote:
> >
> > There's a chance of a successful exploitation that would result
> > in obtaining my privileges. Sure, gaining access to my account
> > is bad enough, but if I run "su" or "sudo", they have
root!
>
> Along these lines, someone pointed out a rather nasty attack
> vector via sudo the other day:
>
> http://blog.grdryn.me/blog/fedora/prank-alias-sudo-in-bash.html
>
> so...you'd better remember to call it with \ every time...:)
This is a „movie plot threat“, proposing a specific attack and a
specific mitigation, but doing nothing about the immediately
available alternative attacks. For example, I could edit ~/.profile
to replace the running bash with a modified copy that ignores (or
even specifically hijacks) the \ in \sudo.
At a first glance it seems to me there in principle can’t be a way
to protect against a modified shell environment from within that
environment because that environment can lie to you about any system
output, or to the system about any your input. (So even having a
trusted “antivirus service” running outside of the shell and
protected against it wouldn’t be useful because from the shell you
could never be sure that you are talking to that trusted service.¹)
Mirek
Sure, I just meant it as a handy and clear demonstration of the
principle that if you can compromise the environment of a user with
sudo or other admin privileges, you're about 97% of the way to root in
any case.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:12 a.m.
On Mon, 2015-01-19 at 18:15 -0800, Adam Williamson wrote:
Sure, I just meant it as a handy and clear demonstration of the
principle that if you can compromise the environment of a user with
sudo or other admin privileges, you're about 97% of the way to root in
any case.
Right. Don't use sudo. For a server you're not physically sitting in
front of, you *definitely* want to log in as root instead of using sudo.
Please don't make this misguided change. Or if you must, make it
optional. Just a checkbox when setting the root password would suffice.
Or better still, make it possible not to set the root password at all,
if you don't want direct login as root. Use sudo for *everything*.
--
dwmw2
10:02 a.m.
Hi
On Fri, Jan 16, 2015 at 9:39 AM, Lubomir Rintel wrote:
For this reason, I avoid privilege escalation when I need to conduct
privileged operations, but open a separate session. The sshd daemon
running with root privileges is more trustworthy to me than my user
session.
I have no idea what you mean here. Turning off direct root login in SSH
doesn't make SSHD itself run as that user. SSHD is still running as root.
Rahul
3:09 p.m.
On 01/17/2015 09:02 AM, Rahul Sundaram wrote:
Hi
On Fri, Jan 16, 2015 at 9:39 AM, Lubomir Rintel wrote:
For this reason, I avoid privilege escalation when I need to conduct
privileged operations, but open a separate session. The sshd daemon
running with root privileges is more trustworthy to me than my user
session.
I have no idea what you mean here. Turning off direct root login in SSH
doesn't make SSHD itself run as that user. SSHD is still running as root.
I can't speak for Lubomir, but I'd guess he or she meant that as root,
one's environment ($HOME/.bashrc, $HOME/.tcshrc for us weirdos, aliases,
$HOME/bin/ contents, etc.) are unlikely to have been tampered with,
unless an attacker has already gained root access anyway. Nothing to do
with sshd per se.
--
J. Randall Owens | http://www.ghiapet.net/
5:06 a.m.
Hi Lubomir,
On Friday, 2015-01-16 15:39:42 +0100, Lubomir Rintel wrote:
> Remote users would not be allowed to login using 'root'
account with a
> password. They would have to login using an SSH key or first connect
> using a non-root account and then upgrade their privileges via sudo(8)
> or su -.
I sometimes do risky things with my regular account.
The solution is easy. Don't ssh to your regular account. Allow ssh login
only to a specific account that you use for nothing else. Then from
there su -
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
3366
days inactive
3394
days old
105 comments
38 participants
participants (38)
-
Adam Jackson -
Adam Williamson -
Alexander Ploumistos -
Ben Cotton -
Chris Adams -
Chris Murphy -
Chuck Anderson -
David Woodhouse -
Dennis Gilmore -
DJ Delorie -
Eike Rathke -
F. Alonso -
Gerd Hoffmann -
Ian Malone -
J. Randall Owens -
Jaroslav Reznik -
Josh Boyer -
Kevin Fenzi -
Laurent Rineau -
Lubomir Rintel -
Marian Csontos -
Maros Zatko -
Mike Pinkerton -
Milan Kerslager -
Miloslav Trmač -
Oron Peled -
P J P -
Paul Wouters -
Peter Robinson -
Przemek Klosowski -
Rahul Sundaram -
Ralf Corsepius -
Reindl Harald -
Richard W.M. Jones -
Simo Sorce -
Stephen Gallagher -
Stephen John Smoogen -
Volker Sobek