Ubuntu uzerinde post-quantum SSH kontrolu nasil yapilir

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 gerektirmemiştir. Güncel bir OpenSSH istemcisi, güncel bir OpenSSH sunucusu ile iletişim kurduğunda 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 dar kapsamlıdı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şimidir. Başka 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ı önerebilir ve bunu size bildirecek bir mekanizması yoktur. Bu komutları öğrenin; böylece bu makale de dahil olmak üzere bu konudaki yazılara ihtiyaç duymayı bırakırsınız.

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

ssh -V
ssh -Q kex

ssh -V, OpenSSH_ ile başlayan bir sürüm satırı ve ardından Ubuntu paket soneki ile 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 curve25519-sha256 gibi klasik isimlerin yanında mlkem768x25519-sha256 ve sntrup761x25519-sha512@openssh.com gibi isimler de göreceksiniz.

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

Çoğu makalenin 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 boşluk, 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 olan yapılandırmasını yazdırır. sshd -T aynı işlemi sunucu için yapar. Her biri tercih sırasına göre tek bir kexalgorithms satırı yazdırır ve bu satırdaki ilk isim, ilgili tarafın ilk tercihidir. Ağ üzerinden gönderilen veri bu satırdır.

Bu boşluk 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 bir melezdir. 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ı içinde harmanlar.

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

debug1: kex: algorithm: curve25519-sha256

Bu ismin kuantum sonrası bir yarısı yoktur. curve25519-sha256 tek başına 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 neden 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 kazanır, bu nedenle iki uçtan daha eski olanı listede ne kadar yukarı çıkabileceğinize karar verir. Dizüstü bilgisayarınızı yükseltmek, ML-KEM'den hiç haberi olmayan bir sunucuya yapılan oturumu yükseltmez.

grep ve ssh -v komutlarını bırakın, bir sonraki bölümün konusu olan satır da dahil olmak üzere müzakerenin geri kalanını gösterir:

debug1: kex: host key algorithm: ssh-ed25519

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

Upstream sürüm notları net bir sıralama sunar. 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ü, ikinci bir seçenek olarak mlkem768x25519-sha256 özelliğini ekledi. Aynı sürüm, eski yönteme IANA kayıtlı adını, yani sntrup761x25519-sha512 adını 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 mutabakatı için varsayılan yaptı.
• 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 özellik ssh_config içindeki WarnWeakCrypto seçeneği ile kontrol edilir ve varsayılan olarak açıktır.

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 sürüm yayınlandığında OpenSSH sürümünü 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 şöyledir:

• 22.04 LTS, 9.0 varsayılanından daha eski olan 1:8.9p1 ile gelir, bu nedenle standart bir kurulum curve25519-sha256 üzerinden anlaşma sağlar.
• 24.04 LTS, 9.0'dan sonra ve 9.9'dan önce gelen 1:9.6p1 ile gelir; bu nedenle varsayılanı sntrup761x25519-sha512@openssh.com'dur ve ML-KEM içermez.
• 25.10, varsayılanı mlkem768x25519-sha256 olan 1:10.0p1 ile gelir.
• 26.04 LTS, varsayılanı mlkem768x25519-sha256 olan 1:10.2p1 ile gelir ve kuantum sonrası (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 yoktur. İstemcinin sunucuda bulunan bir sonraki kuantum sonrası tercihi sntrup761x25519-sha512@openssh.com'tir ve ssh -v'nın raporladığı isim budur. Oturum, 2024 yapımı bir sunucuya karşı, kimse tarafından özel bir yapılandırma yapılmadan, anahtar değişimi aşamasında kuantum sonrası güvenliğe sahiptir.

22.04 durumu ise tam tersi yönde işler ve ssh -Q kex komutunun tek başına neden yanıltıcı olduğunu 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 gerçekleşir. 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.

Hibrit yapı neden gereklidir ve "şimdi topla, sonra şifresini çöz" ne anlama gelir

Tehdit oldukça belirgindir. Trafiğinizi görebilen bir saldırgan, şifrelenmiş baytları bugün kaydeder ve saklar. Bugün bunları okuyamaz. Verileri, X25519 algoritmasını kırabilecek kadar büyük bir kuantum bilgisayarı var olana kadar tutar ve ardından okur. Buna "şimdi topla, sonra şifresini çöz" veya "şimdi depola, sonra şifresini çöz" denir. Bu yöntem, saldırgandan günümüzde herhangi bir zeka gerektirmez. Sadece disk alanı ve sabır ister.

Ş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 imzanın ise yalnızca kontrol edildiği anda taklit edilemez olması gerekir. 2035 yılında bir imza algoritmasını kırmak, birinin 2035'te bir sunucuyu taklit etmesine olanak tanır. Ancak bu, geçmişe gidip 2026 yılından bir oturum açma işlemini sahte olarak oluşturmalarını sağlamaz. 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 kusur, halihazırda sahip olduğunuz korumayı ortadan kaldırmaz.

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 kullanıma girdiğinde 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ışır durumda 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.

Giriş anahtarınız da korunmamaktadır. ~/.ssh/id_ed25519 içindeki anahtar da aynı klasik imza türündedir ve aynı mantık bunun için de geçerlidir. Bu anahtarı bu yıl koruyan şey, nerede saklandığı ve kimlerin okuyabildiğidir; bu nedenle 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 ve ssh-keygen size bu konuda sunabileceği bir seçenek barındırmaz. Size bir tane oluşturmanızı söyleyen bir rehber, henüz var olmayan bir yazılımı tarif ediyordur.

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 bu durumu 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 ilgili yığın hakkında kendi özelinde bilgi edinin.

Makul bir operatörün 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 OpenSSH sürümüne geçmenin yolu, daha yeni bir Ubuntu sürümüne geçmektir. Otomatik güvenlik güncellemelerini açmak, bu yamaların siz hatırlamak zorunda kalmadan uygulanmasını sağlar. Sırf bir algoritma isminin peşinden gitmek için OpenSSH'i kaynak kodundan derlemek kötü bir tercihtir; çünkü sunucudaki en açık servis için dağıtımın sağladığı güvenlik güncellemelerinden vazgeçmiş olursunuz. Yine de kaynak kodunu indirirseniz, derlemeden önce dosyayı yayınlanan sağlama toplamı (checksum) ile doğrulayın.

KexAlgorithms satırını elinizle 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 kılavuzu size o dönem için doğru olan bir liste verir; bunu sshd_config içine yapıştırmak, mevcut listeye ekleme yapmak yerine varsayılan listeyi tamamen değiştirir. O tarihten beri icat edilen tüm algoritmalar devre dışı kalır ve kendi kendine mlkem768x25519-sha256 ile anlaşabilecek bir sunucu, sessizce sabitlenmiş listede hayatta kalan herhangi bir algoritmaya düşer. Devraldığınız her 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 geçerli 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ı belirten KexAlgorithms satırı, sshd'nin başlamasını engeller. Uzak bir sunucuda bu, sisteme tekrar giremeyeceğiniz anlamına gelir; bu yüzden çalışırken ikinci bir oturumu açık tutun. İki tarafın listeleri örtüşmediğinde, 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" pazarlama ifadelerini tek bir katmana yönelik bir iddia olarak okuyun. Bir ürünün kuantum güvenli olduğunu iddia eden satıcı, sadece ismini verdiği katmanı tanımlıyordur ve bu katman genellikle bir anahtar değişimidir. Algoritma ismini ve hangi protokole uygulandığını 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 çalınan bir dizüstü bilgisayara kopyalanmış özel bir anahtar (private key) karşısında 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ı yükün neredeyse tamamını taşımaya devam eder. Buradaki anlaşma adımları size yabancı geldiyse, SSH bağlantı kurduğunda ne yapar başlıklı yazı, 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 yer alan ismi okuyun. mlkem768x25519-sha256 ve sntrup761x25519-sha512@openssh.com hibrit kuantum sonrasi anahtar degisimleridir. curve25519-sha256, ecdh-sha2-nistp256 ve diger tum diffie-hellman-group isimleri klasik yontemlerdir. Her iki ucun da kuantum sonrasi bir isim sunan bir surume sahip olmasi gerekir; cunku muzakere sureci, sunucunun da destekledigi ilk istemci tercihini secer, bu nedenle eski olan makine ust siniri belirler.

Kuantum sonrasi anahtar degisimini varsayilan yapan 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 ve 2025-04-09 tarihinde yayinlanan OpenSSH 10.0, bu algoritmayi varsayilan yapti. 2025-10-06 tarihinde yayinlanan OpenSSH 10.1, baglanti herhangi bir kuantum sonrasi algoritma ile muzakere edilmediginde uyari vermeye basladi. Kendi derlemenizin ne yaptigini ssh -Q kex ve ssh -G <host> ile kontrol edin; zira kullandiginiz Ubuntu surumu, bu ozelliklerden 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 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 anahtari kullanmaya devam edin ve anahtarinizin 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 bunlarin hicbirini kabul etmemistir. Sunucunun OpenSSH surumunu yukseltin veya sshd_config dosyasinda modern isimleri dislayan bir KexAlgorithms satiri olup olmadigini kontrol edin. WarnWeakCrypto no ayarini yapmak mesaji gizler ancak baglantiyi oldugu gibi zayif birakir.