• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

Question AlmaLinux 9 - Hardening SSH Server breaks Plesk

marekp

New Pleskian
Server operating system version
AlmaLinux 9
Plesk version and microupdate number
18.0.66 Update #2
Hi to all,
I tried to harden the OpenSSH server. A first attempt was made with
Code:
sudo update-crypto-policies --set FUTURE
but this breaks Plesk with
Code:
Certificate signature verification failed; error info: error:03000098:digital envelope routines::invalid digest error:06880006:asn1 encoding routines::EVP lib (Error code: 2)
reverting to
Code:
sudo update-crypto-policies --set DEFAULT:SHA1
works.

Is this an Plesk Issue or an AlmaLinux 9 Issue?
 
You shouldn't be using the future set since that's meant for testing and what not to begin with (you can read more over at Strong crypto defaults in RHEL 8 and deprecation of weak crypto algorithms - Red Hat Customer Portal). Even more so since Plesk would only release things based off of current requirements.

Ideally the best way to harden SSH is to ensure the following:
  • Enable Certificate Based Authentication
  • Disable Password Authentication
  • Disable Empty Passwords
  • Disable Root Login
  • Change Default SSH Port
  • Only Allow Selected Users and/or Groups
  • Disable X11 Forwarding
Generally speaking as long as you've done those you should be pretty good in terms of hardening your SSH. Although I'd probably take it a step further by not opening the SSH port to the public to begin with regardless of it being on a new port or not and instead use a zero trust solution like tailscale or set up an instance of teleport to get access to the the server that way.
 
Hi, I had already adjusted sshd accordingly. However, an ssh audit shows that insecure encryption algorithms are still allowed:
“(kex) diffie-hellman-group-exchange-sha1 (3072-bit) -- [fail] using broken SHA-1 hash algorithm”
“(kex) diffie-hellman-group14-sha1 -- [fail] using broken SHA-1 hash algorithm”

But I assume that Plesk still needs SHA1
 
Back
Top