SSH ve temel Linux komutları: sunucu yönetimi için rehber

Kısa yanıt

SSH, uzak sunuculara şifreli kanal üzerinden bağlanmayı sağlayan temel protokoldür. Linux komutlarıyla birleştiğinde dosya yönetimi, izinler, süreçler ve sistem günlükleri tek terminal oturumundan yönetilir. İlk bağlantıdan güvenlik sıkılaştırmasına kadar günlük operasyonlarda en sık başvurulan ssh komutları pratik örneklerle ele alınarak altyapı işleriniz hızlandırılır.

Uzak sistemleri yönetirken bağlantı kurma, güvenli veri kopyalama, izin mekanizmasını kavrama, kaynak tüketimini izleme ve günlükleri inceleme sırasını takip etmek gerekir. Buradaki asıl amaç komutları tek tek ezberletmek yerine, hangi operasyonel problemde hangi araca başvurulacağını netleştirmektir.

SSH nedir ve neyi korur?

Secure Shell (SSH), iki cihaz arasında şifreli bir tünel kuran uygulama katmanı protokolüdür. Bir sunucuya bağlandığınızda parolanız, terminalde çalıştırdığınız komutlar ve aktardığınız dosya içerikleri yerel ağda ya da internet üzerinde asla açık metin olarak taşınmaz. OpenSSH platformunun resmî el kitabı protokolü üç katmanda ele alır. Taşıma katmanı veri şifrelemesini ve sunucu kimlik doğrulamasını yürütürken, kullanıcı doğrulama katmanı bağlanan kişinin yetkisini inceler. Bağlantı katmanı ise açılan sanal terminalleri, tünelleri ve eşzamanlı veri akışlarını tek bir hat üzerinden sorunsuz şekilde yönetir.

Sistem yöneticileri ve yazılım geliştiriciler gün boyunca SSH üzerinden farklı gereksinimleri karşılar. Sunucuya komut satırından erişip servisleri yönetmek, dosyaları hedef sistemlere güvenle aktarmak, doğrudan dışarıya açık olmayan veritabanlarına güvenli tüneller açmak ve dağıtım ya da bakım betiklerini uzaktan tetiklemek bu protokolün omurgasını oluşturur. SSH oturumu kendi içinde ne kadar güçlü kriptografik temellere dayanırsa dayansın, yanlış dosya izinleri veya zayıf bırakılmış parola mekanizmaları tüm sunucuyu savunmasız kılar. Güvenli bir altyapı için bağlantı aracını çalıştırmak kadar, kimlik doğrulama süreçlerinin nasıl kurgulandığı da hayati bir meseledir.

ssh-keygen ile anahtar tabanlı kimlik doğrulama nasıl yapılır?

Geleneksel parolalarla oturum açmak hem paylaşılan tek bir sırra dayanması hem de kaba kuvvet saldırılarına hedef olması sebebiyle ciddi güvenlik riskleri barındırır. Asimetrik anahtar şifrelemesi ise sunucu tarafında sadece açık anahtarın barındırılmasını, özel anahtarın ise yalnızca yetkili istemcinin yerel cihazında saklanmasını şart koşar. Modern sistemlerde güvenliği yüksek ve performanslı bir anahtar çifti oluşturmak için standart üretim komutuyla sürece başlanır:

Ssh-keygen -t ed25519 -C "[email protected]"

İşlem tamamlandığında sistem ~/.ssh/id_ed25519 yolunda gizli kalması gereken özel anahtarı, ~/.ssh/id_ed25519.pub yolunda ise her ortamda paylaşılabilecek ortak anahtarı üretir. Özel anahtar dosyasını hiçbir koşulda sohbet uygulamalarından ya da e-posta üzerinden paylaşmamanız gerekir çünkü bu dosyanın başkasına geçmesi doğrudan sunucu yetkisinin devredilmesi anlamına gelir. Üretim sırasında belirlenen parola cümlesi (passphrase), yerel cihazınız çalınsa dahi dosyanın üçüncü kişilerce kullanılmasını engelleyen sağlam bir zırhtır.

Oluşturduğunuz ortak anahtarı uzak sunucuya aktarmanın en zahmetsiz yöntemi kopyalama aracını çalıştırmaktır:

Ssh-copy-id -i ~/.ssh/id_ed25519.pub kullanici@sunucu-adresi

Bu araç ortak anahtar satırını sunucudaki ~/.ssh/authorized_keys dosyasının en altına güvenli biçimde ekler. Komutun bulunmadığı sistemlerde genel anahtar metni kopyalanarak ilgili dosyanın sonuna elle de yerleştirilebilir. Her bağlantı denemesinde aynı parola cümlesini girmekten kurtulmak için bellek içi aracı devreye alınır:

Eval "$(ssh-agent -s)"
Ssh-add ~/.ssh/id_ed25519

Anahtar tabanlı doğrulama operasyonel esneklik sağlar. Ekibe yeni biri katıldığında veya bir cihaz kaybolduğunda, yalnızca ilgili açık anahtarı sunucudaki yetkili anahtarlar dosyasından silmek yeterli olur. Bütün ekibin bildiği tek bir parola kullanıldığında ise her personel değişiminde parola yenilemek ciddi bir iş yükü ve risk doğurur.

Sunucu bağlantısı ve ~/.ssh/config dosyası için ssh komutları nasıl yapılandırılır?

Uzak bir makineye erişirken kullanılan temel komut yapısı kullanıcı adını, hedef sunucu adresini ve gerekiyorsa port bilgisini içerir:

Ssh kullanici@sunucu-adresi
Ssh -p 2222 kullanici@sunucu-adresi
Ssh kullanici@sunucu-adresi "uptime"

Üçüncü örnekte olduğu gibi komutun sonuna tırnak içinde bir komut eklendiğinde SSH tam bir kabuk oturumu başlatmaz. İlgili komutu uzak sistemde yürütür, çıktısını yerel terminale aktarır ve bağlantıyı kendiliğinden sonlandırır. Bu yaklaşım özellikle otomatik dağıtım betiklerinde ve anlık durum kontrollerinde büyük kolaylık sağlar. Farklı sunucu adreslerini, özel portları ve anahtar yollarını sürekli akılda tutmak yerine ~/.ssh/config dosyasında pratik tanımlar yapabilirsiniz:

Host proje
 HostName 203.0.113.10
 User deploy
 Port 2222
 IdentityFile ~/.ssh/id_ed25519

Böyle bir blok oluşturduktan sonra terminale yalnızca ssh proje yazarak tanımlanan parametrelerle sisteme doğrudan ulaşabilirsiniz. Geliştirme, test ve canlı ortamlar gibi çok sayıda sunucuyla çalışırken yapılandırma dosyası hangi projenin hangi anahtarla eşleştiğini düzenli tutar. Burada dosya izinlerine hassasiyet gösterilmelidir; ~/.ssh dizini 700, içerideki config ve özel anahtar dosyaları ise 600 izin koduna sahip olmalıdır. İzinleri gereğinden fazla açık olan anahtarları OpenSSH güvenlik nedeniyle işleme almaz. Doğrudan erişime kapalı olan iç ağdaki bir makineye ara bir sunucu üzerinden atlayarak bağlanmak gerektiğinde ise tünelleme parametresi devreye girer:

Ssh -J kullanici@atlama-sunucusu hedef-sunucu

scp ve rsync ile dosya transferi için ssh komutları nasıl kullanılır?

Tekil dosyaları veya ufak boyutlu klasörleri karşı tarafa hızla yüklemek ya da sunucudan yerele çekmek istediğinizde scp aracı doğrudan işinizi görür:

Scp rapor.txt kullanici@sunucu:/var/www/site/
Scp -r ./yerel-klasor kullanici@sunucu:/var/www/
Scp kullanici@sunucu:/var/log/nginx/error.log ./

Geniş veri yapıları, binlerce dosyadan oluşan dizinler veya periyodik yedeklemeler olduğunda rsync devreye girmelidir. Sadece değişen veri bloklarını aktardığı ve transferi sıkıştırabildiği için bant genişliğini son derece verimli kullanır:

Rsync -avz --progress ./site/ kullanici@sunucu:/var/www/site/

Dizin adının sonuna koyulan eğik çizgi karakteri transferin yapısını tümüyle değiştirir. Kaynak dizin sonuna / koyduğunuzda klasörün içindeki tüm dosyalar hedefin içine boşaltılır; eğik çizgi konulmadığında ise dizin klasörün kendisiyle birlikte karşı tarafa taşınır. Sunucuda kaynakta artık bulunmayan dosyaları ayıklayıp tam bir eşitleme sağlamak için silme anahtarından yararlanılır:

Rsync -avz --delete --dry-run ./site/ kullanici@sunucu:/var/www/site/

Hedefteki fazla dosyaları kalıcı olarak silen --delete bayrağı dikkatsiz kullanıldığında ciddi veri kaybına yol açar. Bu riski bertaraf etmek için komutu önce --dry-run parametresiyle tetikleyerek hangi dosyaların silinmek üzere listelendiğini ekrandan dikkatle incelemek gerekir.

Sunucuda dosya gezinme ve yönetim adımları nelerdir?

SSH üzerinden bağlandığınız uzak Linux kabuğunda hareket edebilmek için temel dizin komutlarını bilmeniz gerekir. Bulunulan dizini öğrenmek için pwd, mevcut konumu değiştirmek için cd, içerikleri dökmek içinse ls komutuna başvurulur.

Pwd
Ls -la
Cd /var/www/site
Mkdir -p yedek/2026
Cp config.php config.php.bak
Mv eski.log arsiv/eski.log
Find /var/www -name "*.log" -size +100M

Gizli yapılandırma dosyalarını gözden kaçırmamak adına dizinleri her zaman ls -la parametresiyle listelemek alışkanlık hâline getirilmelidir. Dizinleri başka bir noktaya çoğaltırken cp -r gibi yinelemeli bayraklar kullanılır. Diskte yer kalmadığında ya da eski kayıtlar arandığında find komutu; isim, dosya boyutu veya değişiklik tarihi gibi filtrelerle en kritik verileri saniyeler içinde tespit eder. Kullanılmayan verileri sunucudan kaldırırken dosya silme komutları geri dönüşü olmayan sonuçlar üretebilir:

Rm eski-yedek.tar.gz
Rm -r arsiv/2024

Linux dosya sistemlerinde rm komutuyla silinen öğeler herhangi bir çöp kutusuna gitmeden doğrudan disk bloklarından düşürülür. Özellikle içi dolu klasörleri silerken kullanılan rm -rf yapısı, tanımsız bir kabuk değişkeniyle birleştiğinde kök dizinin temizlenmesine neden olabilir. Olası felaketleri önlemek için betiklerde değişkenin tanımlı olup olmadığını denetleyen koruma blokları tercih edilmelidir:

Rm -rf -- "${HEDEF_DIZIN:?HEDEF_DIZIN tanimli degil}"

Sunucudaki dosyalar nasıl incelenir ve aranır?

Kısa metinleri veya ayar dosyalarını hızlıca ekrana basmak için cat kullanılırken, binlerce satırdan oluşan kayıt dosyalarında less terminali kilitlemeden gezinme olanağı tanır. Canlı log akışlarında ise dosyanın en alt satırlarına odaklanmak daha verimli bir inceleme sağlar:

Cat /etc/hostname
Less /var/log/nginx/access.log
Head -n 20 rapor.csv
Tail -n 50 /var/log/syslog
Tail -f /var/log/nginx/error.log

Servis hatalarını anlık simüle ederken tail -f komutu dosyaya düşen yeni kayıtları kesintisiz şekilde ekrana akıtır. less aracılığıyla açılan devasa dosyalarda / tuşuna basarak metin araması yapabilir, q harfine basarak terminale geri dönebilirsiniz. Metinler ve log dizinleri arasında belirli bir anahtar kelimeyi bulmak için Linux dünyasının en temel filtreleme aracı grep kullanılır:

Grep -i "error" /var/log/syslog | tail -n 30
Grep -rn "TODO" ./src
Grep -c "GET /api" /var/log/nginx/access.log
Grep -rn --exclude-dir=node_modules "apiKey" .

Komuttaki -i parametresi arama yaparken büyük-küçük harf duyarlılığını ortadan kaldırır, -r dizinlerin derinliklerine kadar iner ve -n satır numarasını listeler. Eşleşen içeriklerin kendisi yerine sadece toplam satır adedini öğrenmek istediğinizde -c bayrağı devreye girer. Yüzlerce megabaytlık log dosyalarını cat ile açmaya çalışmak oturumu dondurabileceğinden, her zaman less veya tail üzerinden çalışılmalıdır.

Dosya izinleri ve mülkiyet yapısı nasıl yönetilir?

Bir dosyanın kim tarafından okunabileceği veya çalıştırılabileceği ls -l çıktısındaki sütunlardan takip edilir:

-rw-r--r-- 1 deploy www-data 4096 Sep 18 10:12 config.php

Satırın en başındaki simge dosyanın türünü belirtir; tire işareti standart dosyayı, d harfi ise dizini temsil eder. Sonraki dokuz karakter üçerli bloklar hâlinde dosya sahibinin, grubun ve diğer kullanıcıların yetkilerini sıralar. Buradaki r okuma (4), w yazma (2), x ise çalıştırma (1) yetkisidir. Dolayısıyla 644 değeri dosya sahibine okuma-yazma, dış dünyaya ise yalnızca okuma hakkı verir; dizinler ve betik dosyaları için çoğunlukla 755 tercih edilir.

Chmod 644 config.php
Chmod 600 ~/.ssh/id_ed25519
Chmod +x deploy.sh
Chown deploy:www-data /var/www/site/config.php
Chown -R deploy:www-data /var/www/site/uploads

Kullanıcı ve grup sahipliklerini düzenlemek genellikle yetkili kullanıcı hakları gerektirir. Klasör altındaki tüm nesneleri kapsayan chown -R komutunu çalıştırmadan önce yolu defalarca doğrulamak gerekir; yanlış bir konumda işletildiğinde sistem kütüphanelerinin yetki dengesi bozulabilir. Güvenlik zaafiyetlerinin başında gelen chmod 777 ataması, sistemdeki herkese dosyayı değiştirme ve çalıştırma hakkı sunar. Web kök dizininde yer alan bir klasöre bu izni vermek, dışarıdan yüklenen zararlı bir betiğin sunucu çekirdeğinde yürütülmesine zemin hazırlar. İzinleri kontrolsüzce açmak yerine dosyanın ait olduğu servise özel kullanıcı grubu tanımlanmalı ve asgari yetki prensibi uygulanmalıdır. Özel anahtar dosyalarının izinleri gevşek tutulduğunda ssh komutları bağlantıyı doğrudan iptal eder.

Sunucu süreçleri ve sistem kaynakları nasıl izlenir?

Web uygulaması yavaşladığında veya arka plan servisleri kilitlendiğinde işlemci ve bellek kaynaklarını tüketen işlemlerin analiz edilmesi gerekir:

Ps aux | grep nginx
Ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
Top
Df -h
Du -sh /var/log/*

Çalışan tüm süreçleri detaylarıyla döken ps aux çıktısı belirli süreçleri yakalamayı sağlarken, top aracı terminal üzerinde dinamik bir kaynak takip ekranı sunar. Diskteki genel doluluk yüzdesini df -h üzerinden takip etmek, hangi klasörün aşırı şiştiğini ise du -sh ile adım adım tespit etmek mümkündür. Dolup taşan bir disk alanı, veritabanı servislerinin aniden çökmesine ve log yazılamadığı için sistemlerin kilitlenmesine yol açan en yaygın operasyonel aksaklıktır. İşletim sistemindeki servislerin genel yaşam döngüsü systemctl altyapısı üzerinden yönetilir:

Systemctl status nginx
Sudo systemctl restart nginx
Sudo systemctl enable --now nginx

Servis durumunu inceleyen status parametresi, hem sürecin ayakta olup olmadığını bildirir hem de son log kayıtlarını ekrana dökerek arıza kaynağını gösterir. Ayar değişikliklerinde servisi tümden yeniden başlatmak yerine reload komutunu işletmek, mevcut istemci bağlantılarını koparmadan yapılandırmayı devreye alır.

Sistem günlükleri ve journalctl nasıl incelenir?

Modern Linux dağıtımlarında systemd tarafından yönetilen servislerin kayıtları journalctl komut setiyle taranır:

Journalctl -u nginx -n 100
Journalctl -u ssh --since "1 hour ago"
Journalctl -p err -b
Journalctl -f

Belirli bir servisin loglarını -u bayrağıyla sınırlandırabilir, --since filtresiyle son bir saatteki olayları yakalayabilir ve -p err ile önemsiz satırları eleyip yalnızca kritik hataları ayıklayabilirsiniz. Servis çökmelerinde kök nedene ulaşmak için ilk başvurulması gereken mekanizma bu filtredir. Kayıtlarını doğrudan metin tabanlı tutan servislerde ise dosya sistemi üzerinden inceleme sürdürülür:

Ls /var/log
Tail -n 50 /var/log/auth.log

Yetkilendirme kayıtlarını tutan /var/log/auth.log veya dağıtıma göre /var/log/secure dosyası, sisteme giriş denemelerini tüm ayrıntısıyla listeler. Dosya içerisinde peş peşe yüzlerce başarısız giriş denemesi görüyorsanız, sunucunuz internet üzerindeki botnet ağları tarafından parola deneme taramasına maruz kalıyor demektir.

Temel güvenlik sertleştirme adımları nelerdir?

Varsayılan işletim sistemi kurulumları geniş erişim yetkileriyle gelir ve internete bağlandıkları anda tehditlere açık hâle gelir. Güvenli bir üretim ortamı için sshd üzerinde root girişinin kapatılması, normal kullanıcıya sudo yetkisi tanımlanması, parola ile kimlik doğrulamanın devre dışı bırakılması, güvenlik duvarının asgari porta indirilmesi ve düzenli güvenlik yamalarının kurulması adımları şarttır. Yapılandırma dosyasında değişiklik yaptıktan sonra servisi yeniden başlatmadan önce sözdizimi doğrulanmalı ve yeni kurallar servis kesilmeden yüklenmelidir:

Sudo sshd -t
Sudo systemctl reload ssh

Yapılandırma dosyasındaki ufak bir yazım hatası SSH servisinin çökmesine ve sunucuya olan erişimin tamamen kaybolmasına neden olabilir. Bu sebeple mevcut oturum asla kapatılmadan önce sshd -t komutuyla test yapılmalı ve yeni bir uçbirim penceresinden sunucuya yeniden bağlanılabildiği mutlaka doğrulanmalıdır. Ağ üzerinden yürütülen kaba kuvvet saldırılarını otomatik savuşturmak için ilgili servis devreye alınır:

Sudo apt install fail2ban
Sudo systemctl enable --now fail2ban
Sudo fail2ban-client status sshd

SSH portunu 22 yerine başka bir sayıya taşımak saldırı gürültüsünü azaltsa da tek başına güvenlik sağlamaz. Asıl koruma katmanı, parolayla girişi tümüyle yasaklayıp yalnızca anahtar tabanlı doğrulamaya izin vermektir.

Sık karşılaşılan SSH hataları nasıl çözülür?

Permission denied (publickey)

Bu arıza, sunucunun istemci tarafından sunulan şifreleme anahtarını doğrulamayı reddettiği durumlarda karşınıza çıkar. Çözüm için istemcideki açık anahtarın uzak sunucudaki authorized_keys içine eklenip eklenmediği, ~/.ssh dizin izninin 700 ve dosya izinlerinin 600 olup olmadığı denetlenmelidir. Hatanın perde arkasını görmek için bağlantı ayrıntılı modda başlatılmalıdır:

Ssh -v kullanici@sunucu-adresi

Terminalde üretilen -v çıktısı, istemcinin sunucuya hangi özel anahtarları sunduğunu ve sunucunun hangi kimlik doğrulama modellerini kabul ettiğini adım adım gösterir.

Host key verification failed

Uzak sunucunun kimlik parmak izi istemcinin known_hosts dosyasındaki kayıtla uyuşmadığında güvenlik gereği bağlantı anında koparılır. Sunucuya yeni bir işletim sistemi kurulduğunda veya IP adresi el değiştirdiğinde bu uyarı normaldir; ancak beklenmedik bir anda ortaya çıkıyorsa aradaki trafiği dinlemeye çalışan bir saldırganın varlığına işaret edebilir. Durumun sunucudaki meşru bir yeniden kurulumdan kaynaklandığından eminseniz eski parmak izi kaydını yerelinizden silebilirsiniz:

Ssh-keygen -R sunucu-adresi

Connection refused, timed out ve no route to host

Connection refused uyarısı, paketin karşı sunucuya ulaştığını fakat hedeflenen port üzerinde hiçbir SSH servisinin dinleme yapmadığını ya da yerel bir güvenlik duvarının bağlantıyı doğrudan reddettiğini gösterir. timed out çıktısı gönderilen veri paketlerine hiçbir yanıt dönmediğini anlatır; bulut panelindeki güvenlik grupları veya fiziksel ağ erişimindeki kısıtlamalar kontrol edilmelidir. no route to host uyarısı ise yerel ağ geçidinin hedef IP adresine ulaşabilecek bir yönlendirme yolu bulamadığını ortaya koyar.

Sunucu güvenliği için operasyonel kontrol listesi

• Güçlü bir şifreleme algoritmasıyla anahtar çifti oluşturulup parola cümlesiyle kilitlendi.
• İstemci ve sunucu tarafındaki .ssh dizin izinleri 700, özel anahtarlar 600 olarak sınırlandı.
• Sunucuya parola girmeden, yalnızca anahtar çiftiyle erişim sağlandığı test edildi.
• Günlük çalışılan tüm ortamlar ~/.ssh/config dosyasına kaydedilerek kısayollar oluşturuldu.
• rsync ile veri taşımadan önce --dry-run bayrağıyla silinecek veya eklenecek dosyalar gözden geçirildi.
• Yıkıcı silme komutları öncesinde hedef dizin değişkenlerinin doluluğu doğrulandı.
• Web dizinlerinde ve paylaşılan alanlarda chmod 777 gibi sınırsız izinler tümüyle kaldırıldı.
• Disk doluluk seviyeleri ve aşırı bellek tüketen işlemler periyodik incelemeye alındı.
• Servislerin durumları ve çökme sebepleri düzenli olarak journalctl üzerinden izlendi.
• Uzak sunucuda doğrudan root erişimi engellendi, parola doğrulama kapatıldı ve sshd -t ile sözdizimi sınandı.

Yukarıdaki güvenlik adımları sisteme bir kere uygulandığında sunucu operasyonlarını uzun süre güvende tutar; kritik olan arıza anında doğru komutla müdahale edebilmektir. Kullandığınız araçların detaylı çalışma mantığını anlamak için OpenSSH tarafından hazırlanan resmî el kitabına ve doğrudan ssh protokolünün Linux man sayfasına göz atabilirsiniz.

Sunucu yönetimini ekibe taşımak

Ufak çaplı projelerde birkaç sunucuyu terminalden komutlarla yönetmek pratik görünse de, organizasyon genişledikçe sunucu yetkilerini bölüştürmek ve sürümleri kontrol altında tutmak karmaşıklaşır. Bu aşamada ssh komutları ile yürütülen manuel işler yerini otomatik dağıtım betiklerine, merkezi kimlik yönetimine ve modern altyapı standartlarına bırakmalıdır. Kendi dijital varlıklarınızı sürdürülebilir bir sistem mimarisine kavuşturmak isterseniz kurumsal yazılım çözümleri ve özel yazılım projeleri sayfalarımızdan sunduğumuz kapsamı inceleyebilirsiniz.

Sistem dağıtımlarını, otomatik testleri ve sunucu süreçlerini uçtan uca otomatikleştirmek için DevOps rehberimize bakabilir; arama motoru performansı ile sunucu yanıt süreleri arasındaki dengeyi kurmak için teknik SEO, INP ve tarama bütçesi rehberimize göz atabilirsiniz. Grup şirketimiz Web Tasarım Ofisi, kurumsal web uygulamalarında altyapı barındırma, güvenli sunucu konfigürasyonu ve kesintisiz bakım konularında şirketlere uzman desteği sağlar. Sunucu ortamlarınızı modern güvenlik standartlarına taşımak ve altyapınızı güçlendirmek için bizimle iletişime geçebilirsiniz.