OpenSSH 2026 açıkları: Ubuntu ve RHEL sunucuda yamalı sürümü doğrulama ve sshd_config sertleştirme

2026'da OpenSSH için 10.3 ve 10.4 sürümleriyle birlikte birkaç güvenlik düzeltmesi yayımlandı ve dağıtımlar bu yamaları kendi paketlerine taşıdı. Sunucuda ssh -V komutu hâlâ eski bir sürüm gösterdiğinde akla gelen ilk soru şu: "Savunmasız mıyım?" Bu yazı Ubuntu ve RHEL tabanlı sunucu yöneten sistem yöneticileri ve KOBİ teknik sorumluları için hazırlandı. Paketin yamalı olup olmadığını nasıl doğrulayacağınızı, oturumu kaybetmeden nasıl güncelleyeceğinizi ve yama gelene kadar sshd_config ile riski nasıl azaltacağınızı adım adım anlatıyoruz.

2026'da OpenSSH tarafında ne oldu?

OpenSSH projesi 2026'da 10.3 ve 10.4 sürümlerini yayımladı. Bu sürümler yeni özelliklerin yanında birden fazla güvenlik düzeltmesi içeriyor. Ubuntu bu düzeltmeleri USN-8222-1, USN-8533-1 ve USN-8721-1 gibi güvenlik bildirimleriyle, Red Hat ise RHSA-2026:69266 gibi errata kayıtlarıyla kendi paketlerine taşıdı.

Kayıtlarda geçen açıklar (CVE-2026-35414, CVE-2026-60000, CVE-2026-60002, CVE-2026-73281 ve diğerleri) kabaca dört başlıkta toplanıyor:

• Sertifika tabanlı kimlik doğrulama: SSH sertifikalarındaki principals alanının yanlış değerlendirilmesiyle ilgili hatalar. Yalnız SSH CA ve kullanıcı sertifikası kullanan ortamları ilgilendirir.
• GSSAPI ve Kerberos: GSSAPI kimlik doğrulama yolundaki hatalar. Bu özellik çoğu bulut sunucuda kullanılmaz ama bazı dağıtımlarda varsayılan olarak açık gelebilir.
• Ajan yönlendirme (agent forwarding): Ajan yönlendirmesi açık bir bağlantıda, uzak taraftaki bir saldırganın yerel anahtarlarınızı kötüye kullanabilmesine yol açan durumlar.
• scp ve sftp yol işleme hataları: Dosya aktarımında yol adlarının hatalı işlenmesi. Bunların bir kısmı istemci tarafını etkiler.

Her CVE'nin ayrıntısı, etkilenen yapılandırma ve önem derecesi resmi bildirimlerde yazar. Bir CVE'nin sizi gerçekten etkileyip etkilemediğini anlamanın doğru yolu, kendi dağıtımınızın bildirimini okumaktır. Haber sitesindeki özete güvenmeyin.

Sürüm numarası neden yanıltır?

Ubuntu 24.04'te ssh -V çıktısı OpenSSH_9.6p1 Ubuntu-... biçimindedir. Bunu görüp "ben 10.4'te değilim, demek ki açığım" sonucuna varmak yanlıştır. Kararlı dağıtımlar bir LTS sürümü boyunca ana sürümü değiştirmez. Güvenlik düzeltmelerini eski sürümün üstüne yama olarak ekler. Buna geri taşıma (backport) denir.

Yani 9.6p1 yazan bir sunucu, ilgili 2026 düzeltmelerini almış olabilir. Belirleyici olan üst sürüm numarası değildir, paketin dağıtım revizyonudur. Ubuntu'da bu 1:9.6p1-3ubuntu13.x gibi bir dizgenin son kısmıdır. RHEL'de ise openssh-server-8.7p1-...el9_x gibi bir paket adının release bölümüdür.

İki ayrıntı daha önemli:

1. ssh -V istemcinin sürümünü gösterir. Sunucu tarafını openssh-server paketi belirler. Çoğu zaman ikisi birlikte güncellenir ama ayrı paketlerdir.
2. Paket güncellense bile çalışan sshd süreci yeniden başlatılmadıysa bellekte eski kod çalışmaya devam eder.

Adım 1: Yamalı sürümü doğrulama

Önce dağıtımınızın bildirimini açın ve sürümünüze karşılık gelen düzeltilmiş paket sürümünü not edin:

• Ubuntu: USN-8721-1 sayfasında her Ubuntu sürümü için "openssh-server" satırında düzeltilmiş sürüm yazar. Daha eski bildirimler için USN-8533-1 sayfasına da bakın.
• RHEL: RHSA-2026:69266 sayfasında RHEL sürümünüze göre güncellenmiş paket adları listelenir.

Aşağıdaki betik kurulu paket sürümünü okur, verdiğiniz düzeltilmiş sürümle karşılaştırır, paket değişiklik günlüğünde CVE numarasını arar ve çalışan sshd sürecinin eski ikili dosyayı kullanıp kullanmadığını kontrol eder. Ubuntu 22.04, Ubuntu 24.04, Debian 12, RHEL 9 ve uyumlu dağıtımlar (AlmaLinux, Rocky Linux) için hazırlandı. Yalnız okuma yapar, sistemde değişiklik yapmaz. Bu yüzden geri alınacak bir şey yoktur.

#!/usr/bin/env bash
# openssh-kontrol.sh
# Kullanım: sudo ./openssh-kontrol.sh "DUZELTILMIS_SURUM" "CVE-2026-35414"
# DUZELTILMIS_SURUM: USN ya da RHSA sayfasındaki paket sürümü
#   Ubuntu örneği: 1:9.6p1-3ubuntu13.ORNEK   RHEL örneği: 8.7p1-ORNEK.el9
# Yalnız okuma yapar; sistemde değişiklik yapmaz.
set -u

DUZELTILMIS="${1:-}"
CVE="${2:-}"

. /etc/os-release
echo "Dağıtım      : ${PRETTY_NAME}"
echo "İstemci      : $(ssh -V 2>&1)"

if command -v dpkg-query >/dev/null 2>&1; then
    # Debian/Ubuntu ailesi
    KURULU=$(dpkg-query -W -f='${Version}' openssh-server 2>/dev/null || true)
    echo "openssh-server: ${KURULU:-kurulu değil}"
    apt-cache policy openssh-server | sed -n '2,3p'
    if [ -n "$DUZELTILMIS" ] && [ -n "$KURULU" ]; then
        if dpkg --compare-versions "$KURULU" ge "$DUZELTILMIS"; then
            echo "SONUÇ        : paket düzeltilmiş sürümde ya da daha yeni"
        else
            echo "SONUÇ        : GÜNCELLEME GEREKLİ"
        fi
    fi
    GUNLUK="/usr/share/doc/openssh-server/changelog.Debian.gz"
    if [ -n "$CVE" ] && [ -f "$GUNLUK" ]; then
        zgrep -q "$CVE" "$GUNLUK" && echo "Değişiklik günlüğü: $CVE geçiyor" \
                                   || echo "Değişiklik günlüğü: $CVE bulunamadı"
    fi
elif command -v rpm >/dev/null 2>&1; then
    # RHEL ailesi
    KURULU=$(rpm -q --qf '%{VERSION}-%{RELEASE}' openssh-server 2>/dev/null || true)
    echo "openssh-server: ${KURULU:-kurulu değil}"
    if [ -n "$DUZELTILMIS" ] && [ -n "$KURULU" ]; then
        # sort -V yaklaşık karşılaştırma yapar; kesin sonuç için RHSA sayfasına bakın
        ENKUCUK=$(printf '%s\n%s\n' "$KURULU" "$DUZELTILMIS" | sort -V | head -n1)
        if [ "$ENKUCUK" = "$DUZELTILMIS" ]; then
            echo "SONUÇ        : paket düzeltilmiş sürümde ya da daha yeni"
        else
            echo "SONUÇ        : GÜNCELLEME GEREKLİ"
        fi
    fi
    if [ -n "$CVE" ]; then
        rpm -q --changelog openssh-server | grep -q "$CVE" \
            && echo "Değişiklik günlüğü: $CVE geçiyor" \
            || echo "Değişiklik günlüğü: $CVE bulunamadı"
    fi
fi

# Çalışan sshd eski ikiliyi mi kullanıyor?
PID=$(pgrep -o -x sshd || true)
if [ -n "$PID" ]; then
    if ls -l "/proc/${PID}/exe" 2>/dev/null | grep -q '(deleted)'; then
        echo "sshd (PID $PID): ESKİ ikili bellekte, yeniden başlatma gerekli"
    else
        echo "sshd (PID $PID): güncel ikili çalışıyor"
    fi
else
    echo "sshd süreci bulunamadı (socket etkinleştirme kullanılıyor olabilir)"
fi

Değişiklik günlüğünde CVE numarasının geçmesi, dağıtımın o açığı paketine taşıdığının en somut kanıtıdır. RHEL'de buna ek olarak dnf updateinfo list --security 'openssh*' komutu bekleyen güvenlik güncellemelerini listeler. Ubuntu'da Ubuntu Pro etkinse pro fix CVE-2026-35414 komutu da aynı soruyu yanıtlar.

Adım 2: Oturumu kaybetmeden güncelleme

sshd yeniden başlatıldığında mevcut SSH oturumları genellikle kopmaz, çünkü her oturum ayrı bir alt süreçte çalışır. Yine de güvenli yol şudur: mevcut oturumu açık tutun, güncellemeyi yapın, ikinci bir terminalden yeni bağlantıyı deneyin, başarılı olursa ilk oturumu kapatın.

Güncellemeden önce sunucunun bir snapshot'ını ya da yedeğini almak iyi bir alışkanlıktır. Düzenli bir planlı yedekleme kurgunuz varsa son yedeğin tarihini kontrol etmeniz yeterli olur.

Aşağıdaki betik yalnız OpenSSH paketlerini günceller, yapılandırmayı sshd -t ile sınar ve ancak sınama geçerse servisi yeniden başlatır. Ubuntu 22.04, Ubuntu 24.04, Debian 12 ve RHEL 9 ile uyumlu dağıtımlar için hazırlandı. Paket güncellemesini geri almak genellikle önerilmez. Gerekirse Ubuntu'da apt-get install openssh-server=ESKI_SURUM, RHEL'de dnf downgrade openssh-server ile önceki sürüme dönülebilir, ama bu açığı yeniden açar.

#!/usr/bin/env bash
# openssh-guncelle.sh  (root ya da sudo ile çalıştırın)
set -euo pipefail

YEDEK_DIZIN="/root/ssh-yedek-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$YEDEK_DIZIN"
# Yapılandırmanın yedeği; aynı gün tekrar çalıştırmak zararsızdır
cp -a /etc/ssh "$YEDEK_DIZIN/"
echo "Yedek: $YEDEK_DIZIN"

if command -v apt-get >/dev/null 2>&1; then
    apt-get update
    # Yalnız OpenSSH paketleri; mevcut sshd_config korunur
    DEBIAN_FRONTEND=noninteractive apt-get install -y --only-upgrade \
        -o Dpkg::Options::="--force-confold" \
        openssh-server openssh-client openssh-sftp-server
    SERVIS="ssh"
else
    dnf -y upgrade --security 'openssh*' || dnf -y upgrade 'openssh*'
    SERVIS="sshd"
fi

# Yapılandırmayı sına; hata varsa yeniden başlatma yapılmaz
if sshd -t; then
    systemctl restart "$SERVIS"
    systemctl --no-pager --lines=5 status "$SERVIS"
else
    echo "sshd -t hata verdi; servis yeniden başlatılmadı. Yedek: $YEDEK_DIZIN" >&2
    exit 1
fi

Ubuntu 24.04'te SSH varsayılan olarak ssh.socket ile etkinleştirilir. Bu durumda systemctl restart ssh yine doğru komuttur. Yalnız ssh.socket ve ssh.service birimlerinin ikisinin de etkin olduğunu systemctl status ssh.socket ssh.service ile görebilirsiniz.

Güncellemeden sonra kontrol betiğini yeniden çalıştırın. "SONUÇ" satırı düzeltilmiş sürümü göstermeli ve sshd için "güncel ikili çalışıyor" yazmalı.

Adım 3: Yama gelene kadar sshd_config sertleştirme

Bazen yama hemen gelmez ya da bakım penceresini beklemeniz gerekir. Bu sürede kullanmadığınız özellikleri kapatmak saldırı yüzeyini daraltır. 2026 açıklarının çoğu GSSAPI, ajan yönlendirme ve sertifika gibi her sunucuda gerekmeyen özelliklerle ilgili. Bu yüzden sertleştirme gerçekten işe yarar.

Ayarları ayrı dosyaya yazın

Ana sshd_config dosyasını düzenlemek yerine /etc/ssh/sshd_config.d/ altına ayrı bir dosya koyun. Ubuntu ve RHEL 9 bu dizini ana dosyanın başında içe aktarır. sshd, bir ayar için ilk okuduğu değeri kullanır ve dosyalar alfabetik sırayla okunur. Ubuntu'daki 50-cloud-init.conf ya da RHEL'deki 50-redhat.conf aynı ayarı farklı yapıyorsa ve sizin dosyanız sonra okunuyorsa ayarınız etkisiz kalır. Bu yüzden dosya adını 01- ile başlatın.

Aşağıdaki betik Ubuntu 22.04, Ubuntu 24.04, Debian 12 ve RHEL 9 için hazırlandı. Her çalıştırmada aynı içeriği yazar, yani idempotenttir. Sınama başarısız olursa dosyayı otomatik olarak geri alır. Elle geri almak için /etc/ssh/sshd_config.d/01-sertlestirme.conf dosyasını .bak uzantısıyla yeniden adlandırıp servisi yeniden başlatmanız yeterlidir.

#!/usr/bin/env bash
# ssh-sertlestir.sh  (root ya da sudo ile çalıştırın)
set -euo pipefail

DOSYA="/etc/ssh/sshd_config.d/01-sertlestirme.conf"
SERVIS=$(systemctl list-unit-files ssh.service >/dev/null 2>&1 && echo ssh || echo sshd)

# Varsa önceki dosyanın yedeği
[ -f "$DOSYA" ] && cp -a "$DOSYA" "${DOSYA}.onceki"

cat > "$DOSYA" <<'EOF'
# GSSAPI/Kerberos kullanılmıyorsa kapatın
GSSAPIAuthentication no
KerberosAuthentication no

# Ajan, TCP, X11 ve akış yönlendirmesini tek seferde kapatır
# (sunucuda tünel ya da port yönlendirme kullanıyorsanız bu satırı kaldırın)
DisableForwarding yes
AllowAgentForwarding no
X11Forwarding no

# Kaba kuvvet ve bağlantı sel saldırılarını yavaşlatma
MaxAuthTries 3
LoginGraceTime 30
MaxStartups 10:30:60

# root yalnız anahtarla girebilir
PermitRootLogin prohibit-password
EOF
chmod 644 "$DOSYA"

if sshd -t; then
    systemctl restart "$SERVIS"
    echo "Sertleştirme uygulandı: $DOSYA"
else
    echo "sshd -t hata verdi, değişiklik geri alınıyor" >&2
    if [ -f "${DOSYA}.onceki" ]; then mv "${DOSYA}.onceki" "$DOSYA"; else mv "$DOSYA" "${DOSYA}.hatali"; fi
    exit 1
fi

Hangi ayar neyi kapatır?

• GSSAPIAuthentication no: Kerberos ile oturum açmıyorsanız bu yolu tamamen kapatır. Active Directory ile SSH girişi yapan ortamlarda bu ayarı değiştirmeyin.
• DisableForwarding yes: Ajan, TCP, X11 ve Unix soket yönlendirmesinin hepsini kapatır. Sunucuyu sıçrama noktası (jump host) olarak kullanıyorsanız bu ayarı kaldırın ve yalnız AllowAgentForwarding no bırakın.
• MaxAuthTries 3 ve LoginGraceTime 30: Bir bağlantının deneme sayısını ve kimlik doğrulama süresini kısaltır.
• MaxStartups 10:30:60: Kimliği doğrulanmamış eşzamanlı bağlantıları sınırlar. Bağlantı selinde sunucunun kaynak tüketmesini azaltır.

Parola ile girişi kapatmak (PasswordAuthentication no) en etkili adımlardan biridir. Ancak bunu yalnız anahtarla girişin çalıştığını ikinci bir oturumda doğruladıktan sonra yapın.

İstemci tarafı: ajan yönlendirmesi

Ajan yönlendirme riski asıl olarak sizin bilgisayarınızı ilgilendirir. ssh -A ile bağlandığınız sunucu ele geçirilmişse, orada yetkili biri yerel ajanınızdaki anahtarları siz bağlıyken kullanabilir. Yerel ~/.ssh/config dosyanızda varsayılanı ForwardAgent no yapın. Başka sunucuya geçmeniz gerekiyorsa ajan yönlendirmesi yerine ProxyJump kullanın. Yöneticilerin dizüstü bilgisayarlarındaki OpenSSH istemcisini de güncellemeyi unutmayın, çünkü scp ve sftp yol hatalarının bir kısmı istemcide düzeltilir.

Adım 4: Erişimi daraltma, fail2ban ve güvenlik duvarı

En iyi koruma, SSH portunun herkese açık olmamasıdır. Ofisinizin sabit IP'si ya da bir VPN varsa SSH'ı yalnız oradan kabul edin.

Kendini kilitleme uyarısı: Güvenlik duvarını etkinleştirmeden önce SSH'a izin veren kuralı eklemezseniz ya da yanlış IP aralığı yazarsanız sunucuya erişiminizi kaybedersiniz. Başlamadan önce sağlayıcınızın web konsoluna (VNC, IPMI ya da seri konsol) erişebildiğinizi doğrulayın. Kural hatasını yalnız oradan düzeltebilirsiniz.

Aşağıdaki betik Ubuntu 22.04 ve 24.04 üzerinde UFW için hazırlandı. 198.51.100.0/24 yerine kendi yönetim ağınızı yazın. Geri almak için ufw delete allow from 198.51.100.0/24 to any port 22 proto tcp kullanılır, gerekirse konsoldan ufw disable ile güvenlik duvarı tamamen kapatılır.

#!/usr/bin/env bash
# ssh-erisim-daralt.sh  (Ubuntu, root ya da sudo ile)
set -euo pipefail

YONETIM_AGI="198.51.100.0/24"   # ORNEK: kendi ofis ya da VPN aralığınız

apt-get install -y ufw fail2ban

# 1) ÖNCE SSH izni: aynı kural tekrar eklenmez, ufw bunu atlar
ufw allow from "$YONETIM_AGI" to any port 22 proto tcp

# 2) Sonra varsayılan politika ve etkinleştirme
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status numbered

# 3) fail2ban: sshd hapsini yerel dosyayla etkinleştir
cat > /etc/fail2ban/jail.d/sshd-yerel.conf <<'EOF'
[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h
EOF
systemctl enable --now fail2ban
systemctl restart fail2ban
fail2ban-client status sshd

RHEL tarafında aynı mantık firewalld ile uygulanır. Önce izin kuralını ekleyin, sonra genel ssh servisini kaldırın:

# RHEL 9 için; önce izin, sonra genel kuralı kaldırma
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" service name="ssh" accept'
firewall-cmd --reload
# Yeni terminalden bağlantıyı doğruladıktan SONRA:
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

Erişim sağlayıcı seviyesinde de kısıtlanabiliyorsa (ör. panelden ağ güvenlik kuralı) bunu tercih edin. Bulut sunucu ya da fiziksel sunucu kullanıyor olun, konsol erişiminin nasıl açıldığını önceden öğrenmek kilitlenme anında zaman kazandırır.

Doğrulama

Tüm adımlardan sonra şunları kontrol edin:

# Etkin sshd ayarları (dosyalar değil, sshd'nin gerçekte kullandığı değerler)
sudo sshd -T | grep -Ei 'gssapiauthentication|allowagentforwarding|disableforwarding|maxauthtries|permitrootlogin|passwordauthentication'

# Paket ve çalışan süreç
sudo ./openssh-kontrol.sh "DUZELTILMIS_SURUM" "CVE-2026-35414"

# Son SSH girişleri ve hatalar
sudo journalctl -u ssh -u sshd --since "1 hour ago" --no-pager | tail -n 30

sshd -T çıktısında beklediğiniz değerler yoksa başka bir drop-in dosyası ayarınızı geçersiz kılıyordur. grep -r <AyarAdi> /etc/ssh/ ile bulun.

Sık yapılan hatalar

• Kendini kilitlemek: Güvenlik duvarını SSH izni olmadan açmak ya da parola girişini anahtar test edilmeden kapatmak. Her değişiklikten sonra mevcut oturumu kapatmadan yeni bir terminalden giriş deneyin.
• Yalnız istemciyi güncellemek: openssh-client güncel ama openssh-server eski kalabilir. Her iki paketi de kontrol edin.
• sshd'yi yeniden başlatmamak: Paket güncellense bile eski süreç çalışmaya devam eder. Kontrol betiğindeki "ESKİ ikili" uyarısı bu durumu yakalar. Ubuntu'da needrestart, RHEL'de needs-restarting -s de yardımcı olur.
• Ana sürüme bakarak karar vermek: 9.6p1 ya da 8.7p1 görmek tek başına açık olduğunuz anlamına gelmez. Dağıtım revizyonuna ve değişiklik günlüğüne bakın.
• Drop-in sırasını gözden kaçırmak: 99- ile başlayan bir dosya, 50-cloud-init.conf içindeki ayarı geçersiz kılamaz.

Sık sorulan sorular

ssh -V 9.6p1 gösteriyor, savunmasız mıyım?

Tek başına bu bilgi yeterli değil. Ubuntu 24.04 tüm destek süresi boyunca 9.6p1 tabanında kalır ve düzeltmeleri geri taşır. dpkg-query -W openssh-server çıktısını USN sayfasındaki düzeltilmiş sürümle karşılaştırın ve değişiklik günlüğünde ilgili CVE numarasını arayın.

OpenSSH 10.4'ü kaynak koddan derlemeli miyim?

Dağıtım paketi destekleniyorsa hayır. Kaynaktan derlenmiş OpenSSH, dağıtımın güvenlik güncellemelerinin dışında kalır ve her yeni açıkta elle bakım ister. Dağıtım paketini güncel tutmak çoğu sunucu için daha güvenli bir yoldur.

Güncelleme sırasında açık SSH oturumum kopar mı?

Genellikle kopmaz. sshd yeniden başlatıldığında mevcut oturumlar kendi alt süreçlerinde devam eder. Yine de yeni bağlantıyı ikinci bir terminalden test etmeden ilk oturumu kapatmayın.

SSH portunu değiştirmek bu açıklardan korur mu?

Hayır. Port değiştirmek otomatik tarayıcılardan gelen gürültüyü azaltır ama açığı kapatmaz. Asıl koruma paketi güncellemek, kullanmadığınız özellikleri kapatmak ve erişimi belirli IP aralıklarıyla sınırlamaktır.

SSH sertifikası kullanmıyorum, sertifika açığı beni ilgilendirir mi?

Sunucuda TrustedUserCAKeys ya da HostCertificate ayarı yoksa sertifika tabanlı kimlik doğrulamayı kullanmıyorsunuz demektir ve bu sınıftaki açıklardan doğrudan etkilenme olasılığınız düşüktür. Yine de paketi güncellemek gerekir, çünkü aynı güncelleme başka düzeltmeler de içerir.

Sonuç

OpenSSH açıklarında doğru soru "hangi sürümdeyim?" değil, "dağıtımımın düzeltilmiş paketi kurulu mu ve sshd onu mu çalıştırıyor?" sorusudur. Bildirimdeki düzeltilmiş sürümü not edin, kontrol betiğiyle karşılaştırın, güncelleyip sshd'yi yeniden başlatın. Yama gecikirse GSSAPI ve yönlendirme gibi kullanmadığınız özellikleri kapatın, SSH'ı da yalnız güvendiğiniz ağlara açın. Ayrıntılı değişiklik listesi için OpenSSH sürüm notlarına bakabilirsiniz.