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

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

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

    While upstream SSH has disabled password logins for the root user as their default configuration the past number of years and that has carried over into being the out-of-the-box behavior for many operating systems, Fedora continues allowing password-based SSH root log-ins by default. But with the next Fedora release they are thinking about changing that default behavior...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.
    Last edited by jukk; 17 May 2019, 10:45 AM.

    Comment


    • #3
      I personally enable root login via ssh on my PCs at home, because I'm not especially concerned about security. My router's built-in firewall blocks the port from the outside and my network is encrypted. In the event I want outside access, I'm going to change the port to something totally different. However, I do think blocking password-based root ssh logins is a very good idea as a default setting.

      Comment


      • #4
        Originally posted by schmidtbag View Post
        and my network is encrypted
        *wifi network

        ethernet isn't encrypted.


        Comment


        • #5
          Meh. Unless you disable ssh logins entirely (i.e. only pre-shared key logins) this isn't changing much.

          In most Linux systems you can login as the user, and then use the same password to sudo or su, and then you are root.

          As long as ssh server is disabled by default on a desktop, it should be fine for most end users.

          Comment


          • #6
            I always disable root login via SSH after an install. My logs fill up with failed login attempts as "root" along with "admin", "administrator" and other default usernames. I consider it just another small layer of security along with limiting login attempts, which accounts can be accessed via sshd (AllowGroups in sshd_config), who's in sudo, etc. Hardening is a journey, man

            Comment


            • #7
              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).

              Comment


              • #8
                Originally posted by swagg_boi View Post
                I always disable root login via SSH after an install. My logs fill up with failed login attempts as "root" along with "admin", "administrator" and other default usernames. I consider it just another small layer of security along with limiting login attempts, which accounts can be accessed via sshd (AllowGroups in sshd_config), who's in sudo, etc. Hardening is a journey, man
                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).

                Comment


                • #9
                  You can easily slow down brute force attempts with iptables. Example:
                  Code:
                  iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
                  iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
                  This will reduce login attempts to 3 per minute. Existing sessions won't be affected.

                  Other things that help are denyhosts or fail2ban. You could also DROP all IPs by default and enable only certain ip addresses or ranges from where to allow login.

                  Comment


                  • #10
                    I've always been a fan of fail2ban on my system with an open ssh port that faces the world. Of course I disallow root access and use pre-shared keys for my portable devices. At work I use a password for the only user on the system but have given myself unlimited attempts to get in, everyone else only gets two chances. Since May 12 there have only been 214 failed attempts and currently I have 50 locked out IP addresses. That said, some sites are really aggressive, following a reboot for a kernel update, one site managed 29 attempts with different names (all beginning with the letter 'a') until fail2ban got started.

                    Comment

                    Working...
                    X