SSH Nasıl Çalışır? Sunucuya Bağlanırken Arka Planda Ne Oluyor?

ssh deploy@sunucu komutu kısa görünür. Arka planda ise önce ağ bağlantısı kurulur, taraflar bağlantıyı nasıl koruyacağını kararlaştırır, sunucunun kimliği kontrol edilir ve kullanıcı doğrulanır. Bu aşamaları ayırmak hem güvenliği hem de sorun gidermeyi kolaylaştırır.

Burada SSH'yi yalnızca “uzak terminal açan araç” olarak değil, doğrulanmış ve şifrelenmiş bir taşıma kanalı olarak inceleyeceğiz. Örneklerdeki alan adları temsilidir; komutları yalnızca erişim yetkiniz olan sunuculara uygulayın.

1. Ağ bağlantısı ve protokol görüşmesi

İstemci önce hedef adı IP adresine çözer ve sunucunun dinlediği porta TCP bağlantısı kurar. SSH için alışılmış port 22'dir, ancak sunucu farklı portta dinleyebilir. DNS çözümlemesi, routing ve firewall bu aşamada belirleyicidir.

Bağlantı kurulduktan sonra SSH sürüm bilgisi ve desteklenen algoritmalar görüşülür. Anahtar değişimi, şifreleme ve bütünlük koruması birlikte seçilir. Protokolün taşıma katmanı RFC 4253 içinde tanımlanır; kullanılacak güncel algoritmalar uygulama sürümü ve güvenlik politikasına bağlıdır.

“Connection timed out” çoğunlukla kullanıcı anahtarını değiştirmeyi gerektirmez. Henüz kimlik doğrulama aşamasına gelinmemiş olabilir. “Connection refused” ise hedefe ulaşılmış fakat o portta bağlantı kabul eden servis bulunmamış olabileceğini gösterir.

2. Sunucu kimliği: host key neden var?

Şifreli konuşmak, doğru sunucuyla konuştuğunuzu tek başına kanıtlamaz. SSH sunucusunun host key'i bu kimlik kontrolünde kullanılır. İstemci tanıdığı anahtarları genellikle ~/.ssh/known_hosts içinde takip eder.

İlk bağlantıda görülen fingerprint'i, sunucunun yönetim konsolu veya güvenilir başka bir kanaldan doğrulamak gerekir. Ekranda bir değer gösterilmesi, o değerin güvenilir olduğu anlamına gelmez. Benzer şekilde ssh-keyscan bir anahtarı toplar; anahtarın doğru sunucuya ait olduğunu bağımsız olarak doğrulamaz.

Sunucu yeniden kurulduğunda host key değişebilir. Aynı uyarı bir araya girme saldırısında da ortaya çıkabilir. Dolayısıyla uyarıyı susturmak için kontrolü kapatmak yerine, değişikliğin nedenini doğrulayın. Meşru değişiklik onaylandıktan sonra ilgili eski kaydı güncelleyin.

3. Kullanıcı anahtarı farklı bir soruyu cevaplar

Host key “karşımdaki sunucu doğru mu?” sorusuna cevap verir. Kullanıcı anahtarı ise “bu hesaba bağlanmaya çalışan kişi yetkili mi?” sorusunda kullanılır.

Public key authentication sırasında özel anahtar normalde sunucuya gönderilmez. İstemci, anahtara sahip olduğunu imzayla kanıtlar. Public key ise sunucudaki yetkilendirme kaydıyla ilişkilendirilir. Özel anahtarı e-posta ile göndermek veya sunucuya kopyalamak bu modelin ihtiyacı değildir.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_taskapi -C "task-api-deploy"
ssh -i ~/.ssh/id_ed25519_taskapi deploy@api.example.com

Anahtarı passphrase ile korumak, dosyanın ele geçirilmesi durumunda ek bir engel sağlar. Otomatik işler içinse geniş yetkili kişisel anahtar yerine kapsamı sınırlı makine kimlikleri ve yönetilen secret süreçleri düşünülmelidir.

4. Oturum ve tüneller

Doğrulama başarılı olduğunda bağlantı üzerinde terminal, komut çalıştırma veya port forwarding gibi kanallar açılabilir. SSH bir bağlantıyı yalnızca tek shell ile sınırlamaz.

Örneğin uzak makinenin kendi localhost'unda dinleyen PostgreSQL servisine geçici erişim:

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 deploy@api.example.com

İlk adres kendi bilgisayarınızda dinlenecek noktayı, ikinci adres SSH sunucusunun bakış açısından erişilecek hedefi belirtir. Burada yerel portu yalnızca loopback'e bağlamak, tüneli istemeden yerel ağa açmamak için bilinçli bir seçimdir. Seçeneklerin ayrıntıları OpenSSH istemci kılavuzunda bulunur.

Tünel, veritabanı yetkilendirmesinin yerine geçmez. Hangi kullanıcının hangi veriye erişebileceğini veritabanı yine kontrol etmelidir.

5. Bağlantıları okunabilir hale getirmek

~/.ssh/config içindeki bir host tanımı tekrar eden seçenekleri azaltır:

Host task-api
    HostName api.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519_taskapi
    IdentitiesOnly yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

Ardından ssh task-api kullanılabilir. Bu tanım public key'in sunucuya yetkilendirilmesini kendiliğinden yapmaz. Keepalive seçenekleri de kopmuş ağı onarmaz; bağlantının artık cevap vermediğinin fark edilmesini kolaylaştırır.

6. Hata mesajını doğru aşamada incelemek

ssh -v task-api bağlantı adımlarını gözlemlemek için yararlıdır. Gerekirse ayrıntı seviyesi artırılabilir, ancak çıktıyı paylaşmadan önce kullanıcı, sunucu ve yerel dosya yollarını kontrol edin.

“Permission denied (publickey)” durumunda doğru kullanıcıyı, sunulan anahtarı ve sunucudaki yetkilendirmeyi inceleyin. OpenSSH ayrıca dosya sahipliği ve izinleri nedeniyle anahtarı reddedebilir. Sunucu tarafındaki davranışlar sshd_config seçeneklerine bağlıdır.

Sunucuda SSH ayarı değiştirirken mevcut oturumu açık tutun, yapılandırmayı sshd -t ile doğrulayın ve yeni bağlantıyı ayrı oturumda deneyin. Parola girişini kapatmak gibi bir değişikliği, anahtarla erişimin gerçekten çalıştığını görmeden uygulamak kendinizi dışarıda bırakabilir.

SSH sorunlarını aşamalara ayırdığınızda rastgele anahtar üretmek yerine doğru kanıtı ararsınız: ağ mı, sunucu kimliği mi, kullanıcı yetkisi mi, yoksa oturum politikası mı?