SSH Tunneling ile Sunucudan Localhost’a Güvenli Erişim Rehberi

Bir VDS/VPS/Dedicated sunucudan kendi bilgisayarınızdaki localhost hizmetine erişmeniz gerektiğinde klasik yöntemler (port açma, yönlendirme) hem risklidir hem de her zaman mümkün değildir. SSH tunnel (tünel) ise trafiği şifreleyerek uzak sunucudan yereldeki porta güvenli bir yol oluşturur. Bu rehberde; "sunucu localhost’uma nasıl bağlanır?" sorusunun net, uygulanabilir cevabını; port planlaması, güvenlik kontrolleri ve doğrulama testleriyle birlikte anlatacağız.

SSH Tunneling Ne Sağlar? (Neden localhost erişimi için tercih edilir?)

SSH tunneling, SSH bağlantısı üzerinden belirli bir port trafiğini başka bir noktaya taşıyabilir. En pratik senaryo şudur:

• Sizde bir servis çalışır: http://localhost:3000 veya localhost:5432
• Uzak sunucuda (VDS/VPS) bunun doğrudan ağ erişimi yoktur
• SSH ile tünel kurarsınız: Uzak sunucunun bir portu, sizin yerel servisinizin yanıtlarını getirir

Bu sayede: - Yerel makinenizde port açmadan (veya sadece SSH portunu açık tutarak) erişim sağlanır - Trafik şifrelenir (üstelik uygulama katmanı genelde internete hiç çıkmaz) - Güvenlik duvarı (firewall) ve yönlendirme karmaşası azalır

İki temel mod: Local forward ve Remote forward

Genelde iki yaklaşım karşınıza çıkar:

1. Local forwarding (ssh -L): Uzak sunucu değil, sizin lokal makinenizden gelen isteklerin uzak tarafta başka porta taşınması.
2. Remote forwarding (ssh -R): Uzak sunucuda açılan portun, sizin lokalinizdeki porta bağlanması.

"Uzak sunucudan localhost’a erişmek" hedefinde çoğu zaman -R (remote forward) doğru seçimdir. Ancak bazı mimarilerde -L daha mantıklı olabilir; bu rehberde iki yaklaşımın farkını somut örneklerle anlatacağız.

Kurulum Öncesi Net Kontrol Listesi

Tunnel kurmadan önce şu maddeleri netleştirin. Bu kontroller olmadan kurulum "çalışmıyor" hissine dönüşür.

1) Uzak sunucuda SSH erişimi ve yetki

• Uzak sunucuda SSH erişiminiz olmalı
• Kullanıcı hesabınızın ssh komutunu çalıştırması yeterli olmalı
• Eğer SSH anahtarı (key) kullanıyorsanız, anahtarınız uzak sunucuda ekli olmalı (~/.ssh/authorized_keys)

2) Yerel (localhost) servisin gerçekten ayağa kalktığından emin olun

Örnek: Yerelde web uygulamanız localhost:3000 dinliyorsa: - http://localhost:3000 adresi kendi makinenizde tarayıcıyla yanıt vermeli - Servis 127.0.0.1 veya ::1 üzerinde dinliyor olmalı (varsayılan çoğu geliştirme sunucusunda budur)

3) SSH sunucusunda GatewayPorts ve AllowTcpForwarding

Tünelin nasıl görünür olacağını belirler. - Uzak sunucunun SSH daemon ayarlarında AllowTcpForwarding genellikle yes olmalı - GatewayPorts ayarı remote forward için kritik olabilir

Uzak sunucuda yönetici değilseniz bu ayarları değiştiremeyebilirsiniz. Bu durumda alternatif yaklaşım olarak yerelde -L ile gidiş-geliş yapılır.

Senaryo A: Uzak sunucudan sizin localhost’unuza erişim (Remote forward -R)

Bu senaryoda amaç: - Siz lokal makinenizde localhost:3000 çalıştırıyorsunuz - Uzak sunucuda bir port açıyorsunuz (örnek 127.0.0.1:9001) - Uzak sunucu üzerinden http://127.0.0.1:9001 çağrıldığında istek lokal makinenizdeki localhost:3000 servisine gider

Komut şablonu

Yerel makinenizde (kendi bilgisayarınız) şu mantıkla çalışırsınız:

ssh -N -R 127.0.0.1:9001:127.0.0.1:3000 user@VDS_IP

Komutun parçaları: - -N: komut çalıştırma, sadece tünel aç - -R [bind_address:]remote_port:local_host:local_port - 127.0.0.1:9001: Uzak sunucuda sadece loopback üzerinden erişilebilir kısım - 127.0.0.1:3000: Yerel makinenizdeki hedef servis

Uzak sunucuda test

Uzak sunucuya SSH ile bağlanıp test edin:

• Aynı makinede çalışan tünel portu:
• curl http://127.0.0.1:9001 (web ise HTML döner)

Burada kritik nokta: 127.0.0.1 kullandığınızda tünel sadece sunucunun kendi içinde erişilebilir olur. Böylece internetten rastgele erişim riski düşer.

Güvenlik notu: Neden 0.0.0.0 yerine 127.0.0.1?

-R 0.0.0.0:9001:... gibi bir kullanım, tünel portunu sunucunun dış arayüzlerine açabilir. Bu çoğu durumda istenmez.

Net yaklaşım: - Önce 127.0.0.1 ile açın - Gerekirse kontrollü şekilde açın

Senaryo B: Yerelde erişim, uygulamayı uzak sunucuda test etme (Local forward -L)

Bazı ekiplerde şu hedef olur: - Siz uzak sunucuda geliştirme/test yapıyorsunuz - Uzak sunucudaki komutlar lokal servisle konuşmalı

Bu senaryoda çoğu zaman -L ile tünel açmak daha pratik olur. Mantık tersine döner: - Yerelde bir port açarsınız - Uzak sunucu üzerinden bu portu kullanmak için ayrıca bir yaklaşım gerekebilir (ör. SSH üzerinden ikinci adım)

En temel -L şablonu:

ssh -N -L 9001:127.0.0.1:3000 user@VDS_IP

Bu komut: - Yerel makinenizde localhost:9001 üzerinden gelen isteği - Uzak SSH sunucusu üzerinden değil, tünelin karşı ucuyla yerel hedefe bağlar

Bu yüzden "tek bir komutla" uzak sunucunun doğrudan yerel servise ulaşması için genelde -R daha doğrudur. Ancak ortamlar farklıysa -L de kullanılabilir. Karar verirken şu soruyu net sorun: - Tüneli kimin oluşturması gerekiyor? (yerel mi uzak mı) - Ulaşım hangi yönde? (uzak sunucu → yerel mi, yerel → uzak mı)

Port planlama: Çakışma ve dinleme davranışı

Tunnel komutlarında port seçimi sık hata kaynağıdır.

Hedef portu çakıştırmayın

• Yerelde servis portunuz 3000
• Uzak sunucuda tünel portunuz 9001 gibi ayrı bir sayı olmalı
• Hem yerelde hem uzakta çalışan servisler ile çakışmamalı

Port kontrolü komutları

• Yerelde:
• ss -lntp | grep 3000
• Uzak sunucuda:
• ss -lntp | grep 9001

SSH Tünelini Arka Planda Çalıştırma

ssh -N komutu terminali kilitler. Süreklilik gerekiyorsa arka planda çalıştırmak gerekir.

Basit arka plan

ssh -N -R 127.0.0.1:9001:127.0.0.1:3000 user@VDS_IP &

Doğrulanabilir yöntem: autossh

Sürekli tünel gereksiniminde yeniden bağlanmayı otomatikleştiren araçlar tercih edilir. autossh, bağlantı kopunca tüneli toparlar. Kurulum dağıtıma göre değişir; hedef her zaman şudur: - Tünel kesilince manuel iş bırakmamak

Net kullanım hedefi, tüneli "gün içinde bozulup sonra unutma" durumundan kurtarmaktır.

Doğrulama ve Hata Ayıklama (Çalışmıyor ise)

Aşağıdaki testler, tünelin hangi katmanda kırıldığını anlamanıza yardımcı olur.

1) SSH bağlantısı hatasız mı?

Önce basit doğrulama yapın: - ssh user@VDS_IP ile oturum açın - Sonra tüneli ekleyin

2) Uzak sunucuda port dinliyor mu?

Tünel açıldıktan sonra uzak sunucuda: - ss -lntp | grep 9001

Dinleme yoksa: - SSH daemon ayarları (örn. AllowTcpForwarding) kısıtlıyor olabilir - Komut satırında yanlış hedef var olabilir

3) Yerel servis gerçekten yanıt veriyor mu?

Yerelde: - curl http://127.0.0.1:3000 (web servis ise) - psql gibi protokollerde uygun istemci ile test

4) Firewall engelliyor mu?

Genelde 127.0.0.1 bağlaması firewall ihtiyacını azaltır ama yine de: - Uzak sunucuda güvenlik grupları (SG) veya OS firewall kuralı loopback dışına taşan senaryolarda devreye girebilir

5) Sunucu SSH ayarı: GatewayPorts

Şu hedef var: - Tüneli sadece loopback ile tutmak Bu yüzden çoğu örnekte 127.0.0.1 özellikle kullanıldı.

Veri tabanı gibi servislerde dikkat: TCP davranışı ve kimlik doğrulama

Web servisleri tünelle genellikle sorunsuz çalışır. Ama veritabanı (MySQL/PostgreSQL) gibi servislerde ekstra noktalar vardır.

Örnek: Yerel PostgreSQL ile uzak sunucudan bağlanma

Yerelde PostgreSQL localhost:5432 dinliyorsa:

• Tünel:

ssh -N -R 127.0.0.1:15432:127.0.0.1:5432 user@VDS_IP

• Uzak sunucuda psql ile bağlantı:
• psql -h 127.0.0.1 -p 15432 -U dbuser dbname

Burada kritik olan: - PostgreSQL kullanıcınızın yetkileri - pg_hba.conf ayarlarının kimlik doğrulama politikasını bozup bozmadığı

Sık yapılan 7 hata ve net düzeltme

1. Yanlış yön (L yerine R kullanmak): Hedef "uzak → yerel" ise -R tercih edin.
2. Port çakışması: Uzak ve yerel portları birbirinden farklı seçin.
3. Servis localhost yerine başka arayüzde dinlemiyor: Yerelde 127.0.0.1 dinliyorsa tünelde aynı IP’yi hedefleyin.
4. 0.0.0.0 ile açıp herkese maruz kalmak: Varsayılan olarak 127.0.0.1 kullanın.
5. SSH daemon kısıtları: AllowTcpForwarding kapalı olabilir; kontrol edin.
6. Hedef portu yanlış yazmak: Komutta local_port ve remote_port yerlerini karıştırmayın.
7. Tünel açıldı sanıp doğrulamayı atlamak: Uzak sunucuda ss ve curl/istemci testiyle portun gerçekten aktif olduğunu görün.

Hızlı karar tablosu: Hangi tünel tipi ne zaman?

Sonuç: İlk denemeyi doğru kurun, sonra kilitleyin

Önce en basit hedefi belirleyin: "Uzak sunucu mu yerel servise ulaşacak?" Bu sorunun cevabına göre -R veya -L seçin. Sonra tüneli loopback (127.0.0.1) üzerinden açın, port çakışmasını giderin ve uzak sunucuda ss ile dinleme olup olmadığını doğrulayın. Kurulum çalıştıktan sonra tüneli arka plana alın (gerekirse autossh) ve sadece test süresi kadar açık tutun.

İlk adım olarak, yerel bir web servisi (ör. localhost:3000) ile yukarıdaki -R örneğini uygulayıp uzak sunucuda curl http://127.0.0.1:9001 sonucunu görün. Bu doğrulama geçmeden veritabanı gibi daha kritik servisleri tünelle bağlamayın.