Announcement

Collapse
No announcement yet.

Developers Start Debating Whether To Block Password-Based Root SSH Logins For Fedora 31

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by schmidtbag View Post
    I would be very careful about those failed attempts.
    fail2ban is a nice tool that can help in the "being careful" task.

    Comment


    • #12
      Originally posted by DrYak View Post
      fail2ban is a nice tool that can help in the "being careful" task.
      Ah cool, thanks for the tip. I wasn't aware of that.

      Comment


      • #13
        IMO for true and proper security, logging in as root should require a re-Captcha authentication. "Select all images of Busses" as this is how the internet sorts out good people from bad. The trick here, is find a way to implement it using ASCII.

        Comment


        • #14
          It amazes me how many developer hours get sucked into stuff like this with large distros. Can anyone tell me how many actual Fedora devs there are because my google-fu isn't helping.

          Even if you scale with the installed user base I'm guessing that it's less than the 80 or so that Arch has (and I'm including the folks that run the AUR).
          Ship upstream defaults as much as possible and spend less time debating, that way you can get more proper work done.

          Comment


          • #15
            Originally posted by Slithery View Post
            Ship upstream defaults as much as possible and spend less time debating, that way you can get more proper work done.
            Fedora does ship upstream defaults as much as possible

            https://fedoraproject.org/wiki/Stayi...tream_projects

            The defaults in this case for changed for several reasons. As an example: there are minimal installs with no non-root users setup remotely. The open discussion is to gather feedback to ensure those use cases aren't adversely affected and there are other ways to address it.

            Comment


            • #16
              Originally posted by jukk View Post
              On my own Internet facing machines, in addition to disabled root login, I have enabled 2FA using TOTP (google-authenticator). This is quite easy to do and increases security a lot. And it doesn't make it much harder to login. Except on a raspberrypi, when I forgot to enable NTP (it doesn't have a hardware clock) and the time had drifted (luckily it worked that time by waiting a cycle or two before entering the TOTP key).
              you can add a hardware clock on a raspi (or an Arduino), in case it's really necessary anyway.

              Comment


              • #17
                Originally posted by schmidtbag View Post
                I would be very careful about those failed attempts. I once had a test system where the root password was just "root" and after a few weeks, someone in China (not a stereotype, I confirmed the location of the IP address) got in. This was also the first time I had ever encountered malware on Linux. Considering the massive ssh log, it was made obvious that they logged in through brute-force, just testing every combination possible, so, you better hope your password is long or else it'll just be a matter of time until they manage to break in. Since all the login attempts were bogging down my network and making my logs huge, my solution to stop this problem was to just simply change the port number (and then I realized I never really used ssh from the outside, so, I just stopped forwarding it).
                This is ok for a home system. Real infrastructure uses stuff like fail2ban that will lock out IPs of bots bruteforcing their way (which would still bog down the network even if you disable the password login).

                EDIT: yes, ninjad by others

                Comment


                • #18
                  Originally posted by jukk View Post
                  Should be default on any machine. If you must use root (e.g. when automating something obscure that needs root), use a preshared key and set "PermitRootLogin forced-commands-only" in sshd_config. To tighten further, allow only certain commands in /root/.ssh/authorized_keys, or by referring to a separate file listing allowed commands.
                  preshared key doesn't guarantee good security, and is much harder to manage (rotation, centralised revocation).

                  I'd recommend instead: dont allow root login (without password vault/bastion), and only allow sudo rules with whitelisted commands. sudo root shell only with mfa.
                  Last edited by FrankL; 05-17-2019, 03:37 PM.

                  Comment


                  • #19
                    Originally posted by torsionbar28 View Post
                    IMO for true and proper security, logging in as root should require a re-Captcha authentication. "Select all images of Busses" as this is how the internet sorts out good people from bad. The trick here, is find a way to implement it using ASCII.
                    image to ascii converters are a thing you know https://picascii.com/

                    Comment


                    • #20
                      Having "root" logins enabled with sshd is not the same as using su or sudo after login... root is a known account with an instant win. Of course we can also configure sudo and make the su binary only accessible by a group like wheel so for example only one user can elevate. I'm not big on security (over functionality and performance) but this is the kind of good practice measure that costs nothing.

                      I don't like PAM, but I have often seen PAM policies prevent that anyway (minimum UID) in some distros even if root logins are enabled in sshd_config. A similar PAM config to login manager sessions.

                      One of the first things I do is check sshd_config when I bring up a new box, or get a new server, to make sure root logins are not permitted, and password logins are permitted. (Yep, I've seen such anal defaults).

                      Comment

                      Working...
                      X