Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 pgp1ydfG1kbnC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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/ signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 2015-01-14 at 16:54 +, 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 14 January 2015 at 14:31, Simo Sorce s...@redhat.com wrote: On Wed, 14 Jan 2015 05:53:23 + (UTC) P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 05:53:23 + (UTC) P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jan 2015 12:34:22 -0500 (EST) Miloslav Trmač m...@redhat.com wrote: On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 12:34:22 -0500 (EST) Miloslav Trmač m...@redhat.com wrote: On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tue, Jan 13, 2015 at 10:53 PM, P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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.kersla...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jan 2015 12:51:41 -0500 Ben Cotton bcot...@fedoraproject.org wrote: On Tue, Jan 13, 2015 at 12:46 PM, Dennis Gilmore den...@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 B3N...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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jan 2015 12:26:04 -0500 Ben Cotton bcot...@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 den...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 den...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tue, Jan 13, 2015 at 12:46 PM, Dennis Gilmore den...@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 B3N...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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 13 January 2015 at 10:37, Marian Csontos mcson...@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.kersla...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Am Dienstag, den 13.01.2015, 11:51 + 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jan 2015 04:53:43 + (UTC) P J P pj.pan...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tue, 13 Jan 2015 17:09:16 + (UTC) P J P pj.pan...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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.kersla...@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@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 -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 p...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Mon, 12 Jan 2015 20:39:35 +0100 Milan Keršláger milan.kersla...@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 pgph0w9ibZwKJ.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 12 January 2015 at 11:58, P J P pj.pan...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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.kersla...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 p...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 12 January 2015 at 12:52, Milan Keršláger milan.kersla...@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.kersla...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Am Montag, den 12.01.2015, 17:20 + 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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-...@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-...@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 p...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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.kersla...@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 p...@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@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 -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 p...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 12 January 2015 at 06:05, P J P pj.pan...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Fri, Jan 9, 2015 at 5:07 PM, Reindl Harald h.rei...@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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Once upon a time, Przemek Klosowski przemek.klosow...@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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 r...@local.rhsoft.net Permission denied (publickey). [root@rawhide ~]# PasswordAuthentication no ChallengeResponseAuthentication no GSSAPIAuthenticationno GSSAPICleanupCredentialsno X11Forwarding no RSAAuthentication yes PubkeyAuthenticationyes PermitEmptyPasswordsno PermitRootLogin without-password signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Fri, Jan 9, 2015 at 4:14 PM, Paul Wouters p...@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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 r...@local.rhsoft.net Permission denied (publickey). [root@rawhide ~]# signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Fri, Jan 9, 2015 at 4:51 PM, Reindl Harald h.rei...@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). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Jan 2015 08:43:48 -0500 Stephen Gallagher sgall...@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 p...@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
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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,1 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 8 January 2015 at 15:19, Reindl Harald h.rei...@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,1 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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,1 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 p...@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). signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 p...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Thu, 08 Jan 2015 11:10:36 -0500 Adam Jackson 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Thu, Jan 8, 2015 at 8:43 AM, Stephen Gallagher sgall...@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 p...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Once upon a time, Laurent Rineau laurent.rineau__fed...@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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Am 08.01.2015 um 15:52 schrieb Chris Adams: Once upon a time, Laurent Rineau laurent.rineau__fed...@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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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...
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
