Ubuntu uzerinde Post-Quantum SSH kullanimi ve detaylari

Post-quantum SSH'de neler değişti

Post-quantum SSH çoğu kullanıcı için halihazırda etkin durumdadır ve herhangi bir yapılandırma yapılması gerekmemiştir. Güncel bir OpenSSH istemcisi, güncel bir OpenSSH sunucusu ile iletişim kurarken varsayılan olarak hibrit bir post-quantum anahtar değişimi seçer. Bu sayede oturum anahtarı, trafiğinizi bugün kaydedip yıllar sonra şifresini çözmeye çalışacak bir saldırgana karşı dirençli hale gelir. Sağlanan koruma gerçektir, ancak "kuantum güvenli SSH" ifadesinin çağrıştırdığından daha sınırlı bir kapsamı vardır.

Öncelikle iki terimi açıklayalım. SSH (secure shell), bir sunucuya giriş yapmak için kullanılan protokoldür. Genellikle "kex" olarak kısaltılan anahtar değişimi, her SSH bağlantısının ilk adımıdır: iki uç nokta ortak bir gizli anahtar üzerinde anlaşır ve bu anahtar, sonrasındaki tüm iletişimi şifreler. Değişen kısım yalnızca anahtar değişimi aşamasıdır. Bunun dışında hiçbir şey değişmemiştir.

Bu sayfaya güvenmeyin, komutları kendiniz çalıştırın

Aşağıdaki her algoritma ismi, bizzat çalıştırabileceğiniz bir komuttan gelmektedir. Bu durum kasıtlıdır. Varsayılan değerler her OpenSSH sürümüyle birlikte değişir; bu nedenle iki yıl önce yazılmış bir rehber, makinenizin artık tercih etmediği bir algoritmayı isimlendirebilir ve size bunu bildirecek bir mekanizması yoktur. Bu komutları öğrenin; böylece bu makale dahil olmak üzere bu tür yazılara ihtiyaç duymayı bırakırsınız.

Yapınızın neleri destekleyebileceğini öğrenerek başlayın.

ssh -V
ssh -Q kex

ssh -V, OpenSSH_ ile başlayan bir sürüm satırı, ardından Ubuntu paket soneki ve OpenSSL sürümünü yazdırır. ssh -Q kex, her satıra bir anahtar değişim algoritması gelecek şekilde çıktı verir. Kuantum sonrası destek içeren bir yapıda, bu listede mlkem768x25519-sha256 ve sntrup761x25519-sha512@openssh.com gibi isimleri, curve25519-sha256 gibi klasik isimlerin yanında bulursunuz.

Derlemenizin desteklediği özellikler ile sunduğu özellikler aynı değildir

Çoğu yazının atladığı ayrım budur. ssh -Q kex tek bir soruyu yanıtlar: bu ikili dosya ne yapabilir. Sizin asıl ilgilendiğiniz soruyu yanıtlamaz: bu bağlantı gerçekte ne önerecek. İki liste birbirinden farklıdır ve aralarındaki fark, eski tavsiyelerin asıl zararı verdiği noktadır.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host>, ~/.ssh/config ve /etc/ssh/ssh_config uygulandıktan sonra istemcinin o ana bilgisayar için geçerli yapılandırmasını yazdırır. sshd -T, sunucu için aynı işlemi yapar. Her biri tercih sırasına göre tek bir kexalgorithms satırı yazdırır ve bu satırdaki ilk isim, o tarafın ilk tercihidir. Ağ üzerinden gönderilen satır budur.

Bu fark teorik değildir. 2021-03-03 tarihinde yayınlanan OpenSSH 8.5, sntrup761x25519-sha512@openssh.com özelliğini eklemiş ancak bunu varsayılan listeye kasten dahil etmemiştir. Bu sürümde ssh -Q kex algoritmayı gösterirken ssh -G göstermez; bu da ikili dosyanın kuantum sonrası anahtar değişimi yapabileceği, ancak hiçbir bağlantının bunu talep etmediği anlamına gelir.

Bağlantınızın müzakere ettiği algoritmayı okuyun

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Mevcut bir istemci ile mevcut bir sunucu arasında bu komut şunu yazdırır:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 hibrit bir yapıdır. 768 parametre setinde ML-KEM (FIPS 203 olarak standartlaştırılmış modül tabanlı kafes anahtar kapsülleme mekanizması) ile X25519 eliptik eğri Diffie-Hellman'ı birlikte çalıştırır ve her iki çıktıyı oturum anahtarında birleştirir.

Daha eski bir sunucuya karşı bunun yerine şunu görebilirsiniz:

debug1: kex: algorithm: curve25519-sha256

Bu ismin kuantum sonrası bir parçası yoktur. curve25519-sha256 sadece eliptik eğri Diffie-Hellman'dır ve büyük bir kuantum bilgisayarı bunu kırabilir. Varsayılanın değiştirilmesinin tüm nedeni budur.

Tek bir eski makinenin oturumu nasıl geride tuttuğunu tek bir müzakere kuralı açıklar. İstemci kendi listesini tercih sırasına göre gönderir, sunucu da kendininkini gönderir ve seçilen algoritma, istemcinin listesinde yer alıp aynı zamanda sunucuda da bulunan ilk isimdir. İstemcinin tercihi baskın gelir, bu nedenle iki uçtan daha eski olanı listenin ne kadar yukarısına çıkabileceğinize karar verir. Dizüstü bilgisayarınızı yükseltmek, ML-KEM'i hiç duymamış bir sunucuyla yapılan oturumu yükseltmez.

ssh -v, sadece bu satırdan daha fazlası için bilinmeye değerdir; çünkü aynı çıktı, bir giriş reddedildiğinde Permission denied (publickey) hatasının izini sürebileceğiniz yerdir.

grep ve ssh -v bayraklarını kaldırırsanız, bir sonraki bölümün konusu olan satır da dahil olmak üzere müzakerenin geri kalanı görüntülenir:

debug1: kex: host key algorithm: ssh-ed25519

Hangi OpenSSH sürümü hibrit değişimi varsayılan hale getirdi

Upstream sürüm notları net bir sıra sunmaktadır. Tarihler sürüm numaralarından daha önemlidir, çünkü bu özelliğin ne kadar süredir sessizce çalıştığını gösterirler.

• 2021-03-03 tarihinde yayınlanan 8.5 sürümü, sntrup761x25519-sha512@openssh.com özelliğini ekledi ancak varsayılan olarak devre dışı bıraktı.
• 2022-04-08 tarihinde yayınlanan 9.0 sürümü, bu özelliği etkinleştirdi. Sürüm notlarında OpenSSH'in "varsayılan olarak hibrit Streamlined NTRU Prime + x25519 anahtar değişim yöntemini kullanacağı" belirtilmektedir. Bu, kuantum sonrası anahtar değişiminin standart hale geldiği sürümdür.
• 2024-09-19 tarihinde yayınlanan 9.9 sürümü, mlkem768x25519-sha256 özelliğini ikinci bir seçenek olarak ekledi. Aynı sürüm, eski yönteme IANA kayıtlı adı olan sntrup761x25519-sha512 ismini verdi; bu nedenle daha yeni derlemeler yöntemi her iki yazımla da listeler.
• 2025-04-09 tarihinde yayınlanan 10.0 sürümü, mlkem768x25519-sha256 yöntemini anahtar anlaşması için varsayılan hale getirdi.
• 2025-10-06 tarihinde yayınlanan 10.1 sürümü, bir bağlantı kuantum sonrası bileşen içermeyen bir anahtar değişimi gerçekleştirdiğinde istemci tarafında bir uyarı ekledi. Bu durum ssh_config içindeki WarnWeakCrypto seçeneği ile kontrol edilir ve varsayılan olarak etkindir.

Nisan 2022, hatırlanması gereken tarihtir. OpenSSH 9.0 veya daha yeni bir sürüm çalıştıran her makine çifti, o tarihten bu yana herhangi bir yapılandırma gerektirmeden ve ssh komutunu yazan kişiye bildirimde bulunmadan kuantum sonrası anahtar değişimi gerçekleştirmektedir.

Hangi Ubuntu sürümü ile geliyor

Ubuntu, bir OpenSSH sürümünü yayınlandığı anda dondurur ve sürüm numarasını değiştirmeden güvenlik yamalarını bu sürüme geri taşır (backport). Bu nedenle, varsayılan algoritmanızı kullandığınız Ubuntu sürümü belirler. Bir listeye güvenmek yerine, önünüzdeki makineyi ssh -V ile kontrol edin. Ağustos 2026 itibarıyla arşivdeki sürümler şunlardır:

• 22.04 LTS, 1:8.9p1 ile gelir; bu sürüm 9.0 varsayılanından eski olduğu için standart bir kurulum curve25519-sha256 üzerinden anlaşma sağlar.
• 24.04 LTS, 1:9.6p1 ile gelir; bu sürüm 9.0'dan sonra ve 9.9'dan önce olduğu için varsayılanı sntrup761x25519-sha512@openssh.com'dır ve ML-KEM içermez.
• 25.10, 1:10.0p1 ile gelir ve varsayılanı mlkem768x25519-sha256'dir.
• 26.04 LTS, 1:10.2p1 ile gelir; varsayılan olarak mlkem768x25519-sha256 kullanır ve post-quantum olmayan bağlantılar hakkında uyarı verir.

Gerçek bir makine çifti üzerinde çalışın. Bir 26.04 dizüstü bilgisayar, 24.04 bir sunucuya bağlanıyor olsun. İstemcinin ilk tercihi olan mlkem768x25519-sha256, 9.6 sunucusunun listesinde bulunmaz. İstemcinin sunucuda mevcut olan bir sonraki post-quantum tercihi sntrup761x25519-sha512@openssh.com'dır ve ssh -v'nin raporladığı isim budur. Oturum, 2024 yılında oluşturulmuş bir sunucuya karşı, kimse tarafından hiçbir yapılandırma yapılmadan, anahtar değişimi aşamasında post-quantum olarak gerçekleşir.

22.04 durumu ise tam tersi şekilde işler ve ssh -Q kex komutunun tek başına neden yanıltıcı olduğunu tam olarak gösterir. OpenSSH 8.9, sntrup761x25519-sha512@openssh.com ismini tanır, bu nedenle o makinedeki ssh -Q kex bunu listeler; ancak varsayılan teklif bunu dışarıda bırakır ve anlaşma curve25519-sha256 üzerinde sağlanır. OpenSSH 10.1 veya daha yeni bir istemciden bağlantı kurulduğunda şu uyarı alınır:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Bu uyarı, istemcinizle ilgili değil, eriştiğiniz sunucuyla ilgili bir gerçektir. Çözüm, sunucuyu yükseltmektir. WarnWeakCrypto no ayarını yapmak mesajı kaldırır ancak bağlantı üzerinde hiçbir şeyi değiştirmez.

Neden hibrit yapı ve "şimdi topla, sonra şifresini çöz" ne anlama gelir

Tehdit net bir yapıya sahiptir. Trafiğinizi görebilen bir saldırgan, şifrelenmiş baytları bugün kaydeder ve depolar. Bunları bugün okuyamaz. Verileri, X25519 algoritmasını kırabilecek kadar büyük bir kuantum bilgisayar var olana kadar saklar ve ardından okur. Buna "şimdi topla, sonra şifresini çöz" (harvest now, decrypt later) veya "şimdi depola, sonra şifresini çöz" denir. Bu yöntem, saldırgandan günümüzde zekice bir hamle beklemez. Sadece disk alanı ve sabır gerektirir.

Şifreleme bu soruna sahiptir ancak imzalar sahip değildir; bu asimetri diğer her şeyi belirler. Kaydedilmiş bir şifreli metin, içindeki veriler hassas kaldığı sürece değerini korur. Bir imza ise yalnızca kontrol edildiği anda sahteciliğe karşı dayanıklı olmalıdır. 2035 yılında bir imza algoritmasını kırmak, birinin 2035'te bir sunucunun kimliğine bürünmesine olanak tanır. Ancak bu, geçmişe dönüp 2026 yılından bir oturum açma işlemini sahtelemesine izin vermez. Bu nedenle anahtar değişimi öncelikle düzeltilmeliydi, imza tarafı ise bekleyebilir.

Hibrit yapı, her iki algoritmanın da çalışması ve her iki sonucun da oturum anahtarını beslemesi anlamına gelir. mlkem768x25519-sha256 arkasındaki gizli veriyi kurtarmak için bir saldırganın hem ML-KEM 768 hem de X25519 algoritmalarını kırması gerekir. Bu eşleştirme kasıtlıdır: ML-KEM, X25519'dan çok daha yenidir ve kriptanalistler tarafından saldırıya uğraması için çok daha az zamanı olmuştur; bu nedenle yeni algoritmada bulunabilecek bir açık, halihazırda sahip olduğunuz korumayı riske atmaz.

Nelerin korunup nelerin korunmadığı

Anahtar değişimi korunmaktadır. Oturumunuzu şifreleyen paylaşımlı gizli anahtar, hibrit bir değişimden elde edilmiştir; bu nedenle bugün kaydedilen bir oturum, kuantum bilgisayarların gelecekte kullanıma girmesiyle okunabilir hale gelmez.

Sunucu anahtarı korunmamaktadır. debug1: kex: host key algorithm: ssh-ed25519 satırı klasik bir imzayı belirtir; rsa-sha2-512 ve ECDSA (eliptik eğri dijital imza algoritması) türleri de aynı şekildedir. Çalışan bir kuantum bilgisayara sahip bir saldırgan, bu imzayı taklit ederek sunucunuzun kimliğine bürünebilir; ancak bu durum yalnızca gelecekteki canlı bir bağlantı sırasında gerçekleşebilir ve halihazırda kaydedilmiş trafik üzerinde hiçbir etkisi olmaz.

Oturum açma anahtarınız da korunmamaktadır. ~/.ssh/id_ed25519 içindeki anahtar, aynı klasik imza türündedir ve aynı mantık burada da geçerlidir. Bu anahtarı bu yıl koruyan şey, nerede saklandığı ve kimlerin okuyabildiğidir; bu yüzden mantıklı SSH anahtar yönetimi, gerçek riskinizi bu sayfadaki herhangi bir algoritma isminden çok daha uzağa taşır.

Bu iki durum hakkında yapabileceğiniz bir şey yoktur, çünkü geçiş yapabileceğiniz bir alternatif bulunmamaktadır. OpenSSH, kuantum sonrası imza desteğinin gelecekteki bir sürümde geleceğini belirtmiştir. Bu özellik yayınlanana kadar OpenSSH'in kuantum sonrası bir sunucu anahtarı türü veya kuantum sonrası bir kullanıcı anahtarı türü yoktur; ssh-keygen ise size sunabileceği herhangi bir seçenek barındırmaz. Size bir tane oluşturmanızı söyleyen bir rehber, henüz var olmayan bir yazılımdan bahsediyordur.

Aynı sunucudaki TLS, ayrı bir cevabı olan ayrı bir konudur. TLS (taşıma katmanı güvenliği), web sunucunuzun 443 numaralı portta kullandığı protokoldür ve farklı bir zaman çizelgesine sahip farklı bir kod tabanıdır. OpenSSH'i yükseltmek orada hiçbir şeyi değiştirmez. Eğer aynı VPS üzerinde özel bir servis için kendinden imzalı bir sertifika kullanıyorsanız, bunun imzası ve anahtar değişimi OpenSSL ve web sunucunuz tarafından belirlenir; bu nedenle o yığınla ilgili soruları kendi bağlamı içerisinde değerlendirin.

Makul bir operatörün şu anda yapması gerekenler

OpenSSH'i güncel tutun ve bununla yetinin. Bu soruna yönelik tüm strateji aslında bundan ibarettir. sudo apt update && sudo apt upgrade sizi Ubuntu sürümünüzün sunduğu versiyonda tutar; daha yeni bir Ubuntu sürümüne geçmek ise sizi daha yeni bir OpenSSH sürümüne taşır. Otomatik güvenlik güncellemelerini açmak, bu yamaların siz hatırlamak zorunda kalmadan uygulanmasını sağlar. Bir algoritma isminin peşinden gitmek için OpenSSH'i kaynak koddan derlemek kötü bir takastır; çünkü sunucudaki en açık servisin dağıtım tarafından sağlanan güvenlik güncellemelerinden vazgeçmiş olursunuz. Yine de kaynak kodu indirirseniz, derlemeden önce dosyayı yayınlanan sağlama toplamı (checksum) ile doğrulayın.

Elle KexAlgorithms satırı yazmayın. Bu, işleri güvenilir bir şekilde daha kötü hale getiren tek eylemdir. 2018 yılından kalma bir sıkılaştırma rehberi size o yıl için doğru olan bir liste verir; bunu sshd_config içine yapıştırmak, varsayılan listeye ekleme yapmak yerine onu tamamen değiştirir. O tarihten beri icat edilen tüm algoritmalar artık dışarıda kalır; dolayısıyla kendi başına mlkem768x25519-sha256 ile anlaşabilecek bir sunucu, sessizce sabitlenmiş listede hayatta kalan herhangi bir algoritmaya düşer. Devraldığınız herhangi bir sunucuda sudo sshd -T | grep -i '^kexalgorithms' komutunu çalıştırın. Eğer bu satır, aynı sürümün temiz bir kurulumundaki satırdan daha kısaysa, birisi onu sabitlemiş demektir.

Listeyi değiştirmek için gerçek bir nedeniniz varsa, değiştirmek yerine ekleme yapın. OpenSSH, başında + olan ifadeyi ekleme, - olanı kaldırma, ^ olanı ise başa taşıma olarak okur.

KexAlgorithms ^mlkem768x25519-sha256

Dosyaya güvenmeden önce test edin. sudo sshd -t yapılandırmayı ayrıştırır ve geçerli olduğunda hiçbir çıktı vermez. Derlemede bulunmayan bir algoritmayı adlandıran bir KexAlgorithms satırı, sshd'nin başlamasını engeller. Uzak bir sunucuda bu, içeri giremeyeceğiniz anlamına gelir; bu yüzden çalışırken ikinci bir oturumu açık tutun. İki tarafın listeleri örtüşmeyi bıraktığında, istemci bunu açıkça belirtir:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

"Kuantum güvenli" pazarlamasını tek bir katmanla ilgili bir iddia olarak okuyun. Bir ürünün kuantum güvenli olduğunu iddia eden bir satıcı, ismini verdiği katmanı tanımlıyordur ve bu katman genellikle bir anahtar değişimidir. Algoritma ismini ve uygulandığı protokolü sorun. Ağustos 2026 itibarıyla OpenSSH için bu iddianın dürüst versiyonu, anahtar değişiminin hibrit kuantum sonrası (post-quantum), imzaların ise klasik olduğu şeklindedir. Bundan daha kapsamlı herhangi bir iddia, ssh -Q kex çıktısında bulabileceğiniz bir isimle gelmelidir.

Sıkıcı kısımları yapmaya devam edin. Kuantum sonrası bir anahtar değişimi, tahmin edilebilir bir parola veya daha sonra çalınan bir dizüstü bilgisayara kopyalanan özel bir anahtar (private key) konusunda hiçbir işe yaramaz. Sunucuların ele geçirilmesine asıl neden olan şeyler bunlardır ve bir VPS üzerinde standart SSH sıkılaştırması hala yükün neredeyse tamamını taşır. Buradaki anlaşma adımları size yabancı geldiyse, SSH bağlantı kurduğunda ne yapar sayfası, bu sayfanın bildiğinizi varsaydığı aşamaları kapsar.

FAQ

SSH baglantim halihazirda kuantum sonrasi (post-quantum) mi?

ssh -v yourserver 2>&1 | grep 'kex: algorithm' komutunu calistirin ve ciktida yazan ismi okuyun. mlkem768x25519-sha256 ve sntrup761x25519-sha512@openssh.com hibrit kuantum sonrasi anahtar degisimleridir. curve25519-sha256, ecdh-sha2-nistp256 ve herhangi bir diffie-hellman-group ismi klasik yontemlerdir. Her iki ucun da kuantum sonrasi bir isim sunan versiyona sahip olmasi gerekir; cunku muzakere sureci, istemcinin ilk tercihini sunucunun da desteklemesi durumunda devreye girer. Bu nedenle eski olan makine ust siniri belirler.

Kuantum sonrasi anahtar degisimini varsayilan yapan ilk OpenSSH surumu hangisidir?

2022-04-08 tarihinde yayinlanan OpenSSH 9.0, sntrup761x25519-sha512@openssh.com algoritmasini varsayilan anahtar degisimi haline getirdi. 2024-09-19 tarihinde yayinlanan OpenSSH 9.9, mlkem768x25519-sha256 destegini ekledi; 2025-04-09 tarihinde yayinlanan OpenSSH 10.0 ise bunu varsayilan yapti. 2025-10-06 tarihinde yayinlanan OpenSSH 10.1, baglantida herhangi bir kuantum sonrasi algoritma muzakere edilmediginde uyari vermeye basladi. Kendi derlemenizin ne yaptigini ssh -Q kex ve ssh -G <host> ile kontrol edin; cunku kullandiginiz Ubuntu surumu bunlardan hangisine sahip oldugunuzu belirler.

Kuantum sonrasi bir SSH anahtari olusturmali miyim?

Hayir, cunku OpenSSH'te boyle bir anahtar turu bulunmamaktadir. Kuantum sonrasi calismalar su ana kadar yalnizca anahtar degisimini kapsamaktadir; bu surec sizden herhangi bir anahtar dosyasi veya yapilandirma gerektirmez. Sunucu anahtarlari ve oturum acma anahtarlari hala Ed25519 ve RSA gibi klasik imzalardir. Gelistirici ekip, kuantum sonrasi imzalarin gelecekteki bir surumde gelecegini belirtmistir. Ed25519 anahtarini kullanmaya devam edin ve anahtar dosyasinin saklandigi yeri koruyun.

ssh neden baglantimin kuantum sonrasi olmadigina dair uyari veriyor?

OpenSSH 10.1 ve uzeri surumler, muzakere edilen degisimde kuantum sonrasi bir bilesen bulunmadiginda ** WARNING: connection is not using a post-quantum key exchange algorithm. ciktisini verir. Bu uyari istemcinizle degil, sunucuyla ilgilidir; cunku istemciniz kuantum sonrasi bir isim sunmus ancak sunucu bunlardan hicbirini kabul etmemistir. Sunucunun OpenSSH surumunu yukseltin veya sshd_config dosyasinda hic kimsenin modern isimleri dislayan bir KexAlgorithms satiri eklemediginden emin olun. WarnWeakCrypto no ayarini yapmak mesaji gizler ancak baglantiyi oldugu gibi zayif birakmaya devam eder.