[{"data":1,"prerenderedAt":226},["ShallowReactive",2],{"seo-verification":3,"blog-openssh-10-6p2-alpine-password-bypass-check-fix-ma-en":6,"promo-bar-likely":20},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-openssh-10-6p2-alpine-password-bypass-check-fix-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":20,"publishedAt":21,"updatedAt":22,"category":23,"categories":29,"featuredImage":31,"bgImage":32,"posterImage":33,"relatedSolution":31,"intro":34,"sections":35,"ctaTitle":166,"ctaBody":167,"ctaButton":168,"ctaUrl":169,"relatedPosts":170},570,"openssh-10-6p2-alpine-password-bypass-check-fix",{"fr":12,"en":10,"ar":13,"es":14},"openssh-10-6p2-alpine-contournement-mot-de-passe-verifier","ثغرة-openssh-10-6p2-تجاوز-كلمة-المرور-alpine-فحص","openssh-10-6p2-alpine-omision-contrasena-verificar","OpenSSH 10.6p2: password bypass on Alpine","OpenSSH 10.6p2 fixes a password authentication bypass on Alpine and musl: check your exposure, update the package, restart sshd and look for traces in your logs.",9,0,false,true,"2026-11-06T00:00:00+00:00","2026-11-08T01:13:02+00:00",{"id":24,"name":25,"slug":26,"color":27,"icon":28},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[30],{"id":24,"name":25,"slug":26,"color":27,"icon":28},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fopenssh-10-6p2-alpine-contournement-mot-de-passe-verifier-poster.svg","On November 5, 2026, OpenSSH 10.6p2 fixed a password authentication bypass that affects Linux systems running musl whose `sshd` is built without PAM, starting with Alpine. A password of 257 to 1024 bytes is enough to log in to an account that has no password, as long as another account on the machine has one. Debian, Ubuntu and AlmaLinux systems are not affected. Here are the five conditions, the verification procedure, the fixed packages for each Alpine branch and the traces to look for in your logs, including in your containers and images.",[36,40,49,52,85,88,116,147,150,153,156,163],{"type":37,"title":38,"body":39},"h2","What OpenSSH and Alpine say, and what they do not say","OpenSSH 10.6p2 was released on November 5, 2026. Its release notes announce the fix for a password authentication bypass, exploitable through `sshd`, on some Linux systems built without PAM. The same day, Alpine Linux published an advisory that details the mechanism, the conditions and the fixed packages. The flaw was reported by Özgün Kültekin, of Wakefield.\n\nTwo points are worth noting before you act. First, no CVE identifier had been assigned at the date of the Alpine advisory. Some press articles cite one, and we do not repeat it for lack of a primary source. Second, the OpenSSH maintainers consider that the root cause lies outside `sshd`, and they worked around the problem in `sshd`. The fix is therefore in the OpenSSH package, not in the C library. As we write, we know of no public report of exploitation, but the technical detail is public: assume that scans will follow.",{"type":41,"title":42,"items":43},"ul","The five conditions, all required",[44,45,46,47,48],"**A musl C library** — this is the case for Alpine, and for other embedded systems that use musl, such as OpenWrt. Debian, Ubuntu, Fedora and AlmaLinux use glibc and are not affected.","**`sshd` without PAM** — Alpine's `openssh-server` package is built without PAM, and so is `openssh-server-pam` with `UsePAM no`. With `UsePAM yes`, you are not affected.","**`PasswordAuthentication yes`** — this is the OpenSSH default. If you have set it to `no`, the flaw cannot be reached.","**An account whose password field is `*`** — a user created without a password for key-based login, a directory user managed by musl-nscd, or the `alpine` user of the official cloud images.","**At least one other account with a real password** (a `$5$` or `$6$` hash) — a single one is enough to expose every account that has no password.",{"type":37,"title":50,"body":51},"Why a 257-byte password is enough","Without PAM, `sshd` hashes the submitted password with `crypt()` and compares the result with the field stored in `\u002Fetc\u002Fshadow`. For accounts whose field is too short to hold a salt, `sshd` borrows the salt of another account, so that response time does not reveal that a username has no password.\n\nOn musl, `crypt()` returns the string `*` as an error value when the key exceeds 256 bytes. But `*` is also, in `\u002Fetc\u002Fshadow`, the value of an account with no password. The comparison succeeds: the login goes through, and nobody has guessed anything. The Alpine advisory gives the exploitable window: a password of 257 to 1024 bytes. This is neither a cryptographic weakness nor a memory corruption. It is a logic error: an error value taken for a result.",{"type":53,"title":54,"headers":55,"rows":59},"comparison","Who is affected, who is not",[56,57,58],"Configuration","Affected?","Why",[60,64,68,71,74,77,81],[61,62,63],"Alpine, `openssh-server`, passwords enabled, one account at `*` and one account at `$6$`","Yes","All five conditions are met",[65,66,67],"Alpine, `openssh-server-pam` with `UsePAM yes`","No","Authentication goes through PAM, not through `crypt()` in `sshd`",[69,66,70],"Alpine with `PasswordAuthentication no`","No password authentication is attempted",[72,66,73],"Debian, Ubuntu, AlmaLinux, Rocky (glibc)","The comparison does not receive the `*` error value",[75,66,76],"Alpine container without `sshd`","No SSH service to attack",[78,79,80],"Account locked with `!` instead of `*`","Not for this account","`!` does not match the error value",[82,83,84],"Official Alpine cloud image, no password set","Not at first boot","The advisory says it becomes exploitable as soon as a `$6$` hash appears, for example a password set at the console",{"type":37,"title":86,"body":87},"\"I am on Debian or Ubuntu: does this affect me?\"","No, not for this flaw: it requires musl. The objection is still worth raising, because the useful question for a fleet lies elsewhere: where do you find Alpine without having chosen it? A container image that bundles an `sshd` for troubleshooting, a network appliance, a router running OpenWrt, an image built with Buildroot or Yocto: all of them may rest on musl, depending on how they were built. On a VPS running Debian or Ubuntu, the exposure comes from an Alpine container with `sshd` that you run there, not from the host system.\n\nAn inventory takes two commands per machine: `ls \u002Flib\u002Fld-musl*` tells you whether the system uses musl, and `ps aux | grep sshd` tells you whether an SSH service is running. Do it in your containers too, because an image rebuilt last year may still carry the old package.",{"type":89,"title":90,"steps":91},"steps","Check your exposure, then fix it",[92,95,98,101,104,107,110,113],{"title":93,"body":94},"Confirm that the system uses musl","Run `ls \u002Flib\u002Fld-musl*` or `ldd --version 2>&1 | head -1`. On Alpine, the answer mentions musl. On glibc, there is nothing to do for this flaw.",{"title":96,"body":97},"Note the OpenSSH version and the PAM variant","`apk info -vv | grep '^openssh'` lists the installed packages. Note whether `openssh-server-pam` is present, then check `UsePAM` in `\u002Fetc\u002Fssh\u002Fsshd_config`.",{"title":99,"body":100},"Read the configuration actually applied","`sshd -T | grep -i -E 'passwordauthentication|usepam|permitrootlogin'` prints the effective values, including those from `Match` blocks and included files. A line read in the file is no substitute for this check.",{"title":102,"body":103},"List the accounts at `*` and the accounts with a real password","`awk -F: '$2==\"*\" {print $1}' \u002Fetc\u002Fshadow` gives the accounts without a password; `awk -F: '$2 ~ \u002F^\\$[56]\\$\u002F {print $1}' \u002Fetc\u002Fshadow` gives those that have a hash. If neither list is empty, conditions 4 and 5 are met.",{"title":105,"body":106},"Update the package","`apk upgrade -U -a` installs the fixed version. Alpine has published fixed packages for all its branches, down to 3.16, including those that are no longer supported.",{"title":108,"body":109},"Restart the service, otherwise nothing is fixed","`rc-service sshd restart`. Updating the package does not replace the running daemon: until it is restarted, the old code keeps answering. Keep one session open during the restart and test a second connection before closing it.",{"title":111,"body":112},"Check the result","Re-run `apk info -vv | grep '^openssh'`, then `sshd -T | grep -i passwordauthentication`. After that, open a key-based connection from another machine to confirm that access works.",{"title":114,"body":115},"Rebuild the images","A container image or a VM image cannot be fixed in place: rebuild it from a fixed base, then redeploy it. Record the date of the fix in the environment's file.",{"type":53,"title":117,"headers":118,"rows":122},"Fixed packages by Alpine branch",[119,120,121],"Branch","Fixed openssh package","Branch version",[123,127,131,135,139,143],[124,125,126],"edge","10.6_p2-r0","—",[128,129,130],"3.24","10.3_p1-r2","3.24.4",[132,133,134],"3.23","10.2_p1-r1","3.23.8",[136,137,138],"3.22","10.0_p1-r11","3.22.8",[140,141,142],"3.21","9.9_p2-r1","3.21.10",[144,145,146],"3.20 and older (down to 3.16)","9.7_p1-r6 (3.20); 9.0_p1-r6 (3.16)","Unsupported branches",{"type":37,"title":148,"body":149},"Look for traces before concluding that all is well","A fix removes the flaw; it does not erase what an attacker did before. The Alpine advisory recommends searching `\u002Fvar\u002Flog\u002Fmessages` for `Accepted password for` lines that concern accounts that are not supposed to have a password: `alpine`, `root` or a user reserved for key-based logins. Such a line is a strong indication, since these accounts should never log in with a password.\n\nFor the accounts that appear, then check the use of `doas`, recently created users, modified files and the contents of every `authorized_keys`. The advisory leaves no doubt about what to do: if you cannot rule out a login, treat the machine as compromised, rebuild it and renew the secrets it held. On the official cloud images, the risk is higher: the `alpine` user has passwordless `doas` there, which allows becoming root once inside.",{"type":151,"body":152},"tip","Cannot update right away? Disable password authentication, after checking that a key-based connection works and keeping your current session open. Alpine suggests a file in `\u002Fetc\u002Fssh\u002Fsshd_config.d\u002F` containing `PasswordAuthentication no` (the directory is read by default since 3.19), provided that no `PasswordAuthentication yes` line remains in a `Match` block. Finish with `sshd -t`, a restart, then `sshd -T | grep -i passwordauthentication`, which must print `passwordauthentication no`. To undo it, delete that file.",{"type":37,"title":154,"body":155},"Troubleshooting: what you may see when applying the fix","The messages below are OpenSSH messages. They appear on the client side in the terminal, and on the server side in the service log.",{"type":41,"title":157,"items":158},"Messages and remedies",[159,160,161,162],"**`Permission denied (publickey).`** — after turning passwords off, your key is not accepted. Keep the session open, check the account's `~\u002F.ssh\u002Fauthorized_keys` (permissions `600`, directory `700`), then re-read `sshd -T | grep -i pubkeyauthentication`. Do not close the original session until you have a second connection that works.","**`Bad configuration option`** followed by a name, with a line number from `\u002Fetc\u002Fssh\u002Fsshd_config` — a typo in the file or in the included file. `sshd -t` reports it before the restart: never restart without this check.","**`sshd: no hostkeys available -- exiting.`** — the host keys are missing, for example in an image where they were not generated. Generate them with `ssh-keygen -A`, then restart the service.","**The daemon still answers with the old version** — you updated the package without restarting. Run `rc-service sshd restart`, then re-read the version announced at connection.",{"type":37,"title":164,"body":165},"What this flaw says about your fleet","It does not come from a spectacular bad practice: one account without a password, another with a password, a default value. Each of these choices is common, and it is their combination on an uncommon system that creates the exposure. The lasting answer is the same as before the flaw: on any server reachable from the Internet, authenticate with keys, disable passwords, and know which images and which containers carry an `sshd`.\n\nIf you have already hardened your access, this alert is settled in ten minutes per machine. If not, it is an opportunity to do so: the full procedure is described in our first SSH access guide, and updating OpenSSH 10.6 without locking yourself out is covered in the article devoted to that version. A ServOrbit VPS gives you root access and the choice of system, which leaves you in control of these settings.","A server whose access you control","On a ServOrbit VPS, you have root access, your choice of system and control over the SSH configuration: keys, passwords disabled, updates at your own pace.","Discover our VPS","\u002Fvps-cloud",[171,188,207],{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":180,"views":181,"isPinned":19,"noindex":19,"publishedAt":182,"updatedAt":183,"category":184,"categories":185,"featuredImage":31,"bgImage":32,"posterImage":187,"relatedSolution":31},494,"openssh-10-6-security-update-sshd",{"fr":175,"en":173,"ar":176,"es":177},"openssh-10-6-mise-a-jour-securite-sshd","تحديث-openssh-10-6-أمان-sshd","openssh-10-6-actualizacion-seguridad-sshd","OpenSSH 10.6: update sshd without losing access","OpenSSH 10.6 security update: check the version actually running, what may break (ProxyCommand, Compression) and reload sshd safely.",12,2,"2026-10-22T00:00:00+00:00","2026-11-09T20:55:16+00:00",{"id":24,"name":25,"slug":26,"color":27,"icon":28},[186],{"id":24,"name":25,"slug":26,"color":27,"icon":28},"\u002Fblog\u002Fcovers\u002Fopenssh-10-6-mise-a-jour-securite-sshd-poster.svg",{"id":189,"slug":190,"slugs":191,"title":195,"excerpt":196,"readTime":181,"views":197,"isPinned":19,"noindex":20,"publishedAt":198,"updatedAt":199,"category":200,"categories":204,"featuredImage":31,"bgImage":32,"posterImage":206,"relatedSolution":31},452,"first-ssh-login-vps",{"fr":192,"en":190,"ar":193,"es":194},"premier-acces-ssh-vps","أول-اتصال-ssh-بخادم-vps","primer-acceso-ssh-vps","Log in to your VPS over SSH for the first time","Retrieve your VPS root password with the one-time link received by email, then log in to your server over SSH for the first time.",1,"2026-10-16T00:00:00+00:00","2026-10-16T01:57:35+00:00",{"id":180,"name":201,"slug":202,"color":203,"icon":202},"Guides","guides","bg-emerald-500\u002F10 text-emerald-400",[205],{"id":180,"name":201,"slug":202,"color":203,"icon":202},"\u002Fblog\u002Fcovers\u002Fpremier-acces-ssh-vps-poster.svg",{"id":208,"slug":209,"slugs":210,"title":214,"excerpt":215,"readTime":216,"views":197,"isPinned":19,"noindex":19,"publishedAt":217,"updatedAt":218,"category":219,"categories":220,"featuredImage":31,"bgImage":32,"posterImage":222,"relatedSolution":223},109,"fail2ban-enhanced-on-vps-blocking-repeated-attacks",{"fr":211,"en":209,"ar":212,"es":213},"proteger-vps-fail2ban","fail2ban-enhanced-على-خادم-vps-حجب-الهجمات-المتكررة","fail2ban-en-vps-bloquear-ataques-repetidos","Fail2Ban Enhanced on VPS: blocking repeated attacks","Link Fail2Ban Enhanced to the ServOrbit catalog: SSH\u002FNginx banning, readable logs and official documentation.",11,"2026-03-03T00:00:00+00:00","2026-11-01T14:14:36+00:00",{"id":24,"name":25,"slug":26,"color":27,"icon":28},[221],{"id":24,"name":25,"slug":26,"color":27,"icon":28},"\u002Fblog\u002Fcovers\u002Fproteger-vps-fail2ban-poster.svg",{"categorySlug":224,"appSlug":225},"securite","fail2ban-enhanced",1794270463313]