VPS'inize Tor Üzerinden Nasıl Bağlanılır

Anonymity · 8 dk okuma

Kısa yanıt: SSH'ı Tor üzerinden iki yönde yönlendirebilirsiniz: kendi IP'nizi sunucudan gizlemek için istemcinizi Tor'un yerel SOCKS proxy'sine yönlendirebilir, ya da sunucunun kendisinin clearnet üzerinde hiçbir zaman erişilebilir bir SSH portu olmaması için VPS'in SSH portunu bir Tor onion hizmeti olarak yayınlayabilirsiniz. İkisi birleştirilerek oturumun hiçbir ucu açık internete hiç dokunmayacak şekilde ayarlanabilir. Doğrudan bir bağlantıya kıyasla anlamlı ölçüde daha yüksek gecikme bekleyin; bu yüzden bunu büyük dosya aktarımları için bir taşıma yöntemi değil, etkileşimli kabuk çalışması için bir yönetici erişim tekniği olarak ele alın.

İki farklı problem, ikisi de 'Tor üzerinden SSH' olarak adlandırılıyor

Tor vps erişimi arayan insanlar genellikle iki farklı problemden birini çözmeye çalışıyor ve kurulum, hangisinin geçerli olduğuna göre değişiyor. Birincisi istemci tarafı: kendi IP adresinizi sunucudan, yerel ağınızı izleyen herkesten ve daha sonra VPS sağlayıcısının bağlantı günlüklerine mahkeme celbi çıkaracak herkesten gizlemek istiyorsunuz. İkincisi sunucu tarafı: VPS'in kendisinin hiç herkese açık internetten erişilebilir bir SSH portu olmamasını istiyorsunuz; böylece bir port tarayıcı tarafından bulunamaz, kimlik bilgisi doldurma botu tarafından hedef alınamaz veya dinleyen hizmeti üzerinden konumlandırılamaz.

Bunlar birbirini dışlamaz. ssh over tor hakkındaki forum konularındaki karışıklığın çoğu, insanların 'kim bağlandığını gizlemek istiyorum' ile 'neye bağlanıldığını gizlemek istiyorum'u karıştırmasından kaynaklanır. Bu rehber ikisini de kapsıyor: önce daha basit istemci tarafı kurulumla başlayıp, ardından sunucu için onion-hizmeti yaklaşımına, sonra sonucu sertleştirmeye ve gerçekte ne performans beklemeniz gerektiğine geçiyoruz.

İstemci tarafı anonimlik: SSH istemciniz Tor üzerinden yönlendirilir; böylece sunucu (ve gelen bağlantılarını günlükleyen herkes) gerçek IP'nizi değil, bir Tor çıkış veya relay noktasını görür
Sunucu tarafı anonimlik: sshd yalnızca bir Tor onion adresi üzerinden erişilebilir; böylece SSH için herkese açık bir IP:port hiç yoktur

Yöntem 1: SSH istemcinizi Tor'un SOCKS proxy'si üzerinden yönlendirin

Çalışan bir Tor istemcisi (Tor Browser değil, Tor daemon'u), varsayılan olarak 127.0.0.1:9050 adresinde yerel bir SOCKS5 proxy sunar. SOCKS destekli herhangi bir uygulama buna yönlendirilebilir, ancak SSH'ın kendisi doğal olarak SOCKS konuşmaz, bu yüzden küçük bir köprüye ihtiyacınız var. İki yaygın yaklaşım, bir komutu sarmalayan ve TCP bağlantılarını proxy üzerinden zorlayan torsocks, ile bağlantıyı SOCKS destekli bir netcat üzerinden ileten SSH yapılandırmanızdaki bir ProxyCommand girişidir.

En hızlı test basitçe şudur: tor'u kurun, çalıştığını doğrulayın, ardından torsocks ssh user@vps-ip-adresiniz çalıştırın. Bağlanırsa, SSH oturumunuz artık üç sıçramalı bir Tor devresi üzerinden yönlendiriliyor demektir. Her gün kullanacağınız bir şey için, her seferinde torsocks yazmak yerine ~/.ssh/config'e bir Host bloğu ekleyin; nc -X 5 -x 127.0.0.1:9050 %h %p (OpenBSD netcat ile) veya connect -S 127.0.0.1:9050 %h %p (connect-proxy aracıyla) gibi bir ProxyCommand satırı kullanın. Bu şekilde sade bir ssh myhost komutu çalışır ve sarmalayıcıyı hatırlamak zorunda kalmadan her zaman Tor üzerinden geçer.

SSH'ın kendisini sorun gidermeden önce Tor'un gerçekten çalıştığını ve 9050'yi dinlediğini doğrulayın
torsocks ssh user@host test etmenin en hızlı yolu; ~/.ssh/config'de bir ProxyCommand ise gün be gün kullanmanın kalıcı yoludur
Bu yöntem IP'nizi VPS'ten ve kimlik doğrulama günlüklerini okuyan herkesten gizler, ancak SSH portunun kendisi hâlâ herkese açık internete açıktır

Yöntem 2: SSH'ı VPS'te bir Tor onion hizmeti olarak yayınlayın

Amaç, yönetici erişimi için VPS'in kendi IP adresini tamamen resmin dışında tutmaksa, sunucunun Tor çalıştırması ve sshd'yi yalnızca gizli bir hizmet olarak sunması gerekir. VPS'e tor'u kurun, ardından torrc'ye iki satır ekleyin: Tor'un yazabileceği bir dizini gösteren HiddenServiceDir ve onion adresinin 22 numaralı portuna gelen bağlantıları yerel olarak dinleyen sshd'ye yönlendirmesini Tor'a söyleyen HiddenServicePort 22 127.0.0.1:22. Tor'u yeniden başlatın; ilk çalıştığında bu dizinde uzun rastgele bir .onion ana bilgisayar adı üretecektir.

Kritik olarak, bu adım, sshd'ye de VPS'in herkese açık arayüzü yerine 127.0.0.1'e bağlanması söylenmediği sürece (sshd_config'de ListenAddress 127.0.0.1, ardından sshd'yi yeniden başlatın) maruziyeti ortadan kaldırmaz. Bu adımı atlamak, SSH'ı hem onion adresi üzerinden hem de doğrudan herkese açık IP üzerinden erişilebilir bırakır, ki bu da amacı boşa çıkarır. Bu yapıldıktan sonra, istemci tarafında torsocks ssh user@uzunanadınız.onion ile bağlanın — VPS'in bir port taramasında SSH için hiçbir herkese açık IPv4 veya IPv6 adresi hiç görünmez.

torrc'ye HiddenServiceDir ve HiddenServicePort 22 127.0.0.1:22 ekleyin, ardından Tor'u yeniden başlatın
sshd'nin kendisini yalnızca 127.0.0.1'e bağlayın — hâlâ herkese açık bir portun önündeki bir onion hizmeti hiçbir şeyi gizlemez
Bağlanılacak .onion adresini almak için HiddenServiceDir içindeki üretilen hostname dosyasını okuyun
torsocks ssh [email protected] ile bağlanın; SSH için sade bir IP artık hiç işe yaramaz

SSH sadece .onion üzerinden yanıt verdiğinde kimlik doğrulamayı kilitlemek

Portu gizlemek, girişi sertleştirmenin yerini tutmaz. ed25519 anahtar çiftleri kullanın, şifre kimlik doğrulamasını tamamen devre dışı bırakın (PasswordAuthentication no) ve SSH üzerinden root girişini devre dışı bırakın (PermitRootLogin no). Bu VPS'e ulaşmak için kullandığınız anahtar, günlük hesaplarınız için kullandığınız anahtarla aynıysa, onion hizmetinin kazandırdığı anonimlik, o anahtarın parmak izinin bir ihlal dökümünde veya başka bir yerde adınıza bağlı bir Shodan/Censys taramasında ortaya çıktığı anda baltalanmış olur — anonim altyapı için özel bir anahtar üretin.

Bu kurulumda sessizce çalışmayı bırakan bir şey var: IP tabanlı araçlar, örneğin fail2ban. Bağlantılar sshd'ye yerel Tor süreci üzerinden geldiği için, sshd'nin günlüklediği kaynak adres başarılı olsun olmasın her tek giriş denemesi için 127.0.0.1'dir — yasaklanacak bir saldırgan IP'si yoktur. Bu, bir geçici çözümle doldurmanız gereken bir boşluk değildir; şifre yedeği olmayan yalnızca-anahtar kimlik doğrulaması, fail2ban'ın hafifletmek için var olduğu kaba kuvvet riskini zaten ortadan kaldırır. Sadece bu yapılandırmada günlüklerinin anlamlı olmasını beklemeyin.

Yalnızca anahtarla kimlik doğrulama, ed25519, şifre yedeği yok
Anonim sunucu başına ayrılmış bir anahtar çifti, hiçbir zaman kişisel bir makineden tekrar kullanılmasın
PermitRootLogin no, ve gerçek iş için sudo yetkili root olmayan bir hesap
Trafik Tor üzerinden geldikten sonra fail2ban veya IP izin listesine güvenmeyin — günlüklerdeki kaynak IP her zaman loopback'tir

Performans gerçekte nasıl görünür

Standart bir Tor devresi üç relay içerir ve bir onion-hizmeti bağlantısı uçtan uca iki üç sıçramalı devreyi üst üste bindirir (biri istemciden Tor ağına, diğeri Tor ağından gizli hizmete), bu yüzden gidiş-dönüş gecikmesi yaygın olarak birkaç yüz milisaniye ile birkaç saniye arasında bir yere düşer; devre yeniden kurulduğunda arada bir sıçramalar olur. Etkileşimli çalışma — yapılandırma dosyalarını düzenlemek, günlükleri kontrol etmek, bir hizmeti yeniden başlatmak — bu gecikmede tamamen kullanılabilir. Boşta kalan oturumların ekstra sıçrama nedeniyle düşürülmemesi için SSH yapılandırmanızda ServerAliveInterval'i ayarlayın ve Tor yeni bir devre seçerken arada bir duraklama bekleyin.

İyi çalışmayan şey verim (throughput). scp, rsync veya gigabaytları hareket ettiren herhangi bir şey, doğrudan bir bağlantıya kıyasla sürünecektir, çünkü Tor devreleri sürdürülen bant genişliği için değil, birçok kısa ömürlü akış boyunca düşük gecikmeli etkileşim için optimize edilmiştir. Gerçek veri aktarımı için — yedeklemeler, büyük yüklemeler — doğrudan şifreli bir kanal kullanın (herkese açık IP üzerinden düz SSH/rsync veya bir WireGuard tüneli) ve Tor yolunu özellikle bağlantıyı gizlemenin hızdan daha önemli olduğu yönetici kabuk erişimi için ayırın.

Elde etmeye çalıştığınız anonimliği sessizce bozan hatalar

Buradaki çoğu başarısızlık egzotik değildir — bir yan kapıyı açık bırakan küçük yapılandırma boşluklarıdır. Kuruluma güvenmeden önce şunlara dikkat edin:

Bunların hiçbiri kaçınmak için ileri düzey araçlar gerektirmez; sadece Tor yapılandırmasının tek başına işi yaptığını varsaymak yerine, gerçek dinlenen portları ve DNS davranışını bir kez kontrol etmenizi gerektirirler.

sshd'nin onion hizmetinin yanı sıra hâlâ herkese açık arayüze bağlı olması; böylece 'gizli' port da düz bir port taramasıyla bulunabilir hale gelir
Ana bilgisayar adlarını Tor dışında çözümlemek (başıboş bir DNS sorgusu veya DNS için SOCKS proxy'sini görmezden gelen bir uygulama), Tor bağlantısı başlamadan önce hangi ana bilgisayara bağlanmak üzere olduğunuzu sızdırır
Tor çalışmıyorsa sessizce doğrudan bir bağlantıya geri düşen bir ProxyCommand — kapalı-yönde başarısız olacak şekilde yapılandırın, açık-yönde değil; böylece ölü bir Tor daemon'u yanlışlıkla bir clearnet bağlantısı değil, hiç bağlantı olmaması anlamına gelir
Bu oturumu başka bir yerdeki anonim olmayan bir kimliğe bağlayan bir SSH anahtarını, terminal istemini veya kabuk geçmişini tekrar kullanmak

SSH erişim yöntemleri karşılaştırması
Yöntem	Neyi gizler	Tipik ek gecikme	Kurulum çabası
Clearnet üzerinden doğrudan SSH	SSH'ın kendi şifrelemesinin ötesinde hiçbir şey	Yok	Yok
Tor'un SOCKS proxy'si üzerinden yönlendirilen istemci	IP adresiniz, sunucudan ve günlüklerinden	Orta — kabaca bir Tor devresi, ~300ms-1sn	Düşük — torsocks veya bir ProxyCommand satırı
Tor onion hizmeti olarak yayınlanan SSH	VPS'in herkese açık IP'si; internette açık SSH portu yok	Orta ile yüksek arası — sunucu tarafında ek devre	Orta — torrc ve sshd_config değişiklikleri
İkisi birlikte: istemci Tor üzerinden, sunucu onion hizmeti olarak	Bağlantının her iki ucu da tamamen clearnet'in dışında kalır	En yüksek — iki bağımsız 3 sıçramalı devre	Orta

SSS

Tor üzerinden SSH, SSH'ın şifrelemesini zayıflatır mı?+

Hayır. SSH, kendi uçtan uca şifreli kanalını taşıyan taşıma yönteminden bağımsız olarak müzakere eder. Tor bunun üzerine kendi devre şifreleme katmanını ekler, bu yüzden trafik daha zayıf bir şeyle bir kez değil, iki kez şifrelenmiş olur.

Tor üzerinden SSH gerçek yönetim işi için çok mu yavaş?+

Etkileşimli kabuk oturumları için — dosyaları düzenlemek, günlükleri kontrol etmek, hizmetleri yeniden başlatmak — ek gecikme fark edilir ama yönetilebilir. Yedeklemeler veya büyük yüklemeler gibi toplu aktarımlar için bunun yerine doğrudan veya WireGuard bağlantısı kullanın ve Tor yolunu yönetici erişimi için ayırın.

SSH yalnızca bir onion hizmeti üzerinden erişilebilirse yine de fail2ban kullanabilir miyim?+

Anlamlı bir şekilde hayır. Bağlantılar sshd'ye Tor'un yerel sürecinden geldiği için, her giriş denemesi 127.0.0.1'den geliyormuş gibi günlüklenir. Bunun yerine şifre yedeği olmayan yalnızca-anahtar kimlik doğrulamasına güvenin, çünkü bu fail2ban'ın ele almayı amaçladığı kaba kuvvet riskini ortadan kaldırır.

VPS erişimi için Tor'a ek olarak bir VPN'e de ihtiyacım var mı?+

Genellikle hayır. Tor'un önüne ticari bir VPN zincirlemek, bu kullanım durumu için gerçek bir koruma eklemeden büyük ölçüde güveni VPN sağlayıcısına taşır. SSH oturumu için tek başına Tor, veya gecikme Tor'un ağı üzerinden yönlendirmekten daha önemliyse bir WireGuard tüneli, pratik durumları kapsar.

Her iki ucun da Tor çalıştırması mı gerekiyor, yoksa sadece dizüstü bilgisayarım mı?+

Kendi IP'nizi sunucudan gizlemek için sadece istemcinizin Tor çalıştırması gerekir (Yöntem 1). Sunucunun IP'sini de gizlemek, VPS'in de sshd bir onion hizmeti olarak yayınlanmış şekilde Tor çalıştırmasını gerektirir (Yöntem 2) — iki kurulum birbirinden bağımsızdır ve ayrı ayrı veya birlikte kullanılabilir.

Offshore'a geçmeye hazır mısınız?

KYC yok, e-posta yok — sadece anonim bir anahtar ve kripto. ~55 saniyede dağıtın.

VPS'inizi yapılandırın →