jamilxt

Posted on Nov 6

How to Audit and Fix the Alpine OpenSSH Password Bypass

#security #linux #openssh #tutorial

A server can appear to reject password logins and still have a configuration worth checking. On November 5, 2026, Alpine Linux published an advisory for an OpenSSH password-authentication bypass affecting particular musl-based, non-PAM configurations. The attacker does not need a correct password: under the required conditions, an oversized password can authenticate to an account whose password field is *.[1]

This is not a reason to assume every Linux server is vulnerable. The issue depends on a specific interaction among OpenSSH, musl, PAM, password-authentication settings, and account records. Alpine’s own advisory says systems using openssh-server-pam with UsePAM yes, systems with password authentication disabled, and containers not running sshd are not affected.[1]

This guide turns that report into an operational audit: identify whether an Alpine host runs SSH, check the effective configuration and installed package, apply the distribution’s fix, restart the daemon, and verify the result without locking yourself out. It is based on the Alpine and OpenSSH advisories, not on testing a vulnerable server.

Why a very long password matters

The short version: musl’s crypt() function returns * as an error indicator when a password is longer than 256 bytes. An account without a password can also have * in its password field. In the affected authentication path, those two values could be treated as a match.[1]

The conditions matter. Alpine says the issue applies when sshd checks passwords without PAM, password authentication is enabled, there is an account with a * password field, and at least one local account has a $5$ or $6$ password hash. The attacker also needs network access to SSH and the name of an eligible account. Password lengths from 257 to 1,024 bytes were reported as the trigger range.[1]

That means “we use SSH keys” is not sufficient evidence that a host is safe. A key-only account may have no password set, yet the server can still accept password attempts unless the effective SSH configuration disables that method. Likewise, an account’s * field means no usable password is set; it is not the same thing as a locked account with ! in the password field.[1]

Do not copy exploit strings or test this against a production host. The safe response is to determine the runtime and configuration, then patch or disable password authentication.

Step 1: Find Alpine systems that actually run SSH

Start with inventory, not assumptions based on a container image name. Alpine containers often do not run an SSH daemon at all. The advisory explicitly excludes containers and other systems that do not run sshd.[1]

On each suspected Alpine machine, inspect the distribution, package, and service state:

cat /etc/alpine-release
apk info -e openssh-server openssh-server-pam openssh
rc-service sshd status
ps | grep '[s]shd'

The exact package names depend on how the server was installed. Alpine’s standard openssh-server package is built without PAM. The separate openssh-server-pam package can also be affected if configured with UsePAM no; with UsePAM yes, Alpine says it is not affected.[1]

For fleet review, run these checks through the configuration-management or remote-execution system you already trust. Avoid broad shell one-liners that silently ignore unreachable hosts. Record the hostname, Alpine branch, installed OpenSSH package version, whether sshd is running, and the effective authentication settings. A missing response should be recorded as “not checked,” not “not vulnerable.”

Step 2: Check effective settings, not just one config line

OpenSSH configuration can include drop-in files and Match blocks. A text search of /etc/ssh/sshd_config alone may not show the value that applies to a particular connection. Use the daemon’s configuration test and effective configuration output:

sshd -t
sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) '

The important values are passwordauthentication and, for the PAM package, usepam. The general safe mitigation is passwordauthentication no. If you are assessing a user- or address-specific Match rule, evaluate the effective configuration for the relevant connection parameters using the supported sshd -T -C form for your OpenSSH version and configuration.

Do not infer that PermitRootLogin prohibit-password resolves the whole issue. It restricts root password login, but another passwordless account may still be reachable, and it may have privileges to become root. Alpine notes that this is especially relevant to its tiny-cloud images, where certain releases include an alpine account with passwordless doas.[1]

Step 3: Upgrade to the fixed package

Alpine recommends updating the package and restarting sshd. Its November 5 release announcement lists fixed stable releases 3.21.10, 3.22.8, 3.23.8, and 3.24.4.[2] The security advisory also publishes fixed package revisions for older branches, including branches that no longer receive regular support.[1]

On a maintained Alpine system, the documented full upgrade command is:

apk upgrade -U -a

Then restart the service:

rc-service sshd restart

Do not treat a successful package upgrade as proof that the running daemon has changed. Alpine specifically warns that upgrading does not replace an already-running sshd; restarting it is required.[1]

Check the package revision after the upgrade:

apk info -v openssh-server openssh-server-pam openssh 2>/dev/null

Compare the installed openssh revision with the fixed revision for your branch in Alpine’s advisory. Avoid comparing only the upstream OpenSSH version string: distributions may backport the fix into an older-looking version. The Alpine package revision is the relevant evidence for Alpine-managed systems.[1]

If the host is on an unsupported release, plan a supported upgrade rather than assuming that a package update settles long-term risk. Alpine published fixed packages back to 3.16 for this specific issue, but that does not make an end-of-support operating-system branch a good ongoing security baseline.[1]

Step 4: If you cannot update yet, disable password authentication

Alpine’s interim mitigation is to set PasswordAuthentication no and restart sshd.[1] Before changing access remotely, confirm that public-key login works in a second session. Keep your current administrative connection open until a new connection succeeds. A syntax error or lost key access can turn a security change into an outage.

Edit the configuration using the method appropriate for your release and configuration management. On Alpine releases that read /etc/ssh/sshd_config.d/, a drop-in can be used; older releases may ignore that directory. Confirm the main configuration includes the directory before relying on it. Alpine documents an alternate method for older releases in its advisory.[1]

After editing, validate before restarting:

sshd -t && rc-service sshd restart
sshd -T | grep -i '^passwordauthentication '

The expected effective output is:

passwordauthentication no

If the output still says yes, stop and investigate included configuration and Match rules. Do not close the existing session until you have opened a new SSH session with the intended authentication method.

Step 5: Verify the daemon, then assess possible access

A practical verification has three parts:

Package: the installed Alpine openssh revision is at or above the fixed revision for that branch, or password authentication is demonstrably disabled as a temporary mitigation.
Runtime: the service was restarted, and the running process is the updated daemon. Confirm service status and inspect the process start time if your operations tooling exposes it.
Configuration: sshd -T reports the intended effective settings. If access rules differ by user or source address, check those contexts too.

If the host may have been reachable while vulnerable, inspect authentication logs for successful password logins to accounts with no password set. Alpine specifically recommends looking in /var/log/messages for sshd entries such as Accepted password for those accounts. Also review doas activity, recently created users, modified authorized_keys files, and unexpected files or processes.[1]

A suspicious successful login should be treated as an incident, not as a patching-only task. Preserve logs and relevant system state, isolate the host according to your incident-response process, rotate credentials and keys from a clean system, and investigate persistence. Alpine advises treating the machine as compromised if you cannot rule out a login.[1]

A compact SSH remediation checklist

Before closing the change, confirm each item:

[ ] Does the host run Alpine, and is sshd actually running?
[ ] Is the installed package PAM-enabled, and what is the effective UsePAM value?
[ ] Does the effective configuration allow password authentication?
[ ] Is the package revision fixed for this Alpine branch?
[ ] Was sshd restarted after the package upgrade?
[ ] Does sshd -t pass, and does sshd -T show the expected settings?
[ ] Can an administrator establish a fresh session using the intended access method?
[ ] Were relevant authentication and privilege-escalation logs reviewed if exposure is possible?

The key operational lesson is not “long passwords are dangerous.” It is that authentication depends on how several layers interpret the same value. A library error marker collided with a sentinel used for accounts without passwords, while a server-side fallback made the interaction reachable through SSH. The repair belongs at the server and package boundary: update to the maintained distribution fix, restart the service, and verify the effective configuration.

If you manage Alpine hosts, which part of your inventory makes it easiest to confirm the running SSH package and effective authentication settings? Share the check that works for your environment.

I write practical software engineering and security guides. Subscribe for future articles, and save the checklist above for your next Linux server review.

DEV Community