HTTPS üzerinden SSH bağlantısı

 (trofi.github.io)
3 puan yazan GN⁺ 2023-12-25 | 1 yorum | WhatsApp'ta paylaş
  • Kısıtlı ağlarda SSH portu engelli olsa bile HTTPS 443 portu ve CONNECT yöntemiyle uzaktan erişim yolu oluşturulabilir
  • Sunucu tarafında apache2'nin mod_proxy_connect modülüyle CONNECT açılır, ancak proxy kapsamını daraltmak için yalnızca ssh-server:22 hedefine izin verilir
  • İstemci tarafında OpenSSH'nin ProxyCommand özelliği socat ile birleştirilir; HTTPS için ise betik CONNECT başlıklarını doğrudan gönderir
  • Bazı güvenlik duvarları veya httpd boşta kalan bağlantıları kapatabileceğinden, oturumu canlı tutmaya yardımcı olmak için ServerAliveInterval 30 kullanılır
  • Bu yöntem SSH'yi TLS içinde kapsülleyerek engellemeleri aşmayı kolaylaştırır, ancak çift katmanlı şifreleme ve istemci yapılandırma yükü sürer

Kısıtlı ağlarda SSH erişim yolu oluşturma

  • Hastane Wi-Fi ortamında bağlantı türlerinin çoğu engelleniyor ve genellikle yalnızca HTTP için TCP 80 ile HTTPS için TCP 443 izinli
  • DNS için UDP 53 ve DoT için TCP 853'ün, bilinen DNS sağlayıcıları açısından çalıştığı görüldü
  • SSH, TCP 22 ve özel portların çoğunda tamamen engelli
  • Uzak sunucuyu yeniden yapılandırmaya imkân veren bir GSM yedek bağlantısı bulunduğundan çeşitli aşma yöntemleri denenebildi

Tek port paylaşımı ve protokol kapsülleme

  • Tek bir portta hem SSH hem HTTPS alıp bunları şeffaf biçimde ayırmanın bir yolu var
    • sslh project, sezgisel yöntemlerle protokolü tahmin edip gerçek arka uca, yani SSH, HTTPS veya desteklenen başka bir protokole yönlendirir
    • Avantajı, ssh istemcisinde özel bir ayar gerekmemesi ve yalnızca varsayılan olmayan portun belirtilmesinin yeterli olmasıdır
    • Dezavantajı ise ek bir hizmet kurulması gerekmesi, HTTPS'nin de sslh üzerinden geçmesi ve arka uçta bağlantının kaynak adresinin gizlenmesi nedeniyle loglamanın zorlaşabilmesidir
  • Başka bir seçenek, bir protokolü diğerinin içine tamamen kapsüllemek
    • OpenSSH'deki ProxyCommand, kullanıcıya ssh protokolünün kullanacağı taşıma yöntemini belirleme imkânı verir
    • Sezgisel tahmin kullanmadan SSH başka bir akış içine sarıldığından, DPI yazılımlarının bunu engellemesi daha zor olabilir
    • HTTPS'nin kendisi yönlendirilmez ve etkilenmez
    • Buna karşılık çift katmanlı şifreleme nedeniyle performans düşebilir ve istemci ayarı gerekir

HTTP üzerinden SSH yapılandırması

  • Önce SSH'yi HTTP üzerinden geçirmek denendi
  • Sunucu tarafındaki apache2 yapılandırmasında mod_proxy_connect yüklenir ve AllowCONNECT 22 ile 22 numaralı porta CONNECT izni verilir
  • <Proxy *> varsayılan olarak her şeyi reddeder; yalnızca <Proxy ssh-server> izinli bırakılarak hedef ssh-server:22 ile sınırlandırılır
  • İstemci tarafındaki .ssh/config, ProxyCommand içinde socat'ın PROXY:http-server:%h:%p,proxyport=80 seçeneğini kullanır
  • Bu ayarla $ ssh ssh-via-http çalıştırıldığında 80 numaralı port üzerinden SSH bağlantısı kurulabilir
  • ServerAliveInterval 30, aradaki yol üzerinde boşta kalan HTTP bağlantılarının sessizce kapatılmasını önlemek için periyodik olarak yoklama gönderir
  • Varsayılan httpd, giriş veya çıkış olmadan 60 saniye geçtiğinde tüneli kapatan TimeOut 60 değerini kullanır

HTTPS üzerinden SSH yapılandırması

  • socat'ın, CONNECT yöntemi kullanan HTTPS proxy desteği sunmadığı ve yalnızca HTTP desteklediği görüldü
  • Bunun yerine socat'ın TLS kapsülleme özelliği kullanıldı ve CONNECT tabanlı istek betik içinde doğrudan uygulandı
  • ~/.ssh/https-tunnel.bash şu akışla çalışır
    • Önce CONNECT ssh-server:22 HTTP/1.1 başlığı ve Host: ssh-server yazdırılır
    • Ardından standart girdi olduğu gibi eklenir
    • Tüm akış, TLS bağlantısı oluşturmak için socat - "SSL:$3:$4" komutuna aktarılır
  • .ssh/config içinde Host ssh-via-https için ProxyCommand ~/.ssh/https-tunnel.bash belirtilir
  • $ ssh ssh-via-https çalıştırıldığında beklendiği gibi HTTPS tüneli üzerinden ssh-server bağlantısı kurulur

Kullanımda dikkat edilmesi gerekenler

  • HTTPS'nin yaygın biçimde izinli olduğu ortamlarda bu yöntem, çok kısıtlayıcı ara cihazlardan veri geçirmeyi mümkün kılabilir
  • CONNECT yöntemi eski bir kalıntı gibi görünse de, keyfi bir TCP yük akışını TLS ana makine akışı içinde sarmak için kullanışlıdır
  • ServerAliveInterval, alt taşıma katmanı boşta kalan bağlantılara dostça davranmadığında OpenSSH bağlantısını korumaya yardımcı olur
  • nginx yapılandırma varyasyonu için bkz. CONNECT passthrough on nginx

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-25
Hacker News yorumları

  • Yazıdaki “HTTPS her yerde olduğu için çok kısıtlayıcı ara cihazlar bile veriyi geçirebilir” kısmı, neredeyse tüm tescilli VPN protokollerinin, yani “SSL VPN” denen şeylerin HTTPS üzerinden tünel açma modunu uygulamasının tam nedeni
    Varsayılan davranış olmasa bile en azından alternatif yol olarak koyuyorlar; amaç, dünya genelindeki internet bağlantılarının neredeyse tamamında çalışacak bir moda sahip olmak
    Çeşitli TLS tabanlı VPN protokollerini uygulayan https://gitlab.com/openconnect/openconnect projesinin başlıca geliştiricilerinden biriyim; ayrıca daha fazla TLS tabanlı VPN sunucusu türünü tespit edip tanımlayan https://github.com/dlenski/what-vpn aracını da yaptım

    • Bağlantıların işe yararlığını kaba biçimde sınırlama girişimleri yüzünden portların asıl amacıyla kullanılmasının zorlaşması üzücü

  • Eskiden Hollandalı internet sağlayıcısı XS4ALL tam olarak böyle bir özellik sunuyordu
    80 numaralı porttan SSH erişimi açıyordu ve seyahat sırasında otel WiFi’ının 80 numaralı port dışında her şeyi engellediği durumlarda birkaç kez işime yaradı

    • XS4ALL harikaydı; KPN’nin o markayı kaldırmaya karar vermesi gerçekten üzücü
      Yine de KPN açısından bakınca XS4ALL’in hacker kültürü baştan beri pek rahat hissettirmemiş olabilir
    • XS4ALL kullanıcısıydım; gerçekten harikaydı ve erken dönem internet ruhu hâlâ yaşıyordu
      1960’lardaki korsan radyo kültürünün yeniden canlanması gibi hissettiriyordu
      https://en.wikipedia.org/wiki/Pirate_radio_in_Europe
    • SSH için standart dışı portlar arasında 443 numaralı port üst sıralarda yer alıyor
      https://www.shodan.io/search/facet?query=ssh&facet=port
      https://www.shodan.io/search/facet.png?query=ssh&facet=port
      Buna karşılık 80 numaralı port çok daha az yaygın
    • XS4ALL’in tam teşekküllü bir internet sağlayıcısı olduğunu bilmiyordum
      Eskiden onu yalnızca haber grubu sağlayıcısı olarak kullandığımı hatırlıyorum
    • XS4ALL bir ölçüde Freedom biçiminde devam ediyor: https://freedom.nl/en

  • Sık görülen üçüncü bir seçenek de var: Başka bir hostun 80 veya 443 numaralı portunda SSH çalıştırıp oradan hedefe ProxyJump kullanmak
    Ya da o hosta SOCKS açarak genel olarak daha az filtrelenen bir internet bağlantısı elde edebilirsiniz
    Ben SOCKS kullanıyorum ve SSH bağlantısının port forwarding’i üzerinden TLS tabanlı DNS’i de geçiriyorum
    Birkaç yıl önce SOCKS proxy’yi ilk kurup WiFi’ı epey kullandığımda portu kontrol etmenin ötesine geçen bir yer görmemiştim; ama böyle cihazlar var ve şimdi daha yaygın olabilir

    • Lise birinci sınıftayken self-hosting’e yeni başlamıştım; okul web sitelerini engelliyordu ama port engelleme hiç yoktu
      Bu yüzden doğrudan kendi sunucuma SSH ile bağlanıp normal şekilde kullandım
      Sonra Windows .iso dosyalarından bir arşiv oluşturup dizüstü bilgisayarıma indirdim ve scp ile sunucuya yükledim; 80/443 dışındaki bir portta toplamda onlarca GB upload/download trafiği oluşturmak trafik denetimini tetiklemeye yetmiş olacak ki öğleye doğru BT ekibi 22 numaralı portu engelledi
      Ama diğer portları engellemedikleri için port yönlendirmede SSH’yi 443’e taşıyıp kullanmaya devam ettim
      Ardından okulun BT ekibi 443’te SSH kullandığımı fark edip 80/443 üzerindeki SSH’yi engelleyen temel trafik analizi ekledi, fakat diğer tüm portlar hâlâ açıktı
      Sonunda sunucumu IP bazında engellediler ama diğer tüm IP’ler açıktı
      VPS üzerinden ProxyJump kullanarak aşmak mümkün; ancak erken üniversite lisesi programı olduğu için 2. sınıftan sonra okula neredeyse hiç gitmediğimden zahmete pek değmez
      Bir dahaki gidişimde mümkün olduğunu kanıtlamak için denemeyi düşünüyorum; tüm portlarda SSH’yi engellerlerse VPS’te HTTPS üzerinde SSH çalıştırmak yeterli olur
      Mezuniyetten sonra misafir WiFi’ında nelerin mümkün olduğuna tekrar bakmayı düşünüyorum

  • Biraz bariz reklam olacak ama Adaptive [1]’de veri güvenliği altyapısı geliştiriyoruz
    Ürünlerimizden birinde SSH ve başka birkaç protokolü HTTP/3 üzerinden taşıyarak kullanıcıların tek bir outbound port üzerinden veritabanlarına, sunuculara ve diğer kaynaklara bağlanmasını sağlıyoruz
    Ngrok benzerleri gibi ama self-host edilebiliyor; parolasız erişim sağlanabiliyor veya geçici kimlik bilgileri ve maker-checker koruması eklenebiliyor
    [1] https://adaptive.live/

  • Pratikte openssh’i 443 numaralı portta dinletmek bile çoğu güvenlik duvarını aşmaya yetiyordu

  • Güzel. Garip şekilde CONNECT metodunu ileri proxy değil de ters proxy gibi hiç düşünmemiştim
    Ancak benim durumumda yalnızca CONNECT yetmedi; şirket proxy’sini aşmak için WebSocket üzerinde SSH kullandım
    O proxy, özel bir CA ile HTTPS bağlantılarını denetliyordu
    socat’ı değiştirerek SSH sunucumu Apache üzerinden WebSocket ile sundum ve istemci tarafında OpenSSH’nin ProxyCommand’i ile kullandım
    O yamayı yayımlamalıyım diye düşünüp duruyorum; ama websocat gibi başka seçenekler de var

    • Bu yüzden birçok şirket proxy’si veya güvenlik duvarı WebSocket’i varsayılan olarak engelliyor gibi görünüyor
    • İstemeden huproxy’yi yeniden yapmışsınız gibi geliyor

  • Neredeyse 20 yıl önce şirket güvenlik duvarında bir delik açmak için tam olarak bu işi yapan corkscrew[0] aracını kullanmıştım
    Bağımsız uygulama ve yazı temiz
    0: https://github.com/bryanpkc/corkscrew

    • Anladığım kadarıyla corkscrew yalnızca belirli koşullarda çalışıyor: Bir HTTP proxy arkasında olmanız ve o HTTP proxy’nin CONNECT metodunu desteklemesi gerekiyor
      Yaklaşık 20 yıl önce kısa süreli bir sözleşmeli iş yaptığımda ilk koşul vardı ama ikinci koşul yoktu
      Neyse ki böyle durumlarda da kullanılabilecek bir araç var; elbette sunucu tarafı yapılandırması gerekiyor
      https://github.com/larsbrinkhoff/httptunnel

  • Genel olarak HTTP/2 üzerinden tünellemenin iyi bir tercih olduğu ortaya çıktı
    HTTP/2 üzerine kurulmuş bir uzaktan prosedür çağrısı protokolü olarak gRPC[1] var
    Çünkü HTTP/2, tek bir TCP bağlantısını kullanarak birden fazla veri yapısını eşzamanlı gönderip almaya yarayan çoğullamada güçlü
    Ancak QUIC’in kendisi çoğullama sunduğu için HTTP/3 kullanmaya gerek olmayabilir
    İleride, aradaki cihaz üreticileri ayrımcılığı bırakmayı başaramayacağı için çoğu iletişimin şifreli HTTP/2 ve QUIC üzerinden gideceğini düşünüyorum
    Aktif yoklamayı[2] hafifletmek için rastgele, belki de yapay zeka tarafından üretilmiş HTTP/2·HTTP/3 içerikleri sunmak gerekebilir
    [1] <https://grpc.io>
    [2] <https://blog.torproject.org/learning-more-about-gfws-active-...>

    • HTTP’nin üstüne neden bir de uzaktan prosedür çağrısı protokolü koyulduğunu pek anlayamıyorum
      HTTP’nin kendisi zaten bir istek/yanıt protokolü ve temelde uzaktan prosedür çağrısı için kullanılabilir
      HTTP 1, 2, 3 hangisi olursa olsun büyük bir fark yok gibi görünüyor
      Bu protokolün evriminin kendisi de biraz şüpheli; uzaktan prosedür çağrısı ortamında gerekmeyen şeylerden yararlanacak şekilde tasarlanmış tarafları var
      Özünde yerel servisler için değil, açık internet için tasarlanmış bir şeye daha yakın
    • SSH söz konusu olduğunda yalnızca tek bir bağlantı var ve SSH zaten kendi çoğullamasını uyguladığı için HTTP/2’nin avantajı pek görünmüyor
    • HTTP/2 hâlâ TCP olduğu için TCP head-of-line blocking sorununu yaşar
      HTTP/3, QUIC üzerinde çalışır

  • Ben tersine SSH üstünde HTTPyi daha çok tercih ederim
    Yarı şaka bir yana, tarayıcılarda SSH’ye denk bir kimlik yönetimi yerleşik olsa güzel olurdu
    Açık anahtarlı HTTP kimlik doğrulama önerisi hobo’yu ilk okuduğumda heyecanlanmıştım ama ne sunucu uygulaması ne de tarayıcı istemcisi uygulaması olduğunu fark ettim
    JavaScript uygulaması var ama istediğim biçimde değildi

    • ssh -D “*:8080” host
      Bu komut 8080 portunda bir SOCKS proxy başlatır
      Firefox’ta sürekli kullanıyorum ve ilk dönem VPN’ler gibi çalışıyor
      Şüpheli amaçlar için de kullanışlı ama AWS’in özel ağındaki rmq panosuna erişirken de kullanıyorum
    • HTTPS istemci sertifikaları nasıl olur?
      https://techcommunity.microsoft.com/t5/iis-support-blog/clie...
      Gereksinimleri karşılayıp karşılamadığını bilecek kadar ayrıntısını bilmiyorum ama üniversitedeyken sunucu kimlik doğrulamasında kullanmıştım
    • Bahsettiğin şey passkey değil mi?
    • Tarayıcıda ssh://google.com mümkün olsaydı güzel olurdu
    • Geçen hafta kaçırdıysanız benzer yönde bir yazı vardı: SSH3, HTTP/3 ve QUIC kullanan SSHv2
      https://news.ycombinator.com/item?id=38664729

  • sslh neden hak ettiği ilgiyi görmüyor?
    HTTP, TLS/SSL (SNI ve ALPN dahil), SSH, OpenVPN, tinc, XMPP, SOCKS5’i algılayabiliyor; düzenli ifadeyle denetlenebilen başka protokolleri de tanıyabiliyor
    Tipik kullanım, 443 portunda birden fazla servisi birlikte sunmak
    Örneğin şirket güvenlik duvarının içinden SSH’ye bağlanırken aynı portta HTTPS sunmaya devam edebilirsiniz
    https://www.rutschle.net/tech/sslh/README.html

    • Yazının ilk yarısı sslh ile tam kapsülleme arasında hangisinin seçileceği hakkındaydı
      Tam kapsüllemeyi seçme nedenleri, yapılandırılacak bir servis daha az olması, bağlantıyı HTTP sunucusunun işlemesi sayesinde loglardaki uzak adresin doğru olması ve muhtemelen hacker ruhu gereği mevcut çözümler yerine yeni çözümleri daha çok sevmeleri gibi görünüyor