OpenSSH 10.6p2: sjekk musl-systemer uten å miste SSH-tilgangen

Status 8. november 2026. Portable OpenSSH 10.6p2 ble utgitt 5. november med et kritisk beskyttelsestiltak mot mulig omgåelse av passordautentisering på enkelte Linux-systemer med musl uten PAM. Veiledningen hjelper administratorer å avklare berørthet og verifisere en oppdatering uten å låse seg ute. Dette er ikke en egen produkt- eller angrepstest. [1]

Hvilke systemer må undersøkes?

Det avgjørende er OpenSSH-serveren som faktisk kjører, ikke bare distribusjonsnavnet. Musl-varselet angir OpenSSH før 10.6p2 med UsePAM=no og PasswordAuthentication=yes; bygg uten PAM-støtte må også vurderes. Alpine er et eksempel, ikke en fullstendig liste. OpenSSH-vedlikeholderen unntar ikke-Linux-systemer, Linux/glibc og systemer som bruker PAM til passordautentisering fra akkurat denne feilen. Musl-varselet unntar Dropbear. Dette er ingen generell sikkerhetsgodkjenning. [2] [4]

Forutsetninger og klargjort gjenoppretting

Du trenger autorisert administratortilgang, dokumentasjon for pakke/image og en fungerende konsoll eller redningstilgang uavhengig av SSH. Hold en eksisterende økt åpen, men ikke betrakt den som garantert gjenoppretting. Beskytt kopier av konfigurasjon, inkluderte filer, pakkeversjoner og gjenopprettingsmateriale; ikke legg private vertsnøkler i supportsaker eller samtaler. Bruk støttet fastvare på appliances, ikke vilkårlig utskifting av kjørbare filer.

Fem trinn til verifisert tilstand

  1. Kartlegg serveren: fastslå serverpakke, libc, PAM-støtte i bygget og aktiv tjeneste fra pakkedata, leverandørvarsler og image-metadata. ssh -V viser den lokale klienten, ikke serveren. Der det støttes viser sshd -V versjonen av den kalte serverfilen, men ikke om den aktive prosessen bruker filen. Vurder tilbakeporterte rettelser etter leverandørens varsel, ikke bare versjonsnummeret. [3]
  2. Les effektive innstillinger: bruk riktig serverfil og tjenestens faktiske konfigurasjon med sshd -t for konfigurasjons-/nøkkelkontroll og sshd -T for innstillinger, med nødvendige rettigheter og stier. Ved Match-regler oppgis relevante -C-tilkoblingsparametere etter den installerte håndboken. Vurder PAM-bygg, UsePAM og passord samlet. Gyldig konfigurasjon beviser ikke at sårbarheten er rettet. [3]
  3. Handle straks ved berørt kombinasjon: musl anbefaler PasswordAuthentication no som midlertidig tiltak. Kontroller først nøkkelinnlogging i en separat ny økt og tilgangen til redningskonsollen. Endre deretter den effektive konfigurasjonen kontrollert, valider og start tjenesten på nytt etter leverandørens anvisning. Uten sikker tilgang må du ikke bytte blindt: bruk konsoll/ansvarlig eller begrens eksponeringen gjennom godkjent nødprosedyre. Ikke aktiver PAM eller andre metoder på prøve. [2] [4]
  4. Installer leverandørrettelsen: bruk godkjent system-/appliancepakke eller image med 10.6p2-tiltaket eller dokumentert backport fra en pålitelig kilde. Klargjør gjenoppretting og vedlikeholdsvindu, og forny også den kjørende tjenesten etter anvisningen. Unngå fremmede pakkearkiver, overlagte kildekodebygg og global deaktivering av beskyttelse som snarvei.
  5. Koble til på nytt og godkjenn: test nøkkelinnlogging, nødvendige administratorrettigheter og påkrevde SFTP-/automatiseringsforløp i en ny forbindelse. Kontroller pakke/image, effektive regler og logger igjen; et utnyttelsesforsøk er ikke nødvendig. Lukk den opprinnelige økten først etter godkjenning. Ved feil gjenopprettes beskyttet tilstand kontrollert via konsollen; ikke behold en urettet, igjen eksponert passordtjeneste som permanent løsning.

Slik bekrefter du resultatet

Arbeidet er ferdig først når den dokumenterte rettelsen er aktiv i tjenesten og nye innlogginger og arbeidsflyter fungerer. Installert pakke, banner eller gammel økt er ikke nok. Vurder gjenaktivering av midlertidig deaktiverte passord først etter bekreftet rettelse og driftsgodkjenning. Fortsatt krav om nøkler kan være hensiktsmessig, men er en egen sikkerhetsbeslutning.

Begrensninger og kilder

Veiledningen endrer ingen server automatisk og erstatter ikke distribusjonsvarsel eller lokal godkjenning. Et eldre versjonsnummer kan inneholde rettelsen; ikke alle musl-enheter bruker OpenSSH. Avklar usikre bygg/backporter med leverandøren og prioriter avskjerming i mellomtiden. Ingen universell CVE-tilordning, angrepsdeteksjon eller gjennomført migrering hevdes.