OpenSSH’de Kritik Açık! (CVE-2026-123158) Kimler Risk Altında, Nasıl Korunulur?

OpenSSH sunucusunda (sshd), belirli Linux dağıtımlarını ve gömülü sistemleri doğrudan etkileyen kritik bir kimlik doğrulama atlatma (password authentication bypass) güvenlik zafiyeti duyuruldu. Hata parola ile giriş yetkisi bulunmayan veya şifresi tanımlanmamış hesaplara, parola bilinmeksizin tek bir bağlantıyla yetkisiz erişim sağlanmasına yol açıyor.

Hata Nasıl Ortaya Çıkıyor?

Bu zafiyet, iki farklı mimari tercihin bir araya gelmesiyle tetikleniyor: PAM (Pluggable Authentication Modules) desteği olmadan derlenmiş OpenSSH ve hafif sistemlerde yaygın olarak tercih edilen musl libc kütüphanesi.

Saldırının gerçekleşme mantığı şu üç adıma dayanır:

1. Eksik Salt Değerinin Ödünç Alınması: PAM desteği olmayan sshd, parola denetimini standart crypt() fonksiyonu üzerinden yürütür. /etc/shadow dosyasında parola alanı * olan (yani şifre belirlenmemiş, yalnızca SSH anahtarıyla girmesi planlanan) hesaplarda bir hash salt değeri bulunmaz. sshd, bu durumda sistemde geçerli bir parolası bulunan başka bir kullanıcının $5$ (SHA-256) veya $6$ (SHA-512) formatındaki salt değerini geçici olarak ödünç alır.
2. musl libc’nin Hata Kodu Üretmesi: Saldırgan, hedef hesaba oturum açarken 256 bayttan uzun (genellikle 257–1024 bayt arası) rastgele bir parola gönderir. musl libc kütüphanesindeki crypt() fonksiyonu, 256 bayt sınırını aşan girdilerde hata koruması olarak geriye doğrudan * karakterini döndürür.
3. Eşleşmenin Sağlanması ve Giriş: sshd, fonksiyondan dönen hata karakteri (*) ile /etc/shadow dosyasında parolasız hesabın karşısında duran değeri (*) karşılaştırır. İki değer birebir eşleştiği için sistem parolayı doğrulanmış kabul eder ve saldırgana anında kabuk (shell) erişimi verir.

İşlem için parola tahminine ya da brute-force denemesine gerek yoktur; doğru uzunluktaki bir dize ilk denemede girişi sağlar.

Hangi Sistemler Risk Altında, Hangileri Güvende?

Açığın ortaya çıkması için sistemin musl libc tabanlı olması ve sshd servisinin PAM olmadan çalışması gerekir.

Risk Altındaki Sistemler

• Alpine Linux: Standart openssh-server paketi PAM olmadan derlenir.
• Gömülü ve Hafif Linux Sistemleri: musl libc ile derlenmiş OpenWrt, Buildroot, Yocto kurulumları.
• Alpine Tabanlı Konteynerler: İçerisinde harici erişime açık sshd servisi barındıran Docker/Podman imajları.

Etkilenmeyen Sistemler

• AlmaLinux, CentOS, RHEL, Rocky Linux
• Ubuntu, Debian
• SUSE / openSUSE

Bu dağıtımlar varsayılan olarak glibc ve PAM (UsePAM yes) kullandığından bu açıktan etkilenmez.

Sunucunuzun Savunmasız Olduğunu Nasıl Anlarsınız?

Alpine veya musl tabanlı bir sistem yönetiyorsanız aşağıdaki komutlarla denetim yapabilirsiniz:

# 1. Parola ile giriş açık mı? (yes dönüyorsa risk)
sshd -T | grep -i passwordauthentication

# 2. Risk altındaki parolasız (*) hesapları listeleyin:
awk -F: '$2 == "*" {print $1}' /etc/shadow

# 3. Tuz ödünç verilebilecek hash'li ($5$ veya $6$) başka kullanıcı var mı?
grep -E ':\$(5|6)\$' /etc/shadow

Bu üç koşul aynı anda sağlanıyorsa sunucu doğrudan saldırıya açıktır.

Çözüm ve Alınması Gereken Önlemler

Paket Güncellemesi ve Servis Yeniden Başlatma

Kalıcı çözüm için sisteminizi güncelleyin. Paket güncellemesinden sonra çalışan sshd sürecini bellekte yenilemek için servisi yeniden başlatmak şarttır:

apk update
apk upgrade openssh
rc-service sshd restart

Güvenli Asgari Sürümler:

• Alpine v3.24: 10.3_p1-r2 veya üzeri
• Alpine v3.23: 10.2_p1-r1 veya üzeri
• Alpine v3.22: 10.0_p1-r11 veya üzeri
• Alpine v3.21: 9.9_p2-r1 veya üzeri
• Alpine Edge / Upstream: 10.6_p2-r0 (10.6p2) veya üzeri

Parola ile Girişi Kapatmak

Güncellemeyi hemen uygulayamıyorsanız geçici çözüm için SSH parola doğrulamasını tamamen kapatıp yalnızca SSH anahtarı kullanımını zorunlu kılmak zafiyeti anında bertaraf eder:

# Drop-in yapılandırma dosyası ekleyin
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf

# Ana yapılandırma dosyasını güncelleyin
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config

# Yapılandırmayı test edip servisi yeniden başlatın
sshd -t && rc-service sshd restart

Uygulamanın aktifleştiğini sshd -T | grep -i passwordauthentication komutuyla (passwordauthentication no çıktısını görerek) teyit edebilirsiniz.

Saldırı İhlal Tespiti

Sisteminizin bu açıktan yararlanılarak hedef alınıp alınmadığını anlamak için /var/log/messages dosyasındaki başarılı parola girişlerini inceleyin:

grep "Accepted password" /var/log/messages

Parolası olmaması gereken (root, alpine veya sadece anahtarla giriş yapan özel servis hesapları) bir kullanıcı adına verilmiş Accepted password for ... log kaydı görüyorsanız, sunucuya yetkisiz erişim sağlanmış demektir. Bu durumda yetki yükseltme geçmişi ve /home/*/.ssh/authorized_keys dosyaları incelenmelidir.