SSH Bağlantısı Sürekli Kopuyor: Kalıcı Çözüm

Bir dosyayı düzenlemek için sunucuya bağlanıyorsunuz, iki dakika başka bir sekmede çalışıp terminale döndüğünüzde imleç ölü. Enter'a basıyorsunuz, hiçbir şey olmuyor. Birkaç saniye sonra ekrana tek satır düşüyor: client_loop: send disconnect: Broken pipe. Ya da daha kötüsü: 40 dakikadır süren bir rsync transferinin ortasında bağlantı kopuyor ve nereye kadar geldiğini bilmiyorsunuz.

Bu iki senaryo aynı hata mesajını verse de kökleri tamamen farklıdır ve bu yüzden çözümleri de farklıdır. Birincisi bir zaman aşımı sorunudur: aradaki bir cihaz, üzerinden veri akmayan TCP oturumunu unutur ve tablosundan siler. İkincisi bir dayanıklılık sorunudur: bağlantı gerçekten koptuğunda, o bağlantıya bağlı olan işiniz de ölür. Birinciyi keepalive ayarlarıyla, ikinciyi ise oturumu bağlantıdan koparan terminal çoklayıcılarla çözersiniz.

Bu rehberde önce belirtiyi doğru sınıflandıracak, sonra istemci ve sunucu tarafındaki ayarların hangisinin nereye yazıldığını, ardından keepalive'ın çözemeyeceği durumlar için kalıcı yaklaşımı ele alacağız.

Önce Ayırın: Boşta mı Kopuyor, İş Yaparken mi?#

Doğru çözümü seçmek için ilk yapmanız gereken şey, kopmanın hangi anda gerçekleştiğini not almaktır. Aşağıdaki tablo, pratikte karşılaşılan dört tipik kalıbı ve her birinin gerçek nedenini özetliyor.

Bu ayrımı yapmadan ayar kurcalamak yaygın bir zaman kaybıdır: sunucuya ClientAliveInterval 60 yazıp sorunun sürdüğünü gören çoğu kişi aslında son satırdaki problemi yaşamaktadır ve keepalive paketi, hat gerçekten koptuğunda hiçbir işe yaramaz.

Hangi tarafın oturumu kapattığını nasıl anlarsınız#

Bağlantıyı -v bayrağıyla açıp bekleyin. Kopma anında ekrana düşen son satırlar size taraf bilgisini verir:

ssh -v [email protected]

Timeout, server ... not responding. görüyorsanız istemci pes etmiştir: keepalive isteklerine cevap gelmemiştir. Connection closed by 203.0.113.10 port 22 görüyorsanız sunucu oturumu düzgün biçimde kapatmıştır, yani bir yapılandırma kararı devrededir. Connection reset by peer ise araya giren bir cihazın TCP RST gönderdiği anlamına gelir; aynı hatanın tarayıcıdaki karşılığı ERR_CONNECTION_RESET hatası yazısında.

SSH Broken Pipe Hatası Ne Anlama Geliyor?#

Broken pipe, SSH'a özel bir hata değildir; işletim sisteminin bir soket üzerinden veri yazmaya çalışan sürece verdiği EPIPE cevabının insan okunur hâlidir. Yani mesaj şunu söyler: "Bu bağlantı artık yok, yazmaya çalıştığın veriyi gönderecek yer kalmadı."

Peki bağlantı neden yok? SSH oturumu TCP üzerine kuruludur ve TCP, üzerinden veri akmadığı sürece hiçbir paket göndermez. Siz terminale bakıp beklerken ağ üzerinde tam anlamıyla sıfır trafik vardır. Aradaki cihazlar (ev modemi, kurumsal güvenlik duvarı, operatör CGNAT'ı, bulut sağlayıcının NAT gateway'i) her aktif bağlantı için bellekte bir kayıt tutar ve belirli bir süre veri görmezlerse bu kaydı düşürürler.

Kayıt düştükten sonra bir tuşa bastığınızda paket, artık kendisini tanımayan bir cihaza ulaşır. Cihaz paketi ya sessizce çöpe atar (terminal donar) ya da RST ile cevap verir (anında Connection reset by peer alırsınız).

Tipik zaman aşımı süreleri şöyledir:

• Ev modemlerinde ve küçük ofis cihazlarında: 5-30 dakika
• Kurumsal güvenlik duvarlarında: 15-60 dakika, bazen daha agresif
• Mobil operatör CGNAT'ında: 2-5 dakika (en sorunlu senaryo)
• Linux conntrack varsayılanı: 5 gün (yani sunucunun kendisi nadiren suçludur)

Mobil internet üzerinden bağlanıp "iki dakikada kopuyor" diyorsanız, sorunun operatörün NAT tablosunda olduğunu neredeyse kesin biliyorsunuz demektir.

İstemci Tarafı Çözüm: ServerAliveInterval#

Çözüm basittir: bağlantı boştayken bile düzenli aralıklarla küçük bir paket göndererek aradaki cihazlara "bu oturum hâlâ canlı" demek. OpenSSH bunu ServerAliveInterval ile yapar ve bu ayar istemci makinede, yani bağlantıyı başlattığınız bilgisayarda tanımlanır.

Kendi kullanıcı hesabınız için ~/.ssh/config dosyasını açın (yoksa oluşturun):

mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/config
chmod 600 ~/.ssh/config

İçine şunu yazın:

Host uretim
    HostName 203.0.113.10
    User deploy
    Port 22
    ServerAliveInterval 30
    ServerAliveCountMax 5

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    TCPKeepAlive no

ServerAliveInterval 30, istemcinin 30 saniyede bir şifreli kanal üzerinden sunucuya istek göndermesini sağlar. ServerAliveCountMax 5 ise kaç cevapsız istekten sonra pes edileceğini belirler. İki değerin çarpımı, gerçek bir kopmanın ne kadar sürede fark edileceğini verir: 30 × 5 = 150 saniye. Kısa aralık ve yüksek sayaç birleşimi hem NAT'ı memnun eder hem de anlık dalgalanmalarda oturumu hemen düşürmez.

⚠️ Sık yapılan hata: ssh_config dosyasında ilk eşleşen değer geçerlidir, son eşleşen değil. Bu yüzden Host * bloğunu dosyanın en altına koymalısınız. En üste koyarsanız aşağıdaki tüm host'a özel ayarlarınız görmezden gelinir ve neden çalışmadığını saatlerce ararsınız.

Tek seferlik denemek için dosyaya hiç dokunmadan komut satırından da verebilirsiniz:

ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5 [email protected]

TCPKeepAlive neden yeterli değil?#

OpenSSH'ın TCPKeepAlive diye ayrı bir seçeneği vardır ve varsayılan olarak açıktır. Ancak bu, çekirdeğin TCP katmanındaki keepalive mekanizmasını kullanır ve Linux'ta ilk keepalive paketi varsayılan olarak 7200 saniye (2 saat) boşta kaldıktan sonra gönderilir. NAT tablosu çoktan temizlenmiş olur. Ayrıca bu paketler şifreli SSH kanalının dışında gider.

ServerAliveInterval ise isteği şifreli kanalın içinden yollar; araya giren cihaz gerçek veri akışı gördüğü için oturumu canlı sayar. Pratik öneri: ServerAliveInterval kullanın, TCPKeepAlive no yazarak diğerini kapatın.

Windows, PuTTY ve mobil istemciler#

Windows 10/11'in dahili OpenSSH istemcisi aynı dosyayı okur, sadece yolu farklıdır: C:\Users\kullanici\.ssh\config. Sözdizimi birebir aynıdır. Kurulum detayları için Windows'tan sunucuya SSH bağlantısı yazısına bakabilirsiniz.

PuTTY kullanıyorsanız ayar arayüzdedir: Connection sekmesindeki Seconds between keepalives alanı varsayılan olarak 0'dır, yani kapalıdır. Buraya 30 yazıp oturumu kaydedin. MobaXterm, Termius ve mobil istemcilerin hemen hepsinde aynı ayar "keepalive" başlığı altında bulunur.

Sunucu Tarafı Çözüm: ClientAliveInterval ve ClientAliveCountMax#

Aynı işi sunucu da yapabilir. Bu, sunucuya farklı yerlerden bağlanan bir ekip varsa daha pratiktir: herkesin bilgisayarında ayar yapmak yerine tek dosyayı düzenlersiniz. /etc/ssh/sshd_config dosyasında ilgili satırlar şunlardır:

ClientAliveInterval 60
ClientAliveCountMax 10
TCPKeepAlive no

Bu yapılandırma sunucunun 60 saniyede bir istemciye canlılık isteği göndermesini, 10 kere üst üste cevap alamazsa (yani 600 saniye sonra) oturumu kapatmasını sağlar.

⚠️ Burada çok kritik bir ayrım var. ClientAliveInterval iki farklı amaç için kullanılabilir ve ikisi zıt yönde çalışır:

Güvenlik sıkılaştırma rehberlerinin (CIS gibi) önerdiği ikinci satırdır. Eğer sunucunuz hazır bir "hardened" imajdan kurulduysa veya bir uyum betiği çalıştıysa, kopmaların sebebi sizin kendi güvenlik ayarınız olabilir. Saat gibi düzenli aralıklarla kopan bağlantılarda ilk bakılacak yer burasıdır.

Ubuntu 22.04+ ve drop-in dosya tuzağı#

Modern Ubuntu ve Debian sürümlerinde /etc/ssh/sshd_config dosyasının en üstünde şu satır bulunur:

Include /etc/ssh/sshd_config.d/*.conf

sshd_config da tıpkı istemci tarafı gibi ilk okunan değeri kullanır. Include en üstte olduğu için /etc/ssh/sshd_config.d/ altındaki bir dosya, ana dosyadaki aynı isimli ayarı ezer ve bulut sağlayıcıların imajları buraya sık sık dosya bırakır. "Değişiklik hiç uygulanmıyor" diyorsanız önce şu dizine bakın:

ls -la /etc/ssh/sshd_config.d/
sudo grep -ri "clientalive" /etc/ssh/

Değişikliği doğrulamak ve uygulamak#

Dosyayı kaydettikten sonra önce sözdizimini test edin, servisi körlemesine yeniden başlatmayın:

# Sözdizimi kontrolü — hata varsa çıktı verir
sudo sshd -t

# Sunucunun gerçekten kullanacağı efektif değerleri gör
sudo sshd -T | grep -i clientalive

sshd -T çıktısı, tüm include'lar ve varsayılanlar birleştirildikten sonraki nihai değerleri gösterir; yani "hangi ayar kazandı" sorusunun tek doğru cevabıdır. Sonuç beklediğiniz gibiyse servisi yeniden yükleyin:

# Debian / Ubuntu
sudo systemctl reload ssh

# RHEL / AlmaLinux / Rocky
sudo systemctl reload sshd

reload kullanmak restarttan güvenlidir çünkü mevcut oturumları düşürmez. Yine de ikinci bir SSH oturumunu açık tutun ve ilk oturumdan çıkmadan yeni bir bağlantı deneyin; kendi kendinizi sunucudan kilitlemek, SSH bağlantısı ve güvenliği konusunda en pahalı hatadır. Servis kayıtlarını journalctl ile log yönetimi yöntemleriyle izleyin.

Hangi Ayar Nereye Yazılır?#

İsimleri birbirine çok benzediği için sürekli karıştırılan bu dört seçeneği tek tabloda toplayalım:

Hafızada kalması için basit bir kural: ayarın adındaki taraf, karşıdaki taraftır. ServerAlive = "sunucu hayatta mı" diye soran istemcinin ayarıdır, dolayısıyla istemci dosyasına yazılır. ClientAlive = "istemci hayatta mı" diye soran sunucunun ayarıdır ve sshd_config'e yazılır.

İkisini aynı anda kullanmakta sakınca yoktur; hatta ideali budur. İstemci ayarı sizin bilgisayarınızı korur, sunucu ayarı ise ayar yapmayı unutan takım arkadaşlarınızı.

Uzun Süren Komut Kopunca Yarıda Kalıyorsa: tmux ve screen#

Şimdi keepalive'ın hiçbir katkı sağlamadığı ikinci senaryoya geçelim. Bir veritabanı yedeği alıyorsunuz, apt full-upgrade çalışıyor veya 300 GB'lık bir dizini taşıyorsunuz. Yarım saat sonra dizüstünüzün kapağını kapatıyorsunuz, Wi-Fi ağı değişiyor ya da elektrik gidiyor. Bağlantı koptuğunda oturuma bağlı kabuk SIGHUP sinyali alır ve o kabuğun çocuğu olan işiniz de ölür. Çözüm ağ katmanında değil oturum katmanındadır: işi bağlantıdan bağımsız bir yere taşımak.

tmux ile pratik kullanım#

# Sunucuya bağlandıktan sonra isimli bir oturum açın
tmux new -s yedekleme

# Uzun süren komutu bu oturumun içinde başlatın
pg_dump -Fc uygulama_db > /yedek/db-$(date +%F).dump

# Ctrl+b sonra d ile oturumdan ayrılın (iş çalışmaya devam eder)
# Bağlantı koparsa yeniden bağlanıp devam edin:
tmux attach -t yedekleme

# Hangi oturumlar var?
tmux ls

Ctrl+b ardından d tuşuna bastığınızda oturum "detach" olur; işlem çalışmaya devam eder çünkü artık sizin SSH oturumunuza değil, tmux sürecine bağlıdır. Ertesi gün başka bir bilgisayardan bağlanıp tmux attach yazdığınızda ekranı tam bıraktığınız yerde bulursunuz. Pencere bölme ve kalıcı düzen kurma gibi ileri kullanımlar tmux terminal çoklayıcı rehberi yazısında.

screen tercih edenler için#

screen daha eskidir ama neredeyse her sunucuda hazır bulunur:

screen -S yedekleme
# ... komutu başlat ...
# Ctrl+a sonra d ile ayrıl
screen -ls          # oturumları listele
screen -r yedekleme # geri dön

Ayrıntılar için screen oturum yönetimi yazısı yeterli olacaktır. tmux ile screen arasında seçim yaparken pratik kural şudur: sunucuda ikisinden hangisi kuruluysa onu kullanın, ikisi de yoksa tmux kurun.

tmux yoksa acil çözüm: nohup#

Terminal çoklayıcı kurmaya yetkiniz yoksa veya tek seferlik bir iş için uğraşmak istemiyorsanız, komutu SIGHUP sinyalinden yalıtabilirsiniz:

nohup ./uzun-betik.sh > /var/log/uzun-betik.log 2>&1 &

nohup süreci hangup sinyalinden korur, & arka plana atar, yönlendirme çıktının kaybolmamasını sağlar. Zaten başlattığınız bir işi sonradan kurtarmak için disown kullanılır:

# Ctrl+Z ile duraklat, arka plana al, kabuğun iş listesinden çıkar
bg
disown -h %1

Bunun tmux'a göre büyük bir dezavantajı vardır: interaktif çıktıyı geri izleyemezsiniz, sadece log dosyasını okursunuz. Sinyallerin süreçleri nasıl etkilediğini süreç sonlandırma ve kill sinyalleri yazısında bulabilirsiniz.

Keepalive Ayarladım Yine Kopuyor: Diğer Sebepler#

Her iki taraf da doğru yapılandırıldığı hâlde kopmalar sürüyorsa sırasıyla şunlara bakın.

1. Bash TMOUT değişkeni. Kopma anında timed out waiting for input: auto-logout mesajı görüyorsanız SSH masum, suçlu kabuk:

echo $TMOUT
sudo grep -ri "TMOUT" /etc/profile /etc/profile.d/ /etc/bash.bashrc

Bir değer dönüyorsa ilgili dosyada tanımlanmıştır. Sıkılaştırma betikleri bunu genellikle readonly TMOUT=900 biçiminde yazar; oturum içinden değiştiremezsiniz, dosyayı düzenlemeniz gerekir.

2. Gerçek paket kaybı. Hattınız zaten sorunluysa keepalive paketleri de kaybolur:

mtr -rwzbc 200 203.0.113.10

Loss% sütununda son satırda kalıcı bir kayıp varsa sorun gerçekten hattadır; ara satırlardaki kayıplar yanıltıcıdır çünkü birçok yönlendirici ICMP'ye düşük öncelik verir. Yorumlama detayları ping, traceroute ve mtr ile ağ tanılama yazısında.

3. MTU / path MTU black hole. Bağlantı sorunsuz kuruluyor, ls gibi kısa çıktılar çalışıyor ama cat büyük-dosya veya apt upgrade gibi bol çıktı üreten komutlarda anında donuyorsa şüpheli MTU'dur. VPN veya PPPoE bağlantılarında sık görülür:

# Parçalanmaya izin vermeden test et, boyutu düşürerek dene
ping -M do -s 1400 -c 3 203.0.113.10
ping -M do -s 1200 -c 3 203.0.113.10

1400 başarısız olup 1200 başarılı oluyorsa yol üzerinde MTU daralması vardır. İstemci arayüzünüzde MTU'yu 1400 civarına çekmek çoğu durumda sorunu bitirir.

4. Sunucu kaynak sıkıntısı veya engelleme. Bellek biten bir sunucuda OOM killer sshd sürecini de hedef alabilir; Fail2ban da tekrarlayan bağlantılarınızı saldırı sanıp IP'nizi yasaklayabilir. Kopma anlarındaki kayıtlara bakın:

sudo journalctl -u ssh --since "1 hour ago" --no-pager
sudo grep -iE "oom|killed process" /var/log/syslog
sudo fail2ban-client status sshd

Ban listesini yorumlamak için Fail2ban kurulumu, kural denetimi için UFW güvenlik duvarı rehberine bakabilirsiniz.

Sürekli Kopan Hatlar İçin: mosh Alternatifi#

Uydu bağlantısı, mobil internet veya sürekli ağ değiştiren bir dizüstüyle çalışıyorsanız SSH'ın TCP tabanlı yapısı dezavantajdır. mosh bu senaryo için tasarlanmıştır: kimlik doğrulamayı SSH üzerinden yapar, sonra UDP'ye geçer ve oturumu IP adresine değil kendi oturum kimliğine bağlar.

sudo apt install mosh                  # her iki tarafa da kurulmalı
sudo ufw allow 60000:61000/udp         # UDP aralığını açın
mosh [email protected]

Wi-Fi'dan mobil veriye geçtiğinizde, hatta bilgisayarı uyku moduna alıp saatler sonra açtığınızda oturum aynen yerinde durur. Karşılığında terminal kaydırma geçmişi düzgün çalışmaz ve port yönlendirme desteklenmez. Bu yüzden mosh'u SSH'ın yerine değil tamamlayıcısı olarak düşünün; en sağlam kombinasyon mosh ile bağlanıp içeride tmux kullanmaktır.

Adım Adım Kalıcı Çözüm Reçetesi#

Her yeni sunucuda ve iş bilgisayarında uyguladığınızda bu sorunla bir daha karşılaşmazsınız:

1. İstemcinizde ~/.ssh/config dosyasına Host * bloğunu (dosyanın en altına) ekleyip ServerAliveInterval 60, ServerAliveCountMax 3 yazın.
2. Sunucuda sshd -T | grep -i clientalive çalıştırıp mevcut durumu görün; ClientAliveCountMax 0 görüyorsanız bunun kasıtlı bir sıkılaştırma olup olmadığına karar verin.
3. ClientAliveInterval 60 ve ClientAliveCountMax 10 ayarlayın, sshd -t ile doğrulayın, ikinci oturum açık iken reload edin.
4. Dakikalar süren her işi istisnasız tmux veya screen içinde başlatma alışkanlığı edinin. Bu tek alışkanlık, keepalive ayarlarından daha fazla iş kaybı önler.
5. Kopmalar sürüyorsa mtr ile hattı, TMOUT ile kabuğu ve MTU'yu sırasıyla eleyin.
6. Mobil veya kararsız hatlarda çalışıyorsanız mosh + tmux ikilisini kurun.

Son bir uyarı: bağlantı kurulurken oluşan hatalar (özellikle Permission denied (publickey)) bu rehberdeki konuların hiçbiriyle ilgili değildir; onlar kimlik doğrulama sorunudur ve SSH permission denied publickey hatası yazısında ele alınır.

Sıkça Sorulan Sorular#

ServerAliveInterval için ideal değer kaçtır?#

Çoğu senaryoda 60 saniye yeterlidir ve gereksiz trafik yaratmaz. Mobil internet veya CGNAT arkasındaysanız 20-30 saniyeye düşürün, çünkü operatör NAT tabloları çok daha agresif temizlenir. 10 saniyenin altına inmenin faydası yoktur; paket sayısını artırır, sorunu çözmez. ServerAliveCountMax değerini 3 ile 5 arasında tutmak anlık dalgalanmalarda gereksiz kopmayı önler.

ClientAliveInterval ayarını sıfır yapmak güvenli mi?#

Sıfır değeri sunucu tarafındaki canlılık kontrolünü tamamen kapatır. Bu tek başına bir güvenlik açığı değildir, ancak sunucu artık ölü oturumları tespit edemez ve zombi süreçler birikebilir. Daha iyi yaklaşım, ayarı kapatmak yerine ClientAliveCountMax değerini yükseltmektir: canlılık kontrolü devam eder ama sunucu kopmaya karar vermeden önce çok daha uzun süre bekler.

Bağlantı kopunca çalışan komutum devam eder mi?#

Hayır. Doğrudan SSH oturumunda başlattığınız bir komut, bağlantı koptuğunda kabukla birlikte SIGHUP sinyali alır ve sonlanır. Devam etmesini istiyorsanız komutu tmux veya screen oturumu içinde başlatmalı ya da en azından nohup ile hangup sinyalinden yalıtmalısınız. Bu yüzden uzun yedekleme ve güncelleme işlerini asla çıplak bir SSH oturumunda başlatmayın.

Broken pipe ile connection reset arasındaki fark nedir?#

Broken pipe, artık var olmayan bir bağlantıya veri yazmaya çalıştığınızda yerel işletim sisteminizin verdiği cevaptır; genellikle sessizce düşürülmüş bir oturumun ardından gelir. Connection reset by peer ise karşı taraftan veya aradaki bir cihazdan gerçek bir TCP RST paketi geldiği anlamına gelir. İkincisi genellikle güvenlik duvarı, NAT cihazı veya kasıtlı bir engelleme kuralına işaret eder.

Sunucuya erişemiyorum, ayarı istemciden çözebilir miyim?#

Evet. ServerAliveInterval tamamen istemci tarafı bir ayardır ve sunucuda hiçbir değişiklik gerektirmez; sunucunun bunu desteklemesi için özel bir yapılandırma da gerekmez. Paylaşımlı bir sunucuda veya root yetkiniz olmayan bir makinede çalışıyorsanız yapılacak tek şey budur ve boşta kopma sorununun büyük bölümünü çözer.

Aynı ayarları her sunucu için tek tek yazmam gerekir mi?#

Gerekmez. ~/.ssh/config dosyanızın en altına bir Host * bloğu ekleyip keepalive ayarlarını oraya yazarsanız, bağlandığınız tüm sunucular için geçerli olur. Belirli bir sunucuya farklı değer vermek isterseniz o host'a özel bloğu dosyada Host * bloğundan önce tanımlayın; OpenSSH ilk eşleşen değeri kullandığı için sıralama burada belirleyicidir.

VPN üzerinden bağlanınca neden daha sık kopuyor?#

VPN tünelleri hem ek bir zaman aşımı katmanı ekler hem de tünel başlığı için yer ayırdığından efektif paket boyutunu küçültür. Düşen MTU, özellikle çok çıktı üreten komutlarda ani donmalara yol açar. ping -M do -s 1400 testiyle doğrulayın ve VPN istemcinizde MTU değerini 1400 civarına çekmeyi deneyin.