Skip to main content

Sec Advisor - SSH direct root logins - ignores prohibit-password? without-password is deprecated?

pkiff

Security Advisor flagged SSH because PermitRootLogin hadn't been turned off:
"SSH direct root logins - ignores prohibit-password - without-password is deprecated". 

The recommended values you provide are either "without-password" or "no". However, current SSH installations under Ubuntu and RockyLinux have deprecated "without-password", I think? Instead of "without-password", should you recommend "prohibit-password"? In my installation, that is actually the value sitting there in the sshd_config file already - commented out - just waiting for me to simply uncomment it.

Regardless of what the recommendation should be, the Sec Advisor test should include checking for the prohibit-password value. When I change my PermitRootLogin to that value doesn't clear the flag.

Comments

9 comments

Date Votes
  • pkiff

    Quick follow-up - maybe I'm wrong that the Sec Advisor is not registering the prohibit-password value. It turns out that even if I switch the value to "no", I'm still getting a red flag. I'm on a VPS. So maybe the hypervisor or whatever other software managing my VPS is actually messing with the security evaluation. Or maybe even my server is not secure, so it's not a false positive at all.

    0
  • cPRex Jurassic Moderator

    Hey there!  I wouldn't expect this to be something that is limited by the server being a VPS, but switching to option to "no" should resolve the warning.

    Could you submit a ticket so this can be investigated directly on this machine?

    0
  • pkiff
    • Edited

    Thanks for the follow-up. I partially resolved this by manually editing the sshd_config file and manually changing the key values to match those in the table provided in the SSH Password Authorization Tweak support page:
    https://docs.cpanel.net/whm/security-center/ssh-password-authorization-tweak/

    I believe that the SSH Password Authorization Tweak button didn't work on my cPanel installation for some reason. (Rocky Linux v9.5.0 STANDARD kvm cPanel Version 124.0.30).

    While searching for a solution, I came upon a similar issue from someone running AlmaLinux 9:
    https://support.cpanel.net/hc/en-us/community/posts/25664292288663-SSH-Password-Authorization-Tweak-Issue

    In any case, the changes that are supposed to occur with the button didn't actually take place. But when I manually edited the file, then the changes stuck.

    cPanel Security Advisor is still complaining about the issue and flagging it red, but the csf Check Server Security script went from flagging it in red to now passing it in green after I made the manual edits. So my theory now is that the cPanel Security Advisor is simply wrong?

    Actually, there's one more related item. The current SSH install on RockyLinux doesn't actually have a "ChallengeResponseAuthentication" key, and as I understand it, this has been replace in current versions with "KbdInteractiveAuthentication", which I set to "no". I didn't add the "ChallengeResponseAuthentication" key.

    I'd be happy to have someone from cPanel check the machine directly. I'm not sure how to submit a ticket?

    0
  • cPRex Jurassic Moderator

    You should be able to do this directly through WHM >> Create a Support Ticket.  If your license isn't purchased through us that page will direct you to your hosting provider.

    0
  • pkiff

    A quick follow-up for others who encounter this issue and to flag the issue for cPRex as others may find the instructions in the current Security Advisor (v1.04) warnings in RockyLinux/AlmaLinux 9+ to be misleading.

    It turns out that to fix this, I had to edit the etc/ssh/sshd_config.d/01-permitrootlogin.conf file and configure the setting manually there:
    PermitRootLogin no

    Current installs of RockyLinux/AlmaLinux 9+ (and maybe Debian and Ubuntu also?) all now ship with an include statement referenced at the top of the sshd_config file. The include statement causes all files with the *.conf extension found in the sshd_config.d folder to be loaded first, before the rest of the sshd_config file.

    There are a couple default .conf files including 01-permitrootlogin.conf, which sets the PermitRootLogin to yes. And that is where the effective PermitRootLogin directive comes from. The sshd_config directives are read in order from top to bottom, and only the first directive is applied for most settings.

    The advice in cPanel's Security Advisor says to edit the sshd_config file and add one of the PermitRootLogin restrictions. But if your sshd_config includes all the default *.conf files like mine did, then the PermitRootLogin should actually be set in the 01-permitrootlogin.conf file instead. Any changes you make further down the sshd_config file (including for example, uncommenting the "PermitRootLogin no" line) will be ignored.

    0
  • cPRex Jurassic Moderator

    pkiff - I do see that include on a test box - I'm looking into this now and I'll update you soon!

    0
  • cPRex Jurassic Moderator

    Thanks for pointing this out.  I'm wondering if this is specific to your environment as a minimal install of either AlmaLinux or RockyLinux doesn't have that 01-permitrootlogin.conf file.  Do you see other files in that location?

    I'm also not finding other reports of this behavior, which also leads me to believe this could be isolated to your environment.

    These files can be created as part of the OS image, so I'm wondering if that's what is happening here.  For example, in our testing environment we add an "init.conf" file to that directory so we can specify SSH options at the time the server is configured, but that wouldn't exist in a default OS install.

    0
  • pkiff

    Oh, thanks for checking. Yes, I do have two other files in that folder. My VPS host installed my RockyLinux OS, and they very well may have included those in their OS image.

    Having said that, I did find references on the Interwebs to the specific file named 01-permitrootlogin.conf which seems to be a standard file that may be added by the OS during an interactive installation if you check off the setting "Allow root log with password" in the installer. You can find stray mentions of it in discussions of Debian and AlmaLinux for example.

    0
  • cPRex Jurassic Moderator

    Oh it's real for sure, I just don't know if it's widespread enough where we should be taking some type of action in the interface.

    Just to be safe I created a test server over at DigitalOcean and that only has the 50-redhat.conf file:

    # pwd
    /etc/ssh/sshd_config.d
    [root@rockylinux-s-1vcpu-1gb-tor1-01 sshd_config.d]# ll
    total 4
    -rw-------. 1 root root 719 May  9  2023 50-redhat.conf
    [root@rockylinux-s-1vcpu-1gb-tor1-01 sshd_config.d]# cat 50-redhat.conf 
    # This system is following system-wide crypto policy. The changes to
    # crypto properties (Ciphers, MACs, ...) will not have any effect in
    # this or following included files. To override some configuration option,
    # write it before this block or include it before this file.
    # Please, see manual pages for update-crypto-policies(8) and sshd_config(5).
    Include /etc/crypto-policies/back-ends/opensshserver.config

    SyslogFacility AUTHPRIV

    ChallengeResponseAuthentication no

    GSSAPIAuthentication yes
    GSSAPICleanupCredentials no

    UsePAM yes

    X11Forwarding yes

    # It is recommended to use pam_motd in /etc/pam.d/sshd instead of PrintMotd,
    # as it is more configurable and versatile than the built-in version.
    PrintMotd no
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post