Sunucuma Bağlanamıyorum: SSH ve Ping Sorunları Nasıl Çözülür?

Beş dakika önce her şey çalışıyordu. Bir güvenlik duvarı kuralı eklediniz, bir paket güncellemesi yaptınız ya da sadece sunucuyu yeniden başlattınız — ve şimdi terminal otuz saniye bekleyip ssh: connect to host 203.0.113.20 port 22: Connection timed out yazıyor. "Sunucuma bağlanamıyorum" cümlesi, yeni sunucu sahiplerinin yaşadığı en sık ve en stresli kriz; çünkü sunucunun içine giremediğiniz sürece neyin bozulduğunu da göremezsiniz. İyi haber şu: bu sorunun olası nedenleri sonsuz değil, dört katmanda toplanır ve doğru sırayla elediğinizde genellikle beş dakikada bulunur.

Bu yazıda tahmin yürütmeyi bırakıp yapılandırılmış bir teşhis akışı izleyeceğiz. Önce sorunun sizin tarafınızda mı yoksa sunucuda mı olduğunu ayıracağız; sonra sunucunun ayakta olup olmadığını, güvenlik duvarının paketi düşürüp düşürmediğini ve sshd servisinin gerçekten dinleyip dinlemediğini sırayla doğrulayacağız. Hata mesajına göre hangi katmanda takıldığınızı söyleyen bir tablo, sağlayıcı panelindeki konsol/VNC ekranından kurtarma adımları ve bir daha kilitlenmemek için alınacak önlemler de yazının içinde.

Önce Sorunu Dört Katmana Ayırın#

SSH bağlantısı kurulamadığında sorun mutlaka şu dört katmandan birindedir ve sırayla elemek, rastgele komut denemekten kat kat hızlıdır:

1. Sizin tarafınız — bulunduğunuz ağ, internet servis sağlayıcınız, yerel güvenlik duvarınız, yanlış IP/port bilgisi.
2. Sunucunun açık olup olmaması — makine kapalı, çökmüş, disk dolu, ağ arayüzü düşmüş.
3. Güvenlik duvarı — sunucu içindeki ufw/firewalld/nftables ya da sağlayıcı panelindeki ağ filtresi.
4. SSH servisi — sshd çalışmıyor, yanlış portta dinliyor, yapılandırma hatası nedeniyle ayağa kalkamıyor.

Bu sırayı bozmayın. En sık yapılan hata, sorunun sunucuda olduğunu varsayıp doğrudan konsola girip yapılandırma kurcalamaktır — oysa vakaların önemli bir kısmında sunucunun hiçbir sorunu yoktur.

Aldığınız hata mesajı hangi katmanda olduğunuzu zaten büyük ölçüde söyler. Bu tabloyu bir kenara not edin:

Connection timed out ile Connection refused arasındaki fark burada altın değerindedir: birincisi paketin yolda kaybolduğunu, ikincisi hedefe ulaşıp "burada kimse yok" cevabı aldığını söyler. Bu ikisinin katman katman çözümünü err connection timed out hatası ve err connection refused hatası yazılarında ayrıca ele aldım.

Katman 1: Sorun Sizin Tarafınızda Olabilir#

Sunucuya dokunmadan önce kendi tarafınızı eleyin; bu üç kontrol iki dakika sürer ve vakaların şaşırtıcı bir bölümünü burada bitirir.

Farklı bir ağdan deneyin. Kurumsal ağlar, üniversite ağları, otel ve kafe Wi-Fi'ları çıkışta 22 portunu sıklıkla kapatır. Telefonunuzun mobil verisiyle bilgisayarınızı bağlayıp tekrar deneyin. Mobil veriden çalışıyorsa sorun sunucuda değil, bulunduğunuz ağdadır. Bu durumda kalıcı çözüm SSH'ı 443 gibi genelde açık bir porta taşımaktır; nasıl yapıldığını ssh portu değiştirme yazısında anlattım.

IP adresini ve portu doğrulayın. Özellikle birden fazla sunucusu olanların en sık hatası yanlış IP'ye bağlanmaya çalışmaktır. Sağlayıcı panelinizden IP'yi kopyalayın ve verbose modda deneyin:

ssh -vvv -p 22 [email protected]

-vvv çıktısı nerede takıldığını satır satır gösterir. Şu satırda takılıp kalıyorsanız paket hiç dönmüyor demektir:

debug1: Connecting to 203.0.113.20 [203.0.113.20] port 22.

Bunun ardından Connection established satırını görüyorsanız ağ ve güvenlik duvarı sorunsuzdur; sorun kimlik doğrulamadadır.

IP'nin doğru yere gittiğini kontrol edin. Alan adıyla bağlanıyorsanız DNS kaydı eski sunucuyu gösteriyor olabilir:

ping -c 4 sunucum.com
dig +short sunucum.com A

Dönen IP panelde gördüğünüz IP değilse sorun DNS'tedir, sunucuda değil.

Kendi güvenlik duvarınızı gözden geçirin. Kurumsal bilgisayarlarda giden bağlantıları filtreleyen istemci güvenlik duvarları vardır. Windows kullanıyorsanız PowerShell'den hızlı bir port testi yapabilirsiniz:

Test-NetConnection -ComputerName 203.0.113.20 -Port 22

TcpTestSucceeded : False dönüyorsa paket hedefe ulaşmıyor demektir.

Katman 2: Sunucu Ayakta mı#

Sunucunun açık olup olmadığını anlamanın en hızlı yolu ping'dir, ama tek başına ping yanıltıcıdır.

ping -c 5 203.0.113.20

Yanıt geliyorsa makine ayaktadır ve ağa bağlıdır — sorun 3. veya 4. katmandadır. Yanıt gelmiyorsa hemen "sunucu kapalı" sonucuna atlamayın: birçok sunucu güvenlik gerekçesiyle ICMP yanıtlarını kapatır ve ping'e cevap vermez ama SSH'ı sorunsuz çalışır. Ping başarısızsa TCP seviyesinde de bir test yapın:

# Herhangi bir portu TCP olarak dener
nc -zv 203.0.113.20 22
nc -zv 203.0.113.20 80
nc -zv 203.0.113.20 443

80 veya 443 açık ve yanıt veriyorsa sunucu kesinlikle ayaktadır; yalnızca SSH erişiminde sorun var demektir. Bu, teşhisi çok daraltan güçlü bir sinyaldir. Ağ katmanı testlerini ayrıntılı yapmak isterseniz ağ tanılama ping traceroute mtr yazısı yol haritası verir.

Web siteniz de açılmıyorsa ve hiçbir port yanıt vermiyorsa muhtemelen makine gerçekten kapalıdır ya da önyükleme sırasında takılmıştır. Bunu doğrulayacak tek yer sağlayıcı panelidir. Panelde şunlara bakın:

• Sunucunun durumu (Çalışıyor / Kapalı / Askıya alınmış)
• Son yeniden başlatma zamanı
• CPU ve ağ grafikleri — grafikler düz çizgiye dönmüşse makine gerçekten durmuştur
• Ödeme/askıya alma durumu — ödenmemiş fatura nedeniyle askıya alınmış hizmet de tam olarak bu tabloyu üretir

Sunucu "Çalışıyor" görünüyor ama hiçbir porta cevap vermiyorsa, bir sonraki durak konsoldur.

Katman 3: Güvenlik Duvarı Paketi Düşürüyor Olabilir#

Connection timed out alıyorsanız ve sunucu ayaktaysa bir numaralı şüpheli güvenlik duvarıdır. Burada dikkat edilmesi gereken iki ayrı katman var ve ikisi birbirinden bağımsız çalışır:

a) Sunucu içindeki güvenlik duvarı. Konsoldan girerek durumu okuyun:

# Ubuntu / Debian
sudo ufw status verbose

# AlmaLinux / Rocky / CentOS
sudo firewall-cmd --list-all

# Doğrudan kural tablosu
sudo iptables -L -n -v --line-numbers
sudo nft list ruleset

ufw status çıktısında 22/tcp ALLOW IN satırını göremiyorsanız sebebi buldunuz. En klasik kilitlenme senaryosu şudur: kullanıcı ufw enable komutunu çalıştırır, varsayılan politika gelen tüm trafiği reddeder ve SSH kuralı henüz eklenmediği için oturum o an kopar. Konsoldan çözümü tek satırdır:

sudo ufw allow 22/tcp
sudo ufw reload

SSH portunu değiştirdiyseniz ve yeni portu güvenlik duvarında açmayı unuttuysanız da tablo aynıdır. Güvenlik duvarı kurallarının doğru sırayla nasıl kurulacağını ufw güvenlik duvarı yazısında anlattım.

b) Sağlayıcı tarafındaki ağ güvenlik duvarı. Birçok sağlayıcının panelinde, sunucunun işletim sisteminden bağımsız bir ağ filtresi bulunur. Bu katmanda port kapalıysa, sunucu içinde ne yaparsanız yapın paket makineye hiç ulaşmaz. Panelde "güvenlik duvarı", "ağ kuralları" veya benzeri bir bölüm varsa 22 (ya da yeni SSH portunuz) için gelen TCP izninin bulunduğunu doğrulayın.

Bir de üçüncü, daha sinsi ihtimal var: fail2ban kendinizi engellemiş olabilir. Birkaç kez yanlış parola girdiyseniz IP'niz otomatik banlanmış olabilir. Konsoldan kontrol edin:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.5

Kendi IP'nizi kalıcı olarak muaf tutmak için jail.local dosyasındaki ignoreip satırına ekleyin. Ayrıntılar fail2ban kurulumu yazısında.

Katman 4: sshd Servisi Çalışıyor mu#

Connection refused alıyorsanız paket sunucuya ulaşmış ama o portta dinleyen kimse yok demektir. Bu neredeyse her zaman servis sorunudur. Konsoldan sırayla:

sudo systemctl status sshd      # RHEL ailesi
sudo systemctl status ssh       # Debian / Ubuntu

Servis inactive (dead) veya failed durumundaysa nedenini loglar söyler:

sudo journalctl -u sshd -n 50 --no-pager

Sık karşılaşılan üç neden ve çözümleri:

1. Yapılandırma hatası. Bir satır yanlış yazıldığında sshd hiç başlamaz. Önce test edin:

sudo sshd -t

Hata satır numarasıyla birlikte gelir. Yedeğiniz varsa geri dönmek en hızlı yoldur:

sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo systemctl restart sshd

2. Port SELinux tarafından reddediliyor. AlmaLinux/Rocky'de standart dışı bir porta geçtiyseniz log şuna benzer:

error: Bind to port 22022 on 0.0.0.0 failed: Permission denied.

Çözüm portu SELinux politikasına tanıtmaktır:

sudo semanage port -a -t ssh_port_t -p tcp 22022
sudo systemctl restart sshd

3. Beklenen porttan farklı bir portta dinliyor. Gerçekte hangi portun dinlendiğini tahmin etmeyin, okuyun:

sudo ss -tlnp | grep sshd
sudo sshd -T | grep -i "^port"

ss çıktısı boşsa servis hiç ayakta değildir. sshd -T çıktısındaki port sizin beklediğinizden farklıysa /etc/ssh/sshd_config.d/ altındaki bir dosya ayarınızı eziyor olabilir ya da yeni Ubuntu sürümlerinde socket aktivasyonu devrededir — bu modda sshd_config içindeki Port satırı yok sayılır ve port ssh.socket biriminden ayarlanır.

Bir de kaynak tükenmesi ihtimali var. Disk tamamen dolduğunda SSH oturum açma sırasında geçici dosya yazamaz ve bağlantı kurulup hemen kopar:

df -h

/ bölümü %100 görünüyorsa önce yer açın; log dosyaları en sık suçludur. Bu senaryonun çözümünü disk dolu no space left çözümü yazısında ayrıntılı anlattım.

Konsol ve VNC ile Kurtarma: Kilitlendiğinizde Ne Yapılır#

SSH tamamen kapandığında elinizde kalan tek yol sağlayıcı panelindeki konsol (VNC/KVM) erişimidir. Bu ekran ağ katmanından bağımsız çalışır: güvenlik duvarı tüm portları kapatmış olsa bile klavye ve ekran doğrudan sanal makineye bağlanır. Kurtarma sırası şöyledir:

1. Panelden sunucunun konsolunu açın; bir giriş ekranı (login:) göreceksiniz.
2. root ve panelde tanımlı parolayla giriş yapın. Parolayı bilmiyorsanız panelden sıfırlayın; yöntemi sunucu root şifresi değiştirme yazısında.
3. Önce en olası suçluyu kontrol edin — güvenlik duvarı:

   ufw status verbose
   ufw allow 22/tcp
   

4. Servisin ayakta olduğunu doğrulayın:

   systemctl status sshd
   systemctl restart sshd
   ss -tlnp | grep sshd
   

5. Yapılandırmayı bozduysanız yedeği geri alın ve sshd -t ile doğrulayın.
6. Disk doluluğunu ve sistem yükünü kontrol edin: df -h, uptime, free -h.

Konsolda çalışırken iki pratik not: klavye düzeni genelde İngilizce'dir, bu yüzden Türkçe karakter içeren parolalar beklendiği gibi yazılmayabilir; ve kopyala-yapıştır çoğu konsolda çalışmaz, komutları elle yazmanız gerekir. Bu yüzden karmaşık komutları önce basitleştirin.

Konsol da açılmıyor veya giriş ekranı hiç gelmiyorsa sunucu önyükleme aşamasında takılmış olabilir. Panelden zorla yeniden başlatma (hard reset) yapın ve açılış ekranını izleyin; dosya sistemi hatası varsa fsck çağrısı ekranda görünür.

Kimlik Doğrulama Aşamasına Geçtiyseniz Sorun Ağda Değildir#

Şu mesajlardan birini alıyorsanız iyi haber: ağ, güvenlik duvarı ve SSH servisi eksiksiz çalışıyor demektir. Sorun tamamen kimlik doğrulamadadır ve konsola girmenize gerek olmayabilir.

• Permission denied (publickey) — sunucu yalnızca anahtar kabul ediyor, sizin anahtarınız kabul edilmiyor.
• Permission denied (publickey,password) — anahtar da parola da denendi, ikisi de tutmadı.
• Too many authentication failures — istemciniz sırayla çok fazla anahtar deniyor, sunucu bağlantıyı kesiyor.

Üçüncüsünün pratik çözümü, doğru anahtarı açıkça belirtip diğerlerinin denenmesini kapatmaktır:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes [email protected]

publickey hatasının en sık nedenleri sunucudaki dosya izinleridir: ~/.ssh dizini 700, authorized_keys dosyası 600 olmalı ve ikisinin de sahibi ilgili kullanıcı olmalıdır. Konsoldan düzeltin:

chmod 700 /home/kullanici/.ssh
chmod 600 /home/kullanici/.ssh/authorized_keys
chown -R kullanici:kullanici /home/kullanici/.ssh

Bu hatanın tüm varyasyonlarını ssh permission denied publickey hatası yazısında topladım.

Host key verification failed mesajı ise sunucunun kimliğinin değiştiğini söyler. Sunucuya format attıysanız veya IP başka bir makineye geçtiyse normaldir; eski kaydı silin:

ssh-keygen -R 203.0.113.20

Böyle bir değişiklik beklemiyorsanız durun ve araştırın — bu, araya girme saldırısının da belirtisi olabilir.

Bir Daha Kilitlenmemek İçin#

Bu krizi bir kez yaşayan herkesin alması gereken önlemler var; hepsi birkaç dakikalık işler:

Riskli değişiklikte ikinci oturumu açık tutun. Güvenlik duvarı, sshd_config veya ağ yapılandırması değiştirirken mevcut oturumu asla kapatmayın. Yeni ayarı ikinci bir terminalden test edin; çalışmıyorsa hâlâ açık olan ilk oturumdan geri alırsınız.

Geri alma zamanlayıcısı kurun. Uzaktan güvenlik duvarı değiştirirken bu numara hayat kurtarır — 10 dakika içinde iptal etmezseniz kurallar sıfırlanır:

sudo bash -c 'echo "ufw --force reset && ufw allow 22/tcp && ufw --force enable" | at now + 10 minutes'

Her şey yolundaysa atrm ile görevi iptal edersiniz.

Değiştirmeden önce yedekleyin.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%F).bak

Konsol erişiminizi önceden test edin. Panelde konsolun açıldığını ve root parolasının çalıştığını kriz anında değil, sakin bir günde doğrulayın. Root parolasını bilmediğini kilitlendiğinde fark eden çok insan gördüm.

Birden fazla sunucunuz varsa bastion kurun. Tüm makineleri internete açmak yerine tek bir giriş noktası üzerinden yönetmek hem güvenliği hem kurtarılabilirliği artırır; kurulumu ssh jump host bastion sunucu yazısında.

Sistem yükünü izleyin. Bağlantının kopmasının bir nedeni de kaynak tükenmesidir; yük kaynaklı erişim sorunlarını sunucu yükü yüksek nedeni bulma yazısında ele aldım.

Sıkça Sorulan Sorular#

Sunucum ping atmıyor, kapalı mı demektir#

Hayır, ping yanıtı vermemek sunucunun kapalı olduğunu kanıtlamaz. Birçok sistem yöneticisi ICMP paketlerini güvenlik duvarında bilinçli olarak engeller; bu durumda makine sorunsuz çalışırken ping'e hiç cevap vermez. Doğru test, TCP seviyesinde bir port denemesidir: nc -zv sunucu-ip 80 veya 443 komutu yanıt veriyorsa sunucu kesinlikle ayaktadır ve sorun yalnızca SSH erişimindedir. Hiçbir port yanıt vermiyorsa sağlayıcı panelinden sunucunun durumunu ve kaynak grafiklerini kontrol edin; grafikler düz çizgiye döndüyse makine gerçekten durmuş demektir.

Connection timed out ile Connection refused arasındaki fark nedir#

Timed out paketin hedefe hiç ulaşmadığını, refused ise ulaştığını ama aktif olarak reddedildiğini gösterir. Bu ayrım teşhisi yarı yarıya kısaltır: zaman aşımı alıyorsanız suçlu neredeyse her zaman bir güvenlik duvarıdır (sunucu içindeki veya sağlayıcı panelindeki) ya da sunucu tamamen erişilemez durumdadır. Reddedildi mesajı alıyorsanız ağ yolu açıktır ve sorun servistedir; sshd çalışmıyor veya beklediğinizden farklı bir portta dinliyordur. İkinci durumda konsoldan ss -tlnp | grep sshd komutu sorunu tek satırda gösterir.

Güvenlik duvarını açtım ve bağlantım koptu, şimdi ne yapmalıyım#

Sağlayıcı panelindeki konsol veya VNC ekranından giriş yapıp SSH portunu güvenlik duvarında açmanız gerekir. Bu ekran ağdan bağımsız çalıştığı için tüm portlar kapalı olsa bile erişim sağlar. Girdikten sonra ufw allow 22/tcp veya firewall-cmd --permanent --add-service=ssh && firewall-cmd --reload komutunu çalıştırmanız yeterlidir. Bu senaryo, ufw enable komutunun varsayılan olarak gelen tüm trafiği reddetmesi ve SSH kuralının önceden eklenmemiş olması nedeniyle yaşanır; bir daha yaşamamak için güvenlik duvarını etkinleştirmeden önce daima SSH kuralını ekleyin.

SSH portunu değiştirdim, artık hiç bağlanamıyorum#

En olası üç neden şudur: yeni portu güvenlik duvarında açmadınız, RHEL ailesinde SELinux portu reddetti ya da yeni Ubuntu sürümlerinde socket aktivasyonu nedeniyle ayarınız hiç uygulanmadı. Konsoldan girip ss -tlnp | grep sshd ile hangi portun gerçekten dinlendiğini görün; hiç satır yoksa servis ayağa kalkamamıştır ve journalctl -u sshd -n 50 nedenini söyler. "Bind to port ... Permission denied" satırı görüyorsanız semanage port -a -t ssh_port_t -p tcp <port> komutuyla portu SELinux'a tanıtın. Port doğru görünüyorsa sorun güvenlik duvarındadır.

İnternet sağlayıcım 22 portunu kapatmış olabilir mi#

Evet, bu özellikle kurumsal ağlarda, üniversite ağlarında ve misafir Wi-Fi bağlantılarında oldukça yaygındır. Doğrulamanın en hızlı yolu telefonunuzun mobil verisiyle bağlanmayı denemektir; mobil veriden çalışıyor, mevcut ağdan çalışmıyorsa engel sizin bulunduğunuz ağdadır. Kalıcı çözüm SSH servisini 443 gibi neredeyse her ağda açık bırakılan bir porta taşımaktır. Alternatif olarak farklı bir ağda duran ve dışarıya açık bir ara sunucu üzerinden atlamalı bağlantı da kurabilirsiniz.

Konsoldan da giremiyorum, sunucu tamamen erişilemez#

Konsol ekranı hiç açılmıyor veya giriş satırı gelmiyorsa sunucu önyükleme aşamasında takılmış olabilir; panelden zorla yeniden başlatma yapın ve açılış çıktısını ekrandan izleyin. Dosya sistemi hatası varsa fsck çağrısı görünür ve elle onay bekliyor olabilir; disk tamamen dolduysa servisler açılırken hata verir. Ekranda hiçbir hareket yoksa sanallaştırma katmanında bir sorun olabilir ve bu noktada sağlayıcının teknik ekibine destek talebi açmak gerekir. Talebi açarken sunucu IP'sini, sorunun başladığı saati ve o sırada yaptığınız son değişikliği yazmanız çözüm süresini belirgin biçimde kısaltır.

Bağlantı kuruluyor ama birkaç saniye sonra kopuyor#

Bağlantının kurulup hemen kopması genellikle sunucu tarafındaki kaynak tükenmesine işaret eder; en sık nedeni diskin tamamen dolmasıdır. SSH oturum açarken geçici dosya yazamadığında oturum başlatılamaz ve bağlantı düşer. Konsoldan df -h ile kök bölümü kontrol edin, %100 görünüyorsa log dosyalarını temizleyerek yer açın. Diğer olasılıklar bellek tükenmesi nedeniyle sürecin OOM killer tarafından sonlandırılması ve ağ kararsızlığıdır; journalctl -u sshd ve dmesg | tail çıktıları hangisi olduğunu ayırt etmenizi sağlar.

Kapanış#

"Sunucuma bağlanamıyorum" krizinin çözümü tek bir sihirli komut değil, disiplinli bir eleme sırasıdır: önce kendi ağınızı, sonra sunucunun ayakta olup olmadığını, sonra güvenlik duvarını, en son SSH servisini kontrol edin. Aldığınız hata mesajını doğru okumak bu sırayı yarıya indirir — zaman aşımı güvenlik duvarını, reddedildi servisi, izin reddedildi ise kimlik doğrulamayı işaret eder. Ve her şey kapandığında elinizde kalan tek kapı sağlayıcı panelindeki konsoldur; onu kriz anında değil, bugün test edin.

Konsol/VNC erişimi olan bir ortamda çalışmak bu tür kilitlenmelerin çözülebilir kalmasını sağlar; VDS sunucu paketlerinde panel üzerinden konsol bağlantısı, yeniden başlatma ve root parola sıfırlama işlemlerini kendiniz yapabilirsiniz. Farklı sunucu tiplerini ve kaynak seçeneklerini karşılaştırmak için sunucu çözümleri sayfasına bakabilirsiniz. Güvenlik duvarı yapılandırması, izleme kurulumu ve kesinti anında müdahaleyi bir ekibin üstlenmesini isterseniz sunucu yönetimi hizmeti bu işleri devralır; sunucunuzun ayakta olup olmadığını sürekli izlemek için ise uptime SLA hesaplayıcı aracıyla hedeflerinizi somutlaştırabilirsiniz.