OpenSSH sshole: what an exploited Alpine login bypass says about the images you run

What happened

On musl-based Linux systems without PAM, OpenSSH before 10.6p2 could let an attacker log in to accounts that have no usable password, such as key-only users, by sending an over-long password²⁵. Alpine Linux's default openssh-server build fits that description, and other musl-based images may too; glibc-based distributions such as Debian, Ubuntu and Fedora are reported as not affected². OpenSSH released 10.6p2 on 5 November, and Help Net Security reports exploitation began within hours¹. The Hacker News reports attackers gained root on an Alpine honeypot³.

Reporting describes the mechanism as an interaction between two components rather than a bug in either alone: musl's password hashing function rejects oversized input with a value that happens to match how locked accounts are marked, and sshd compares the two⁵. OpenSSH and musl maintainers have publicly disagreed about where the fault lies⁴. For defenders, that debate matters less than the fact that each component behaved as its own authors expected.

Lesson 1: "minimal" images are not minimal attack surface

Alpine is popular because it is small, and small images are usually safer. But a small image that ships an SSH server is a small image with an internet-facing login service. The question to ask of every base image is not "how big is it?" but "what does it listen on, and who can log in?".

The flaw also only affected one C library. Many organisations do not know which of their images, appliances and embedded devices use musl rather than glibc, because nobody needed to. Add the C library and the presence of sshd to your image inventory; an SBOM per image makes this a query rather than a hunt. See supply chain security.

Lesson 2: state your intent, do not rely on side effects

Many hosts were exposed because password logins were never explicitly disabled; operators relied on accounts having no password. OpenSSH's developers advised setting PasswordAuthentication to no, or disabling SSH, until systems are patched². That is good practice regardless of this bug: configuration should say what you mean ("no password logins") rather than depend on the state of every account.

The same applies to default users in cloud images. Reporting notes that the default user on some official Alpine cloud images could become root, which turned a login bypass into full control². Review which default accounts your images ship with and what they can do.

Lesson 3: containers should not run SSH

A container that runs sshd invites people to log in and change it, and invites attackers to do the same. Containers should be rebuilt and replaced, not maintained by hand. Where engineers need to debug, use the orchestrator's audited access, and treat any container that someone has changed interactively as untrusted until it is replaced. The Kubernetes community has described exactly that pattern: tag pods that have been accessed interactively and evict them after a set time⁶.

For hosts that genuinely need SSH, put it behind a management network or an access broker, with short-lived certificates rather than static keys, and never on the open internet. See the management plane hardening case study.

What to do this week

CTO take

This was not an exotic attack. It exploited an assumption almost every team makes, on a base image almost every team uses, and attackers moved within hours. Teams with an image inventory, explicit SSH configuration and no SSH in containers will spend this week on a routine patch. Teams without them will spend it finding out where Alpine is running. Read alongside the 7 November tech news, where the flaw first appeared on this site.

How I can help

I help teams harden platforms, from base images and access paths to Kubernetes and management planes. I am based in India, the United States and the UAE, working globally. See fractional CTO work, where I work, or analyse your challenge and bring the result to a call.