Harden Alpine SSH installation against CVE-2026-123158 (SSHole)

[memparanoid]

Summary

While reviewing Coolify's SSH installation flow following the November 5, 2026 OpenSSH security advisory, I noticed a configuration gap worth addressing.

Coolify officially supports Alpine Linux, and its installer can install and enable OpenSSH automatically without explicitly disabling password authentication.

This is a hardening proposal, not a claim that Coolify itself contains the OpenSSH vulnerability.

Current behavior

In scripts/install.sh, the Alpine installation branch contains:

alpine | postmarketos)
    apk add openssh >/dev/null
    rc-update add sshd default >/dev/null 2>&1
    service sshd start >/dev/null 2>&1
    ;;

Source:
https://github.com/coollabsio/coolify/blob/main/scripts/install.sh

The installer does not explicitly configure PasswordAuthentication no or verify its effective value before enabling the service.

It also checks PermitRootLogin, accepting yes, without-password, or prohibit-password as valid configurations.

Coolify itself uses public-key authentication and passes -o PasswordAuthentication=no to its SSH client.

However, disabling password authentication in the client does not disable password authentication in the SSH server.

As a result, an Alpine host provisioned through Coolify may continue accepting password authentication attempts from other SSH clients.

Security impact — CVE-2026-123158

On November 5, 2026, Alpine Linux disclosed an OpenSSH password authentication bypass affecting certain musl-based systems without PAM.

Under specific conditions, an unauthenticated remote attacker may authenticate to an account that should not accept password-based logins.

Relevant conditions include:

• An affected OpenSSH server using musl without PAM.
• PasswordAuthentication yes.
• An accessible account whose shadow password field contains *.
• At least one local account using a $5$ or $6$ password hash.

This does not mean every Alpine installation or Coolify deployment is vulnerable.

The concern is that Coolify can install and start OpenSSH while leaving one of the necessary conditions enabled.

Because Coolify manages container infrastructure, a compromised administrative SSH account may also provide access to Docker or other privileged host resources.

Official advisory:
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/

CVE:
https://nvd.nist.gov/vuln/detail/CVE-2026-123158

Proposed improvement

1. Enforce key-only SSH authentication for new Alpine installations

Once the installer's public key has been installed and key-based access has been verified, configure the SSH server with:

PasswordAuthentication no
PubkeyAuthentication yes

Validate the configuration with sshd -t and inspect its effective values using sshd -T before restarting the service.

2. Detect unsafe existing configurations

When OpenSSH is already installed, inspect its effective configuration.

If Alpine uses PasswordAuthentication yes, display a prominent warning explaining the CVE and recommending an immediate OpenSSH update.

Also distinguish PermitRootLogin yes from prohibit-password rather than treating both as equivalent security configurations.

3. Preserve operator access

Do not silently modify an existing SSH configuration without verifying that public-key authentication works.

An automatic hardening step should not unexpectedly lock operators out of remote servers.

4. Update security documentation

Document that Coolify's SSH client configuration does not secure the SSH server itself.

Recommend disabling password authentication on managed hosts where password-based access is unnecessary.

Affected installations should update OpenSSH and restart sshd independently of this installer improvement.

Expected benefits

• Removes the password authentication path from newly provisioned Alpine hosts.
• Reduces reliance on SSH server defaults.
• Makes the installer's security guarantees more explicit.
• Warns operators about configurations affected by a known authentication bypass.
• Preserves existing access through appropriate validation.

Scope and limitations

I have not demonstrated exploitation of a Coolify installation.

This report concerns a potential unsafe SSH configuration under the specific conditions described in the upstream advisory.

The objective is not to attribute an upstream OpenSSH vulnerability to Coolify.

Rather, it is to ensure that when Coolify provisions an SSH server, its installation process does not unnecessarily preserve a known authentication risk.

This improvement should be possible without changing Coolify's SSH-based deployment architecture.