SSH3 - HTTP/3 Kullanan Daha Hızlı ve Daha Zengin Bir Güvenli Kabuk

 (github.com/francoismichel)
8 puan yazan GN⁺ 2025-09-28 | 1 yorum | WhatsApp'ta paylaş
  • SSH3, HTTP/3 üzerinde çalışan yeni nesil bir güvenli kabuk protokolü olup, geleneksel SSHv2'ye kıyasla oturum bağlantı hızını büyük ölçüde artırır
  • QUIC ve TLS 1.3 ile güvenli kanal kurar; OAuth 2.0, OpenID Connect gibi modern kimlik doğrulama sistemlerini destekler
  • Sunucuyu gizli bir yolun arkasına saklayabildiği için port tarama gibi saldırılara karşı dayanıklıdır; UDP port yönlendirme ve QUIC multipath gibi yeni özellikler sunar
  • OpenSSH'in birçok temel özelliğini şimdiden benimsemiştir, ancak şu anda deneysel aşamadadır; bu yüzden gerçek üretim ortamlarına dağıtılması önerilmez
  • SSH3 adının uygun olmadığı yönünde çok sayıda görüş bulunduğundan, standardizasyon taslağının adı “Remote Terminals over HTTP/3” olarak değiştirildi ve yeniden adlandırma süreci devam ediyor

SSH3 projesine genel bakış ve önemi

  • SSH3, mevcut SSH protokolünü HTTP/3 ve modern web teknolojilerine uygun şekilde yeniden tasarlayan açık kaynaklı bir çözüm
    • Mevcut SSH bağlantı protokolünün (RFC4254) anlamını HTTP/3 Extended CONNECT ve QUIC+TLS 1.3 kanalı üzerinde yeniden kurar
  • IETF internet taslağı draft-michel-remote-terminal-http3 olarak önerildi; oturum bağlantı süresini önemli ölçüde azaltırken, modern kimlik doğrulama yöntemlerinin genişletilmesi gibi çeşitli avantajlar sunar
  • Diğer SSH uygulamalarına kıyasla, QUIC kullanımı ve gizlenmiş sunucu yapılandırması gibi yenilikçi fikirleriyle öne çıkar

Başlıca işlevler ve özellikler

  • Hızlı oturum bağlantısı
    • Geleneksel SSHv2 bağlantısı ortalama 5~7 ağ gidiş-dönüşü gerektirirken, SSH3 yalnızca 3 gidiş-dönüş gerektirir; bu da kullanıcının hissettiği bekleme süresini büyük ölçüde azaltır
    • Tuş vuruşu gecikmesi (latency) mevcut düzeyde kalır
  • Güçlendirilmiş güvenlik
    • TLS1.3, QUIC ve HTTP kimlik doğrulaması temelinde, e-ticaret ve internet bankacılığı gibi alanlarda hâlihazırda kullanılan, doğrulanmış güvenlik protokollerinden yararlanır
    • RSA, EdDSA/ed25519 tabanlı açık anahtar yöntemleri ile OAuth 2.0, OpenID Connect gibi çeşitli kimlik doğrulama yöntemlerini destekler
    • Google, Microsoft ve Github hesaplarıyla da oturum açılabilir
  • Sunucuyu gizleme özelliği
    • Sunucu, belirli bir gizli URL'nin arkasına yerleştirilir (ör. https://192.0.2.0:443/M3MzkxYWMx...); yalnızca bu URL'ye kimlik doğrulama isteği geldiğinde yanıt verir
    • Diğer isteklere 404 Not Found döndürerek, internetteki saldırganların ve tarayıcıların sunucunun varlığını fark etmesini engeller
    • Ancak gizli yol, kimlik doğrulamanın yerini tutmaz; bu nedenle ayrıca bir kimlik doğrulama mekanizması (açık anahtar, parola, OIDC vb.) kullanılması mutlaka önerilir
  • Geliştirilmekte olan deneysel proje
    • Yapısal olarak güvenilir bir güvenlik doğrulamasına ihtiyaç duyar ve üretim sunucularında kullanılması önerilmez
    • Topluluk geri bildirimleri, deney ortamlarında veya kapalı ağlarda toplanmaktadır
  • OpenSSH uyumluluğu ve ek özellikler
    • ~/.ssh/authorized_keys ve known_hosts ayrıştırma, ssh-agent entegrasyonu, TCP/UDP port yönlendirme, Proxy Jump desteği
    • UDP yönlendirme desteği sayesinde DNS, RTP, QUIC servisleri gibi UDP tabanlı sunuculara erişim yolu sağlar; QUIC datagram yolunu kullanır
    • X.509 sertifikaları ile HTTPS düzeyinde sunucu kimlik doğrulaması
    • Anahtarsız (Keyless) kimlik doğrulama: OpenID Connect ile açık anahtar kopyalamadan, kurumsal SSO veya Google/GitHub gibi harici hesaplarla bağlantı kurulabilir

Sonuç

  • SSH3, modern ağ protokolleri ve kimlik doğrulama yöntemlerini benimseyerek SSH ortamını ileri taşıyan açık kaynaklı, deneysel bir projedir
  • Hız, esneklik ve güvenliği büyük ölçüde artırsa da, yeterli doğrulama yapılmadan önce gerçek üretim kullanımında dikkatli olunmalıdır
  • OpenSSH'e benzer bir kullanıcı deneyimi sunar ve yeni özellikler açısından da zengindir
  • Sağlam bir güvenlik değerlendirmesi ve topluluk katılımıyla, gelecek nesil SSH olarak konumlanma potansiyeli taşır

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-28
Hacker News yorumu
  • ssh3 adını gerçekten hiç beğenmemiştim; deponun en üstünde “SSH3'ün adı değişecek. Şu anda SSH Connection Protocol (RFC4254), HTTP/3 Extended connect üzerinde çalışıyor, ancak gerekli değişiklikler çok fazla ve mevcut SSH'tan fazla farklı olduğu için kolayca entegre edilebilecek düzeyde değil. Taslak spesifikasyonun adını zaten ‘Remote Terminals over HTTP/3’ olarak değiştirdik ve daha iyi, kalıcı bir ad bulmak için zamana ihtiyacımız var” yazıyor olması hoşuma gitti
    • Bu isim, sanki biri “Windows 12” ya da “Linux 7” adlı bir repo açmış gibi, hiç yakışmayan bir his veriyor
    • SSH3 yerine Secure Hypertext Interactive TTY gibi bir isim öneriyorum
    • SSH/3 nasıl olur diye düşündüm (SSH + HTTP/3 hissi veriyor)
    • Bu thread, tam anlamıyla bir bike-shedding tartışmasının başyapıtı
    • SSH2/3 fena olmaz diye düşündüm; çoğu şey SSH2 ama HTTP/3 üzerinde çalışıyor
  • SSH yavaş ve benim deneyimime göre en büyük darboğaz oturum kurulumu. Bunun nedeni PAM olabilir ya da OpenBSD'nin politikaları olabilir ama SSH bağlantısını yeniden kullansam da sıfırdan kursam da her seferinde oturum kurulum aşaması ciddi şekilde yavaş. Uzun süreli oturumlarda sorun değil ama tek bir komut çalıştırmak için bile her seferinde ek yük var; bu yüzden Ansible performansından memnun kalmamıştım ve oturum overhead'i olmayan, uzak komut çalıştırmaya yönelik mini bir ansible'ı kendim yaptım
  • “Bu gerçekten geleneksel SSH'tan daha mı hızlı?” diye şüphelenmiştim ama README'ye bakınca yalnızca bağlantı kurulum aşamasının daha hızlı olduğunu, bağlantıdan sonra gerçek hızın aynı kaldığını görünce mantıklı geldi. Bu kadarı bile makul bir iyileştirme
    • Aslında o anlamda daha hızlı değil. Tek bir SSH bağlantısında birden çok port için trafik yönlendirdiğinizde head-of-line blocking oluşuyor; QUIC/HTTP3 protokolleri bunu çözebilir
    • İddiaya girerim ki bu protokol, yüksek gecikmeli bağlantılarda SSH'tan çok daha hızlı olacaktır; UDP tabanlı olduğu için ack beklemeden büyük miktarda veriyi art arda gönderebilir, dolayısıyla dünyanın dört bir yanına büyük dosyaları scp ile aktarırken ciddi hız artışı bekliyorum
    • VPN üzerinde gerçekten daha hızlı olabilir; çünkü "TCP içinde TCP" tuzağı yok
    • HTTP/3 ve genel olarak QUIC'in ana avantajı, öncekilere kıyasla daha az round-trip gerektirmesi; bağlantı kurulumunun daha hızlı olması da bununla örtüşüyor
  • Açıklama şöyleydi: “SSHv2'de oturum başlatmak için yaklaşık 5-7 round-trip gerekirken, SSH3'te sadece 3 gerekiyor. Gerçek oturum sırasında giriş gecikmesi (tuş basımı–tepki süresi) aynıdır.” Kullanıcı olarak bağlantı hızını hiç o kadar dert etmediğim için bana cazip gelmiyor. SSH'nin savaşta kanıtlanmış sağlamlığı da var ve böyle yeni bir araca, üretim seviyesinde olsa bile, güvenmek riskli geliyor
    • Asıl özellik UDP tüneli; WireGuard'dan çok daha hafif ve OpenID kimlik doğrulaması gibi şeyler de var
    • “Bağlantı hızı” beni her zaman biraz rahatsız etti. Özellikle uzakta komutu hemen çalıştırmak istediğimde yavaş olması can sıkıcıydı
    • ssh3'te head-of-line blocking büyük ihtimalle çözülmüştür; tek bir fiziksel bağlantı üzerinden birden fazla portu ya da bağlantıyı çoklayınca daha hızlı olacaktır
    • Daha akıcı bir kullanıcı deneyimi istiyorsanız Mosh öneririm
  • Tüm uygulama katmanı protokollerinin http içinde erimesi neden bu kadar hüzünlü geliyor bilmiyorum
    • Gerçekten o yöne gidiyorsa üzücü olurdu. HTTP'nin tipik modeli çoğu durumda fazla kısıtlayıcı ve karmaşık olduğu için pek çok yere uymuyor. Ama HTTP/2 ya da QUIC (HTTP/3'ün taşıma katmanı) o kadar genel amaçlı ki, HTTP adının kendisi bile anlamını yitiriyor gibi. En azından QUIC, TCP'nin yerine geçen bir şey olarak oldukça net konumlanıyor
    • Aslında tüm protokollerin bu şekilde standartlaşmasını olumlu görüyorum; trafik şekillendirme ve sansür zorlaşıyor. Sonuçta trafik ya HTTP'dir ya da rastgele bir byte akışıdır; yani göze çarpmıyorsa ağ gözetimi ve engellemesi zorlaşır. Yeni bir protokol tasarlıyorsanız, ISS'nin size özel bir avantaj sağlamadığı sürece, HTTP gibi görünmesi hem yavaşlamadan çalışmanın hem de engellenmeden geçmenin yolu oluyor
    • Böyle olmasının sebebi, kurumsal güvenlik ekiplerinin her şeyi durmadan engellemeye ya da araya girmeye çalışması. Evet, Zscaler ya da TLS middleman modu kullanan ekiplerden bahsediyorum
    • Bu tür engellemeler havaalanı Wi‑Fi'larında ve dünyanın dört bir yanındaki otellerde de görülüyor. Örneğin Apple Mail'in çalışmamasının nedeni şirket politikası gereği 25 numaralı portun engellenmesi olabiliyor. Sözde spam'i önlemek için 143, 587, 993 gibi portları da kapatıyorlar ve sonunda sadece 80 ile 443 açık kalıyor. Umarım IPv6 biraz yardımcı olur. Bir de AB'nin ChatControl girişimleri dursa keşke. Gerçekten IT bilen insanların sözü biraz dinlense iyi olur
    • connection init, yani ağ bağlantısı başlatma karmaşıklığının artması yüzünden sonunda savaşta kendini kanıtlamış protokollere dayanan en iyi uygulamalara çıkmak gerektiğini de anlıyorum. Ama gerçek veri aktarımı artık hypertext değilken buna hâlâ http demek tuhaf geliyor
  • SSH özelliklerinin evrilmesi güzel ama madem neredeyse baştan yapılıyor, biraz daha deneysel yeni özellikler de eklenebilirdi. Örneğin Mosh'taki gibi “roaming / geçici ağ kararsızlığı”na karşı kolaylıklar olsa güzel olurdu https://mosh.org/
    • Mosh'un güzel yanı, tuş tepkisinin inanılmaz hızlı olması ve sanki doğrudan yerel shell üzerinde çalışıyormuşsunuz gibi hissettirmesi. SSH3'te bu konuda bir iyileştirme var mı merak ediyorum. QUIC biraz yardımcı olabilir ama Mosh ile aynı şey değil
    • Benim anladığım kadarıyla connection migration ve multipath desteği QUIC'in temel özellikleri; roaming işlevi ile "yerleşik tmux" arasındaki farkta, bunun sisteme doğrudan entegre olmasının gerçekten ne kadar değerli olduğundan emin değilim
  • Kısa isimlere / kısaltmalara takıntılı insanları anlamıyorum; bence gerçekten kötü. Artık komutlar uzun olabilir, mümkün olduğunca teknik olarak açık uzun isimler kullanılmalı. Varsayılan olarak tam ad kullanılmalı, kısaltmalar ise bazı sistem yöneticileri ya da dağıtımlarda isterse kısaltılsın. İnsanlara tam adı öğretmek lazım. Örneğin cd yerine Set-Location daha tercih edilesi; remote-terminals-over-http3 adı da ssh3'ten daha iyi
  • Son commit 1 yıl önce; projenin yakın zamandaki durumu hakkında bilgisi olan var mı?
  • Projenin planını merak ettim. Ne sürümlerde ne de GitHub etkinliğinde 1 yılı aşkın süredir ses var. Makale temelli başlayan bir çalışma olduğu için ilgili araştırmalar ya da başka yan işler üzerinde çalışıyor olabilirler diye düşünüyorum
    • Buna dikkat çektiğin için teşekkürler. Benim kişisel görüşüm, bu projenin artık bittiği yönünde. Yaklaşık 239 commit ile esasen Proof of Concept seviyesinde; hâlâ ciddi biçimde kullanılabilecek bir şey değil. Öte yandan OpenBSD tarafı (OpenSSH) hâlâ inanılmaz aktif, dolayısıyla yakın zamanda yerini alması için yeterli alan yok gibi görünüyor https://github.com/openbsd/src/commits/master/
  • Proje fikri iyi. Özellikle genel bir H3 proxy ile proxy'lenebiliyorsa umut verici. Üstüne multipath / migration ve TCP kaynaklı blocking sorunlarını da çözerse, bu zaten başlı başına büyük bir ilerleme olur