OpenSSH 10.6p2: kontrollér musl-systemer uden at miste SSH-adgang

Status 8. november 2026. Portable OpenSSH 10.6p2 udkom 5. november med en kritisk afværgning af mulig omgåelse af adgangskodegodkendelse på visse Linux-systemer med musl uden PAM. Vejledningen hjælper administratorer med at afklare berørthed og kontrollere en opdatering uden at låse sig ude. Den bygger ikke på vores egen produkt- eller angrebstest. [1]

Hvilke systemer skal kontrolleres?

Det afgørende er den OpenSSH-server, der faktisk kører, ikke blot distributionens navn. Musl-meddelelsen nævner OpenSSH før 10.6p2 med UsePAM=no og PasswordAuthentication=yes; builds uden PAM-understøttelse skal også vurderes. Alpine er et eksempel, ikke en komplet liste. OpenSSH-vedligeholderen undtager ikke-Linux-systemer, Linux/glibc og systemer med PAM til adgangskodegodkendelse fra netop denne fejl. Musl-meddelelsen undtager Dropbear. Det er ikke en generel sikkerhedsgodkendelse. [2] [4]

Forudsætninger og klar gendannelse

Der kræves autoriseret administratoradgang, dokumentation for pakke/image og en fungerende konsol eller redningsadgang uafhængig af SSH. Hold en eksisterende session åben, men betragt den ikke som garanteret gendannelse. Beskyt kopier af konfiguration, inkluderede filer, pakkeversioner og gendannelsesmateriale; læg aldrig private værtsnøgler i supportsager eller chat. Brug understøttet firmware på appliances frem for at udskifte vilkårlige programmer.

Fem trin til en kontrolleret tilstand

  1. Kortlæg serveren: fastslå serverpakke, libc, PAM-build og aktiv tjeneste ud fra pakkedata, leverandørmeddelelser og image-metadata. ssh -V viser den lokale klient, ikke serveren. Hvis understøttet viser sshd -V versionen af den kaldte serverfil, men ikke om den aktive proces bruger filen. Vurder tilbageporterede rettelser efter leverandørens meddelelse, ikke kun versionsnummeret. [3]
  2. Læs effektive indstillinger: brug den korrekte serverfil og tjenestens faktiske konfiguration med sshd -t til konfigurations-/nøglekontrol og sshd -T til indstillinger, med nødvendige rettigheder og stier. Ved Match-regler angives relevante -C-forbindelsesparametre efter den installerede manual. Vurder PAM-build, UsePAM og adgangskoder samlet. En gyldig konfiguration beviser ikke, at fejlen er rettet. [3]
  3. Handl straks ved berørt kombination: musl anbefaler PasswordAuthentication no som midlertidig foranstaltning. Kontrollér først nøglelogin i en separat ny session samt redningskonsollen. Ændr derefter den effektive konfiguration kontrolleret, validér og genstart efter leverandørens anvisning. Uden sikker adgang må der ikke skiftes blindt: brug konsol/ansvarlig eller begræns eksponeringen efter godkendt nødprocedure. Slå ikke PAM eller andre metoder til som forsøg. [2] [4]
  4. Installér leverandørrettelsen: brug en godkendt system-/appliancepakke eller et image med 10.6p2-afværgningen eller dokumenteret backport fra en betroet kilde. Klargør gendannelse og vedligeholdelsesvindue, og forny også den kørende tjeneste efter anvisningen. Undgå fremmede pakkearkiver, overlejrede kildekodebuilds og global deaktivering af beskyttelse som genvej.
  5. Forbind igen og godkend: test nøglelogin, nødvendige administratorrettigheder og krævede SFTP-/automationsforløb i en ny forbindelse. Kontrollér pakke/image, effektive regler og logfiler igen; et angrebsforsøg er unødvendigt. Luk først den oprindelige session efter godkendelse. Ved fejl gendannes den beskyttede tilstand kontrolleret via konsollen; efterlad ikke en urettet, igen eksponeret adgangskodetjeneste som permanent løsning.

Sådan bekræftes resultatet

Arbejdet er først færdigt, når den dokumenterede rettelse er aktiv i tjenesten og nye login og arbejdsgange fungerer. En installeret pakke, et banner eller en gammel session er ikke nok. Overvej kun at genaktivere midlertidigt deaktiverede adgangskoder efter bekræftet rettelse og driftsgodkendelse. Fortsat krav om nøgler kan være passende, men er en særskilt sikkerhedsbeslutning.

Begrænsninger og kilder

Vejledningen ændrer ikke servere automatisk og erstatter ikke distributionsmeddelelse eller lokal godkendelse. Et ældre versionsnummer kan indeholde rettelsen; ikke alle musl-enheder bruger OpenSSH. Afklar usikre builds/backports med leverandøren og prioritér afskærmning imens. Der hævdes ingen universel CVE-tilknytning, angrebsdetektion eller gennemført migrering.