---
title: "Musl tabanlı Linux'ta uzun parola ile root erişimi veren OpenSSH açığı"
description: "OpenSSH musl açığı, PAM'siz ve password authentication açık sshd'de 256 byte'tan uzun parolayla yıldızlı hesaplara giriş yaptırıyor."
url: "https://sezer.in/haberler/openssh-musl-acigi-uzun-parola-root/"
date: "2026-11-06T09:26:03+03:00"
updated: "2026-11-06T09:26:03+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/openssh-musl-acigi-uzun-parola-root/"
---

# Musl tabanlı Linux'ta uzun parola ile root erişimi veren OpenSSH açığı

OpenSSH musl açığı, musl libc kullanan Linux sistemlerde sshd'ye 257 ile 1.024 karakter arası bir parola gönderen saldırganı, parola kabul etmemesi gereken hesaplara sokabiliyor. Araştırmacı Özgün Kültekin'in \*sshole adını verdiği açık 2016'dan beri duruyor ve yalnızca PAM olmadan çalışan, password authentication açık sshd yapılandırmalarını etkiliyor. OpenSSH 10.6p2 ve sonraki build'ler korumalı.

## musl libc nedir ve nerede kullanılır?

musl libc, Linux için yazılmış bir C standart kütüphanesidir. Programların sistem çağrılarına, bellek yönetimine ve parola hash'leme gibi temel fonksiyonlara eriştiği katmandır. Küçük boyutu ve statik bağlamaya uygunluğu nedeniyle Alpine Linux ve embedded sistemlerde tercih edilir. En yaygın alternatifi GNU C Library, yani glibc'dir.

Alpine Linux musl libc ile geliyor ve AWS ile Azure'da resmî cloud image'ı var. Bu image'lardan sunucu açtıysanız ve sshd'de parola girişini kapatmadıysanız, bu açık doğrudan sizin envanterinize dokunabilir. Embedded cihazlarda da musl yaygın.

## Saldırının tuttuğu koşullar

Açık ancak şu koşulların hepsi bir arada olduğunda çalışıyor:

- Sistem glibc yerine musl libc kullanıyor
- Sshd PAM olmadan çalışıyor
- Password authentication açık
- Shadow dosyasında en az bir hesabın parola alanında yıldız (\*) var
- En az bir başka hesabın geçerli bir parola hash'i var

Hedef olabilecek hesaplar: root, sadece anahtarla giriş yapan deployment kullanıcıları ve LDAP kullanıcıları. Root'a doğrudan giriş yine `PermitRootLogin` ayarına bağlı. Bu ayar root'u koruyor olsa bile deploy kullanıcısı açıkta kalabilir.

Kökü musl'ün bir tasarım tercihinde. Musl, `crypt()` hash hesaplayamadığında NULL yerine tek karakterlik `*` döndürüyor ve 256 byte üstü parolaları reddediyor. Shadow'da parolasız hesapları işaretlemek için kullanılan karakter de aynı yıldız. Sshd'nin 2016'da kullanıcı adı taramasını engellemek için eklediği sahte hash adımı bu iki parçayı birleştiriyor.

## Alpine cloud image'larında OpenSSH musl açığı

Alpine'i container base image'ı olarak kullanıyorsanız çoğu container'da sshd çalışmaz. Risk asıl olarak Alpine tabanlı sanal makinelerde ve sshd koşturan container'larda. Bastion host olarak Alpine kullanıyorsanız onu listenin başına alın. Bu makineler internete açık ve tam olarak bu tür bir saldırıya maruz kalan noktalar.

Embedded cihazlarda durum daha zor. Firmware içindeki OpenSSH'yi siz güncelleyemiyorsanız, üreticinin 10.6p2 içeren bir güncelleme yayımlamasını beklemek zorundasınız. O zamana kadar o cihazlarda parola girişini kapatın veya SSH'yi yönetim ağı dışına açmayın.

## Hızlı kontrol

Önce sürüme ve etkin yapılandırmaya bakın. `sshd -T`, sshd'nin gerçekte uygulayacağı yapılandırmayı basıyor:

```
ssh -V
sshd -T | grep -i -E 'usepam|passwordauthentication|permitrootlogin'
awk -F: '$2 == "*" {print $1}' /etc/shadow
```

Çıktıda `usepam no` ve `passwordauthentication yes` görüyorsanız ve sürüm 10.6p2'den eskiyse sistem risk altında. Son komut parola alanı yıldız olan hesapları listeliyor; açığın hedef aldığı hesaplar bunlar.

## Yama veya geçici önlem

Kalıcı çözüm OpenSSH 10.6p2 veya sonrası. 10.6p2 yeni çıktı; Linux dağıtımınızın paketi bu sürüme ulaşmadıysa beklerken geçici önlemi uygulayın.

Geçici önlem basit: `/etc/ssh/sshd_config` içinde `PasswordAuthentication no` yazın ve sshd'yi yeniden başlatın. Alpine OpenRC kullandığı için:

```
rc-service sshd restart
```

Yeniden başlatmadan önce ikinci bir oturum açın ve anahtarla giriş yapabildiğinizi doğrulayın. Aksi halde uzak bir sunucuya erişiminizi kaybedersiniz. Parola girişine gerçekten ihtiyaç duyan kullanıcılarınız varsa, onları yama gelene kadar anahtara taşımak daha az riskli.

## Yamadan sonra log'lara bakın

Açığın istismar edildiğine dair bir belirti yok. Yine de yıldızlı hesaplardan biri parolayla oturum açtıysa bunu alarm sebebi sayın. Kültekin'in yazısında bunun için hazır bir komut var. Elinizdeki log'larda hızlı bir tarama da iş görür:

```
grep "Accepted password" /var/log/messages
```

Satırlarda root, deploy kullanıcınız veya bir LDAP hesabı geçiyorsa makineyi ele geçirilmiş kabul edin ve anahtarları yenileyin.