Sunucudan localhost’a SSH Tunneling (Güvenli Erişim Rehberi)

SSH tunneling, bir sunucunun içindeki (genelde güvenlik duvarı tarafından kısıtlanan) servislere, kendi bilgisayarınızdaki localhost üzerinden erişmenizi sağlayan en pratik yöntemlerden biridir. Doğru kurulduğunda trafikte şifreleme korunur ve bağlantı hedefe yalnızca SSH kanalı üzerinden gider.

Bu rehberde, “sunucudan localhost’a” mantığını netleştirip local ve remote port yönlendirme farklarını, en sık kullanılan SSH komutlarını, güvenlik ayarlarını ve canlı test yöntemlerini adım adım ele alacaksınız.

SSH tunneling neyi çözer?

Birçok senaryoda servis doğrudan internete açılmaz: - Uygulama sadece sunucunun kendi ağında (private network) erişilebilir durumdadır. - MySQL/PostgreSQL, admin panel ya da dahili API yalnızca 127.0.0.1 veya özel interface’te dinler. - Sunucuda bir port açmak yerine güvenli bir “tünel” ile kontrollü erişim yapılır.

SSH tunnel, bu servisleri internete açmadan, trafiği SSH bağlantısı içinde kapsüller. Sonuç: istemci (senin bilgisayarın) servisle sanki localhost’ta varmış gibi konuşur.

Temel kavramlar: Local forward vs Remote forward

SSH’de iki ana yönlendirme yaklaşımı vardır. Karışıklığı en aza indirmek için şu ayrımı net tutalım:

• Local forward (yerelden uzak servise): -L
• Senin bilgisayarında (localhost) bir port açılır.
• SSH, bu porttan gelen trafiği sunucu tarafında belirlenen hedefe iletir.
• Remote forward (uzaktan, senin localhost’unu hedef alan): -R
• Sunucu tarafında bir port açılır.
• SSH, sunucuya gelen trafiği senin bilgisayarındaki localhost’a iletir.

Başlık “sunucudan localhost’a tunneling” dediği için çoğu kullanıcı -R ile ne yaptığını arar. Ancak pratikte senaryoya göre -L de en doğru çözüm olur.

Hangi durumda -R seçilir?

• Sunucudan (remote) belirli bir servise erişim sağlayan taraf senin localhost’un olmalı.
• Sunucuda bir sistem (ör. bir test aracı, bir worker veya reverse proxy) senin laptop’ında çalıştırdığın bir servise bağlanmak zorunda.
• Senin localhost’un internetten doğrudan erişilebilir değildir; ama SSH üzerinden erişilebilir hale getirmek istersin.

Hangi durumda -L seçilir?

• Senin localhost’undan sunucu içindeki servise gitmek istiyorsun.
• Sunucuda internal bir panel veya veritabanı yalnızca sunucu içinde erişilebilir.

En sık kullanılan komutlar

Aşağıdaki örneklerde varsayılan hedefleme mantığını kuralım: - SSH kullanıcı adı: user - SSH sunucusu: server.example.com - SSH port: 22

1) -L ile: Sunucu içi servisi kendi localhost’unda görmek

Örnek: Sunucuda 127.0.0.1:3306 (MySQL) sadece localhost’tadır. Sen kendi bilgisayarından localhost:13306 üzerinden bağlanmak istiyorsun.

ssh -N -L 13306:127.0.0.1:3306 [email protected]

• Sen localhost:13306’ya bağlanırsın.
• SSH, sunucuda 127.0.0.1:3306’a yönlendirir.
• -N: Uzak tarafta komut çalıştırma.

Test: - mysql -h 127.0.0.1 -P 13306 -u ... -p

2) -R ile: Sunucudan kendi localhost’una erişim

Örnek: Sunucuda port dinleyen bir bileşen var; o bileşen senin laptop’ındaki localhost:5000 servisine ulaşsın istiyorsun.

ssh -N -R 5000:127.0.0.1:5000 [email protected]

• Sunucu tarafı localhost:5000 (veya dinlenme şekline göre tüm interface) üzerinden bağlantıları SSH tüneline gönderir.
• Tünel bu trafiği senin lokal 127.0.0.1:5000 servisine taşır.

Not: -R tarafında sunucuda hangi interface’in dinleneceği kritik olabilir. Varsayılan davranış ve SSH sunucusu ayarları (özellikle GatewayPorts) sonucu etkiler.

3) Güvenlik için bağlama adresini netleştirme

-L tarafında çoğu zaman 127.0.0.1 hedeflemesi en güvenlisi: - Sunucu hedefini 127.0.0.1 yap: sadece sunucunun kendi lokalinde dinleyen servislere gider.

-R tarafında ise sunucunun dinleme alanı önemli: - Sunucunun tünel portunu internetten erişilebilir yapma. - SSH sunucusunda GatewayPorts ayarı ve -R ile “bind address” parametresi belirleyici olur.

Güvenlik: tüneli “açık kapı” yapmamak

SSH tunnel kurmak bağlantıyı şifreler; ama yönlendirme yanlış yapılırsa tünel istenmeden dışarıya taşabilir.

Aşağıdaki kontrol listesi karar verirken işinize yarar.

Kontrol listesi (net)

1. Kilitli servis hedefi: - -L kullanıyorsanız hedefi 127.0.0.1 yapın.
2. Tünel portunu erişime kapalı seçin: - -R ile sunucu tarafında bind’in herkese açık olmamasını sağlayın.
3. SSH anahtarı (key) kullanın: - Şifreli login yerine anahtar ile erişim standardı netleştirin.
4. İzin verilen kullanıcı/komut kısıtlaması: - Mümkünse SSH kullanıcı hesabını sadece gerekli yetkilerle sınırlandırın.
5. Tüneli kısa süreli kullanın: - Otomatik ve kalıcı “açık tünel” yerine ihtiyaç oldukça başlatın.
6. Log ve denetim: - Sunucu SSH loglarında (ör. auth.log) deneme ve bağlantıları takip edin.

GatewayPorts etkisi (kısa ama kritik)

• -R ile açılan tünel portunun sunucuda hangi interface’e bağlanacağı SSH sunucu ayarıyla değişebilir.
• GatewayPorts değeri “remote forward” portlarının her yerden erişilebilir olup olmayacağını etkiler.

Net sonuç: -R kullanıyorsanız, “tünel portu sunucuda sadece localhost’tan mı erişiliyor?” sorusunu test etmeden açık bırakmayın.

Doğru port seçimi ve çakışma yönetimi

Tünel portları iki tarafta çakışabilir: - Senin localhost’unda zaten bir servis çalışıyorsa (ör. 5000 kullanıyorsan), -L denemesi başarısız olur. - Sunucuda -R ile açtığın port başka bir uygulama tarafından kullanılıyorsa hata alırsın.

Pratik port stratejisi

• Local tarafta çakışmasın diye yüksek ve genelde boş port aralığı kullanın (ör. 12000-20000).
• Sunucu tarafında -R açacaksan, gerçekten kullanılmayan bir port seç.

Çalıştığını nasıl anlarsın? (test adımları)

Bağlantı kurulduktan sonra “tünel gerçekten gidiyor mu?” sorusu genelde 2 yöntemle cevaplanır.

1) Dinleme portunu doğrula

Yeni bir terminal açıp şunu kontrol edin: - Linux/macOS: - lsof -iTCP:13306 -sTCP:LISTEN - Windows (PowerShell): - netstat -ano | findstr :13306

2) Uygulama katmanında doğrula

• Veritabanı ise:
• mysql veya psql client ile tünel portunu hedefle.
• HTTP servis ise:
• curl http://127.0.0.1:port/ ile kontrol et.

Ek güvenlik adımı: - curl http://localhost:port ile dene; ardından istersen farklı bağlama denemeleriyle (ör. sunucu üzerinden) “yalnızca istenen taraftan” erişiliyor mu kontrol et.

Yaygın senaryolar: “internete açık değil ama erişeyim”

Aşağıdaki tablo karar vermeyi kolaylaştırır.

Tüneli kalıcı kılma yerine kontrollü kullanma

Tünel için en doğru operasyon modeli “gerektiğinde aç, iş bitince kapat”tır.

Tüneli arka planda başlatma

Basit yöntem: - -f (background) - -o ServerAliveInterval=... ile kopmaları azaltma

Örnek (local forward):

ssh -f -N -L 13306:127.0.0.1:3306 \
  -o ServerAliveInterval=30 \
  [email protected]

Tüneli kapatma: - background process ID’yi bulup sonlandır veya kullandığın portu kapatan SSH oturumunu kapat.

Kopma/timeout önleme

• SSH oturumu uzun süre boşta kalırsa bazı sağlayıcılarda bağlantı kesilebilir.
• ServerAliveInterval ve gerekirse ServerAliveCountMax değerleri bu tür kopmaları azaltır.

Güvenlikte son hedef: tüneli kesin ve dar kapsamlı tut

SSH tunneling’i güçlü yapan şey “tek bir kanalla kontrollü erişim”tir. O yüzden kapsamı küçültün.

• -L ile sadece gereken port aralığını açın; tüm portları açmayın.
• -R ile sunucu bind’ini internete açmayın; mümkünse localhost ile sınırlı kalmasını sağlayın.
• Sunucu tarafında tünel üzerinden ulaşılabilecek uygulamanın kimlik doğrulamasını (login) kapatmayın.

Sonuç: İlk denemeyi -L ile yap, -R için bind’i test et

Önce en sık senaryodan başlayın: Sunucuda internal servislere erişmek istiyorsanız -L ile kendi localhost’unuzda port açın; hedefi 127.0.0.1 tutarak kapsamı daraltın. “Sunucudan localhost’a” ihtiyacı baskınsa -R kullanın ama özellikle GatewayPorts etkisini ve sunucudaki bind davranışını doğrulayarak tüneli internete açık hale getirmeyin.

Bir sonraki adım olarak, önce tek bir servis (ör. sadece HTTP veya sadece MySQL) seçin; tüneli açın, curl veya veritabanı client ile doğrulayın, sonra iş bitince kapatın. Bu sıra hem güvenlik hem de troubleshooting açısından en net sonuç verir.