Sunucudan Localhost"a SSH Tunneling: Net Uygulama Rehberi

SSH tunneling (tünelleme), yerel bilgisayarınızın (localhost) erişemediği bir servise sunucu üzerinden güvenli bir yol açmanızı sağlar. Özellikle web uygulamaları, veritabanları veya dahili servisler yalnızca sunucu iç ağında kalıyorsa bu yöntem zaman kazandırır. Bu rehberde hem hangi senaryolarda SSH local port forward ve SSH remote port forward kullanacağınızı netleştirecek, hem de kopyala-uygula komutları ve hata teşhis adımlarını vereceğiz.

Tarih: 02.10.2026

SSH tunneling neyi çözer?

SSH tünelinin temel amacı, trafiği sunucunun SSH şifresi üzerinden taşıyarak iki ağ arasındaki erişim kısıtlarını aşmaktır. En sık senaryolar:

• Uygulama DB"si (MySQL/PostgreSQL) sadece sunucuya bağlıdır, yerelden direkt erişim yoktur.
• Geliştirme/analiz araçları yerelde çalışır ama hedef servis yalnızca sunucudan görülür.
• Cloud ortamında portlar dışarı kapalıdır; sadece SSH erişimi vardır.

SSH tunelinin avantajı, ek VPN kurmadan hızlı bir bağlantı sağlaması ve trafiği şifrelemesidir. Risk tarafında ise doğru yetkilendirme ve doğru bağlama adresi (bind) seçimi şarttır.

Senaryo seçimi: local forward mı remote forward mı?

Tünellemenin yönü, bağlantıyı kim başlatıyor sorusuyla belirlenir.

Senaryo A: Localhost"tan sunucu iç servise erişmek (SSH local port forward)

• Siz yerelde localhost:port üzerinden bağlantı yaparsınız.
• SSH, bu bağlantıyı sunucu tarafındaki hedef_host:hedef_port"a iletir.

Bu en yaygın modeldir.

Senaryo B: Sunucu dışından localhost"a erişmek (SSH remote port forward)

• Siz yerelde bir servis çalıştırırsınız (ör. localhost:5000).
• Sunucu, dışarıdaki bir porttan gelen trafiği sizin yerel servisinize iletir.
• İnbound taraf genellikle daha dikkat ister; güvenlik ve bind ayarları kritik olur.

Aşağıdaki tabloda ikisini pratik şekilde özetleyelim:

Yerelde servis erişimi için: SSH -L ile tunneling (kopyala-uygula)

Diyelim ki SSH erişiminiz olan bir VDS/VPS var. Sunucu üzerinde DB sadece 127.0.0.1 veya sunucu iç ağında çalışıyor ve dışarı açık değil.

Örnek 1: Sunucudaki MySQL/PostgreSQL"e yerelden bağlanma

Varsayımlar: - SSH kullanıcı adınız: user - SSH hostunuz: 203.0.113.10 - Sunucu üzerindeki DB: 127.0.0.1:5432 (PostgreSQL) - Siz yerelde localhost:15432 üzerinden bağlanmak istiyorsunuz.

Komut:

ssh -N -L 15432:127.0.0.1:5432 [email protected]

Sonra yerel bilgisayarınızda DB client"ta: - Host: 127.0.0.1 (veya localhost) - Port: 15432 - Kullanıcı/şifre: (sunucu DB kimlik bilgileri)

Örnek 2: Sunucudaki bir HTTP servise erişim

Varsayımlar: - Sunucuda uygulama 127.0.0.1:8080 dinliyor - Siz yerelde localhost:18080 üzerinden test etmek istiyorsunuz

Komut:

ssh -N -L 18080:127.0.0.1:8080 [email protected]

Tarayıcıdan http://localhost:18080 şeklinde erişirsiniz.

-N ve SSH seçenekleri ne işe yarar?

• -N: Komut çalıştırmaz, sadece tünel açık kalır.
• -f: Arka plana alır (her zaman şart değil).
• -p: SSH portunuz farklıysa kullanılır (varsayılan 22 değildir).
• -v / -vv: Sorun teşhisinde detay için kullanılır.

Örnek arka plan kullanımı (aynı port çakışmalarını kontrol ederek):

ssh -f -N -L 15432:127.0.0.1:5432 -p 22 [email protected]

Sunucudan yerel servise erişim: SSH -R (daha dikkatli)

Remote forward senaryosunda, sunucu tarafında bir port açarsınız ve gelen istekler yerel bilgisayarınızın belirli portuna gider.

Örnek: Sunucudaki portu yerelde çalışan web arayüzüne bağlama

Varsayımlar: - Yerelde bir servis var: localhost:3000 - Sunucu tarafında dinletmek istediğiniz port: 9000

Komut:

ssh -N -R 9000:127.0.0.1:3000 [email protected]

Not: Sunucu tarafının bu portu dışarıya açık hale getirip getirmediğini ayrıca değerlendirmeniz gerekir. Ayrıca, -R kullanırken uzaktan erişim riskini azaltmak için SSH sunucusunun config"inde (ör. GatewayPorts) ayarlar belirleyici olabilir.

Bağlantı kurulumunda pratik doğrulamalar

Tünel komutu çalışıyor gibi görünse bile hedef servis/port doğru değilse bağlantı kuramazsınız. Bu yüzden şu kontrol listesini uygulayın.

Kontrol listesi (hızlı teşhis)

• Yerelde bağlanmaya çalıştığınız localhost:port başka bir program tarafından kullanılmıyor.
• Sunucuda hedef port gerçekten dinliyor (ör. DB için 5432, uygulama için 8080).
• Hedef servis 127.0.0.1 dinliyorsa tünel içinde 127.0.0.1 kullandığınızdan emin olun.
• Sunucuda firewall kuralı tünel trafiğini engellemiyor (genellikle tünel, SSH oturumuyla aktarıldığından dışarı kapalı olması engel değildir; fakat lokalde dinleme ve servis izinleri önemlidir).
• SSH kullanıcı yetkileri doğru (özellikle kısıtlı shell veya ForceCommand varsa).

-v ile log alarak sorun yakalama

Komutu şu şekilde çalıştırın:

ssh -v -N -L 15432:127.0.0.1:5432 [email protected]

Önemli ipuçları: - Connection refused genelde hedef portun dinlemediğini veya yanlış IP/port verdiğinizi gösterir. - Permission denied SSH anahtarı/şifre veya yetkilendirme problemidir. - Could not resolve hostname DNS/host girişi sorunudur.

Güvenlik: tüneli “doğru” bağlamak

SSH tunneling pratik ama güvenlik tarafı net kontrol ister.

Yerel bağlama tarafında bind adresini netleştirin

-L komutunda localhost ile başlatmak yerine, hedefte 127.0.0.1 kullanmanız genellikle daha güvenli olur. Örneğin -L 15432:127.0.0.1:5432 yazımı, tünelin yalnızca hedef sunucudaki loopback"e gider.

Remote forward kullanırken dış erişimi sınırlayın

-R ile sunucu tarafında açılan portun herkese açık hale gelmemesi için SSH server ayarlarını kontrol edin.

• SSH server config"inde GatewayPorts ayarı sonuçları etkiler.
• Sunucu firewall/SG/NACL kuralları da belirleyicidir.

Anahtar kullanımı ve şifre zorlamasından kaçınma

• Mümkünse anahtar (SSH key, genelde ed25519) kullanın.
• Tünel açık kalırken ekran kilidi/oturum süreleri gibi etkenler de devreye girebilir.

Oturum süreleri ve kopmalar

• Tünel uzun sürerse bağlantı kopabilir; uygulama tarafında yeniden bağlanma planı yapın.
• Bazı sunucularda ClientAliveInterval gibi SSH keepalive ayarları tercih edilir.

Sık hata senaryoları ve net çözümler

1) localhost:port bağlanıyor ama hedef servis yine de açılmıyor

Muhtemel nedenler: - Sunucuda hedef servis doğru IP/port"ta dinlemiyor. - Yanlış servis adresi kullandınız (ör. DB 127.0.0.1:5432 yerine 0.0.0.0:5432 veya farklı soket).

Çözüm: - Sunucuda servis dinleme durumunu doğrulayın (örn. ss -ltnp veya servis logları). - Tünelde hedefteki host/port değerini birebir düzeltin.

2) Komut çalışmıyor: Address already in use

Bu, yerelde localhost:18080 veya localhost:15432 gibi bir portun zaten kullanıldığını gösterir.

Çözüm: - Kullanılan portu boşaltın veya tünelde yerel portu değiştirin.

3) Permission denied (publickey)

• Yanlış anahtar, yanlış kullanıcı adı veya yetkilendirme kısıtı var.

Çözüm: - SSH config"te doğru IdentityFile kullandığınızdan emin olun. - Sunucuda ~/.ssh/authorized_keys içeriğini ve dosya izinlerini kontrol edin.

NetKıyas gibi hosting seçiminde tünel etkisi: neye bakmalısınız?

SSH tunneling, sadece komut değil; sunucu kaynakları ve ağ özellikleriyle de ilgilidir. Performans farkını yaratan net başlıklar:

• CPU ve ağ bant genişliği: Özellikle veri tabanı sorguları yoğun ise düşük CPU tünelde gecikme yaratır.
• Disk ve IOPS: DB erişimi tünelden geçse de asıl darboğaz disk performansıdır.
• Bulut erişim güvenliği: SSH erişimi için IP kısıtı, firewall ve güvenlik grupları kurulu olmalı.
• Güvenilirlik: Kopmalar, keepalive ayarları ve servis sürekliliğiyle ilgilidir.

Bu nedenle tünel kurarken “kapsam sorunu” değil “hizmet performansı” yaşıyorsanız, kullandığınız VDS/VPS planının CPU/RAM/disk IOPS değerlerini değerlendirin.

Sonuç: Hemen doğru tüneli kurmak için aksiyon planı

1) Önce senaryonuzu seçin: Yerelden sunucu iç servise mi ( -L ), yoksa sunucudan yerel servise mi ( -R ) ihtiyacınız var? 2) -L ile başlayın; -N ve hedefte 127.0.0.1 kullanımı ile hem test hem güvenlik kazanırsınız. 3) Bağlantı kurulmadığında -v ile log alın; ardından sırayla yerel port çakışması, sunucuda dinleme (doğru host/port) ve SSH yetkilerini doğrulayın. 4) Tünel kullanımı kalıcı hale gelecekse (ör. geliştirme süreci), kopma riskini azaltmak için SSH keepalive/oturum süresi ayarlarını planlayın.

Hazır olduğunuzda, kullandığınız uygulamaya göre hedef portu belirleyip ssh -N -L ... komutunu tek seferde doğru değerlerle çalıştırın; ilk denemede başarı sağlandıktan sonra tüneli kalıcı geliştirme akışınıza alın.