OpenSSH Güvenlik Açığı: Alpine Linux Sunucularında Risk
Yayın tarihi:

5 Kasım 2026'da OpenSSH, bazı Linux sunucularında parola kontrolünün aşılmasına yol açan ciddi bir güvenlik açığı için acil düzeltme yayımladı. CVE-2026-123158 numarasıyla kaydedilen OpenSSH güvenlik açığı, CVSS 3.1 değerlendirmesinde 8,1 puan aldı. Sorun, özellikle Alpine Linux gibi musl kütüphanesini kullanan ve SSH parolalarını PAM olmadan kontrol eden sistemleri ilgilendiriyor.
Bu koşullar oluştuğunda saldırgan, parolayla giriş yapamaması gereken bir hesaba uzaktan erişebiliyor. OpenSSH ekibi sorunu gidermek için 10.6p2 sürümünü yayımladı. Alpine Linux da etkilenen sürümleri için düzeltme paketleri hazırladı. Açık, bütün Linux dağıtımlarında veya SSH kullanan her sunucuda bulunmuyor.
OpenSSH açığı hangi sunucuları etkiliyor?
Alpine Linux'un 5 Kasım tarihli güvenlik duyurusu, riskin oluşması için dört koşulun birlikte bulunması gerektiğini açıklıyor:
- OpenSSH sunucusu PAM kullanmadan parola kontrolü yapıyor. Alpine'ın standart
openssh-serverpaketi bu şekilde hazırlanıyor;openssh-server-pampaketindeUsePAM noayarı da aynı riski oluşturabiliyor. - SSH üzerinde
PasswordAuthentication yesetkin. - Sunucuda parola alanı
*olan, normalde parolayla giriş yapamayan bir kullanıcı hesabı var. - Başka bir yerel hesabın parola kaydı
$5$veya$6$ile başlayan bir özet değer içeriyor.
Bu koşullar altında, kullanıcı adını bilen ve SSH bağlantısı kurabilen bir kişi parolayı bilmeden giriş yapabiliyor. Sorun özellikle yalnızca SSH anahtarıyla erişim verilmiş kullanıcılar açısından dikkat çekici. Hesap için parola belirlenmemiş olması, sunucunun parola ile giriş yöntemini kapattığı anlamına gelmiyor.
Alpine'ın bazı bulut imajlarında bulunan alpine kullanıcısı da etkilenebiliyor. Bu kullanıcıya parolasız doas yetkisi verilmişse saldırganın sunucuda yönetici yetkisine ulaşması mümkün. Buna karşılık root hesabına doğrudan parola ile giriş, OpenSSH'nin varsayılan PermitRootLogin prohibit-password ayarıyla engelleniyor. Her kurulumun doğrudan root erişimine açık olduğu söylenemez.
Parolası olmayan bir hesaba nasıl giriş yapılabiliyor?
Hatanın kaynağı, OpenSSH'nin kullandığı parola kontrolü ile musl kütüphanesinin hata yanıtının aynı değeri kullanması. Linux'ta bazı hesapların parola alanında * bulunuyor. Bu işaret, hesabın geçerli bir parolası olmadığını gösteriyor.
PAM kullanılmadığında OpenSSH, parola denemesini crypt() işlevi üzerinden kontrol edebiliyor. musl ise 256 bayttan uzun belirli parola girişlerini işleyemediğinde hata sonucu olarak yine * döndürüyor. OpenSSH'nin bazı hesapları kontrol ederken başka bir hesaptan aldığı parola ayarlarını kullanması da bu duruma eklenince hatalı sonuç, kayıtlı değerle eşleşmiş sayılabiliyor.
Sonuç olarak 257 ile 1.024 bayt arasındaki parola denemeleri, etkilenen yapılandırmalarda başarılı bir girişe dönüşebiliyor. Sorunu bildiren araştırmacı Özgün Kültekin, bu davranışın geçmişini teknik incelemesinde ayrıntılı biçimde anlatıyor. Açığın kaynağı şifreleme yönteminin kırılması değil, farklı yazılım bileşenlerinin aynı hata işaretini farklı anlamlarda kullanması.
Güvenlik açığı nasıl kapatılır?
OpenSSH'nin 10.6p2 sürüm notlarında düzeltme yer alıyor. Ancak Linux dağıtımlarının kendi paketlerine bu düzeltmeyi daha eski OpenSSH sürüm numaralarıyla ekleyebildiğini unutmamak gerekiyor. Alpine 3.24 için 10.3_p1-r2, 3.23 için 10.2_p1-r1, 3.22 için 10.0_p1-r11 ve 3.21 için 9.9_p2-r1 düzeltilmiş paketlerden bazıları. Alpine, artık düzenli destek almayan 3.16 ve sonraki eski dallara da özel paketler yayımladı.
Alpine sunucularında paket güncellemesi için dağıtımın önerdiği komut kullanılabiliyor:
apk upgrade -U -a
Güncelleme sonrasında çalışan SSH hizmetinin de yeniden başlatılması gerekiyor:
rc-service sshd restart
Paketin güncellenmesi, bellekte çalışan eski sshd sürecini kendiliğinden değiştirmiyor. Özellikle uzaktan yönetilen sunucularda işlem öncesinde erişimin sürdürülebileceğinden emin olmak, mümkünse konsol erişimini hazır tutmak ve yeni oturumla bağlantıyı doğrulamak gerekiyor.
Güncelleme hemen yapılamıyorsa Alpine, geçici önlem olarak SSH'de PasswordAuthentication no kullanılmasını öneriyor. Bu ayar değiştirilmeden önce SSH anahtarıyla girişin çalıştığı doğrulanmalı. Yapılandırma sshd -t ile kontrol edilebilir. Ayrıca Match kuralları ve farklı yapılandırma dosyaları, belirli kullanıcılar için etkin ayarı değiştirebildiğinden yalnızca ana dosyaya bakmak yeterli olmayabilir.
Şirketler sunucularında neyi kontrol etmeli?
Bu olay, bir sunucuda SSH anahtarı kullanılmasının tek başına parola girişini kapatmadığını gösteriyor. Özellikle otomatik dağıtımlar için açılmış hesaplar, bulut imajlarının varsayılan kullanıcıları ve uzun süredir değişmeyen SSH ayarları gözden geçirilmeli.
Envanterde hangi sunucuların Alpine veya başka bir musl tabanlı sistem kullandığı belirlenmeli. Ardından SSH'nin gerçekten çalışıp çalışmadığı, PAM üzerinden mi doğrulama yaptığı ve parolayla girişin etkin olup olmadığı kontrol edilmeli. SSH hizmeti çalışmayan sıradan bir Alpine uygulama konteyneri, yalnızca Alpine kullanıldığı için bu açıktan etkilenmiyor.
Daha önce etkilenen bir yapılandırma çalıştırılmışsa günlük kayıtları da incelenmeli. Alpine, /var/log/messages içinde normalde parola kabul etmemesi gereken hesaplar için Accepted password for kayıtlarının aranmasını öneriyor. Böyle bir kaydın varlığı araştırma gerektirir. Yetkisiz giriş ihtimali dışlanamıyorsa yalnızca güncelleme yapmakla yetinilmemeli; erişim anahtarları, kullanıcı hesapları ve yönetici yetkileri de incelenmeli.
Intellego sunucu güvenliğinde nasıl yardımcı olabilir?
Intellego Softworks olarak DevOps hizmetlerimiz kapsamında sunucu yapılandırmalarını, güncelleme süreçlerini ve sistem günlüklerini izlemeye yönelik altyapılar hazırlıyoruz. Mevcut sistemlerde güvenlik güncellemelerinin uygulanmasını planlayabiliyor, değişiklikleri test ortamında doğrulayabiliyor ve erişimi kesintiye uğratmadan devreye almak için geçiş adımlarını hazırlayabiliyoruz.
Bu tür açıklar yalnızca tek bir paketin sürümünü kontrol ederek yönetilemiyor. Çalışan hizmetin ayarlarını, kullanıcı yetkilerini ve kullanılan işletim sistemi imajlarını da bilmek gerekiyor. Şirketinizin sunucu yapısını değerlendirmek veya güncelleme süreçlerini düzenlemek isterseniz danışmanlık hizmetlerimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz.
Sorular ve cevaplar
- Ubuntu ve Debian sunucuları bu açıktan etkileniyor mu?
- Standart glibc ve PAM tabanlı SSH doğrulamasını kullanan kurulumlar, bu olayda açıklanan musl ve PAM'siz parola kontrolü birleşiminden etkilenmiyor. Farklı kütüphanelerle derlenmiş veya özel olarak yapılandırılmış sistemler için kullanılan paketler ayrıca incelenmeli.
- Yalnızca SSH anahtarı kullanmak yeterli mi?
- Hayır. Bir kullanıcıya parola vermemek ile SSH sunucusunda parola ile giriş yöntemini kapatmak farklı işlemler. Etkilenen sunucularda `PasswordAuthentication no` ayarı veya gerekli güvenlik düzeltmesi bulunmalı.
Kaynaklar
- OpenSSH - Portable OpenSSH 10.6p2 Release Notes (November 5, 2026)
- Alpine Linux - openssh-server Password Authentication Bypass Security Advisory
- Özgün Kültekin - *sshole: Original Technical Investigation
- OpenSSH Portable - Authentication Bypass Fix Commit
- Tenable - CVE-2026-123158 Vulnerability Record and CVSS Score
- The Hacker News - OpenSSH Emergency Fix on Alpine Linux