OpenSSH on Alpine: verify accounts and the daemon after patching
Using SSH keys also requires checking which authentication paths the server accepts. SSHole calls for connecting accounts, effective configuration, the installed package and the running daemon.
Читати португальськоюBy Pentesty
Start with the service that actually receives connections
The OpenSSH 10.6p2 release notes, published on November 5, 2026, describe a safeguard against authentication bypass on certain Linux systems using musl with PAM disabled. The CVE record assigns High severity and a CVSS score of 8.1. Reports published on November 7 prompted this analysis, whose editorial date is separate from technical disclosure.
Previdian records exploitation attempts against its sensors and explains that these observations alone do not establish success. That evidence helps prioritize reachable services. A company needs to locate its own administration endpoints, owners and exposure periods before drawing conclusions about the scope of a possible incident.
Check conditions for each account and connection context
The Alpine advisory specifies combined conditions. The server uses musl without PAM, accepts password authentication, has an eligible account whose password field is * and at least one other local account with a $5$ or $6$ hash. Also identify who can reach the service. Finding an Alpine image in inventory calls for checking those conditions.
Alpine states that PermitRootLogin prohibit-password protects direct root login through this path. Impact depends on the reachable account and its permissions, including possible doas rights. Ask the administrator to classify relevant conditions locally and record the outcome. The report can retain identifiers and conclusions while keeping password hashes and complete account files within the administration environment.
Use effective configuration to decide the change
The sshd manual documents effective configuration inspection using -T and applying Match rules with connection parameters supplied through -C. Consult documentation for the installed package and include representative users and administrative paths. Relate a reviewed line in the main file to the connection context actually served.
For systems awaiting an update, Alpine recommends disabling PasswordAuthentication and restarting the daemon. Plan the change with operations, verify legitimate key access beforehand and maintain an approved recovery path. Record who performs the change, its window and how a fresh authorized connection will demonstrate the outcome.
Connect the fixed package to the running daemon
The distribution provides fixes on stable branches. For example, it lists 10.3_p1-r2 for Alpine 3.24, 10.2_p1-r1 for 3.23 and 10.0_p1-r11 for 3.22. Compare the branch and complete package revision with the current official table. An upstream version number alone can miss a legitimate backport.
Alpine requires restarting sshd after updating the package. Attach evidence of the installed version, the process change and resulting configuration, alongside an agreed legitimate administration check. Linux kernel patch acceptance examines another situation where package delivery needs to be connected to the component actually in use.
Address earlier indicators and coverage gaps
The advisory recommends investigating Accepted password for entries for accounts intended to use keys, alongside doas activity and changes to users, files and authorized keys. If an unauthorized login cannot be ruled out, Alpine advises treating the machine as compromised. Preserve available records and refer the investigation to the incident response owner.
Complete the assessment by asset and account, recording evidence origin, collection time, decision, owner and outstanding questions. Devices that did not report remain awaiting confirmation. Apply the check to deployment images and existing instances where they are in scope. Remediation accepted today should remain observable after configuration changes or image replacement.
Separate observed attempts from established outcomes
Editorial update: November 9, 2026
In a report published on November 8, 2026, the SANS Internet Storm Center added an independent sample of SSH attack attempts. Its Cowrie sensors recorded 232 entries with long passwords on November 5 and 713 the following day. Those figures describe requests, not compromised machines or unique attackers. The researcher identified attempts characteristic of SSHole from November 5, but presented successful access as an expectation still requiring analysis. Another limitation matters: collection retains only the first 255 password characters, restricting interpretation of longer inputs.
For a business, that limitation deserves its own field in investigation evidence. Identify which sensor produced the event, the period covered, what it records and where truncation occurs. Relate suspicious attempts to authentication decisions and sessions actually recorded by the server, respecting the configuration and reach of each source. In an authorized laboratory, use approved synthetic events and fictional values to check whether collection preserves the time, test identity and expected result. Record whether length is observed, inferred or unavailable, without retaining real passwords. Acceptance should distinguish the corrected package and running daemon, telemetry coverage and conclusions about earlier access. A gap in any of those areas remains explicit.
Connect the sensor observation to the server outcome
Editorial update: November 10, 2026
In its snapshot updated November 10, 2026 at 16:40 UTC, GreyNoise recorded 23 post-exploitation chains on its own vulnerable gridpoints. Its definition requires command execution by the SSH server and groups sessions on one gridpoint without a gap exceeding 30 minutes. These are observations from that infrastructure, not a count of compromised businesses. CISA added CVE-2026-123158 to KEV on November 9; the entry lists ransomware campaign use as unknown. Inclusion does not by itself create a uniform legal deadline for every business.
This evidence differs from a recorded attempt or a connection to the SSH port. In an authorized investigation of your environment, connect the asset identifier, authentication decision and observed execution where available. Preserve each record’s origin and time, and state any gaps, including when an external sensor cannot establish the host outcome. In a laboratory, approved synthetic events can check that association without reproducing the exploit or using real credentials. Assessment of earlier exposure remains separate from acceptance of the fixed package and the running daemon.
Frequently asked questions
Is an Alpine container automatically exposed?
Alpine excludes containers that do not run sshd from this scenario. For other containers, check authentication conditions, accounts and access to the service.
Does a version below 10.6p2 establish an unpatched system?
Check the full package revision and distribution branch. Alpine published backports under earlier upstream version numbers.
Does routinely using keys complete the assessment?
Check the methods the server actually accepts for the assessed accounts and connections. The method an administrator chooses in one session does not describe every applicable rule.
When can the rollout be accepted?
When the owner demonstrates the applicable package or measure, daemon state, effective configuration and continued legitimate access, with coverage gaps recorded.
Sources and references
- Cyber Security Brazil: editorial news reference
- CySecurity, second editorial reference about the same event
- OpenSSH, official 10.6p2 release notes
- Alpine Linux, exposure conditions and fixed packages
- CVE Program, CVE-2026-123158 record
- Previdian, observed attempts and telemetry limits
- OpenSSH, checking the daemon effective configuration
- Researcher, original analysis and authentication conditions
Original Pentesty analysis, published November 7, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.