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

Kısa yanıt

SSH, uzak bir sunucuya şifreli bir kanal üzerinden bağlanmanızı sağlayan bir protokoldür. Temel Linux komutlarıyla birlikte kullanıldığında; dosya yönetimi, izinler, süreç takibi ve günlük kayıtları tek bir terminal oturumundan yürütürsünüz. Bu rehber, ilk bağlantıdan güvenlik sertleştirmesine kadar günlük işlerde en çok kullanılan komutları örneklerle anlatır.

Rehber; bağlantı kurma, dosya kopyalama, izinleri okuma, kaynak takibi ve günlük kayıtlarına bakma sırasını izler. Amaç komut ezberletmek değil, hangi iş için hangi aracın kullanılacağını göstermektir.

SSH nedir ve neyi korur?

SSH (Secure Shell), iki cihaz arasında şifreli bir tünel kuran uygulama katmanı protokolüdür. Sunucuya bağlandığınızda parolanız, çalıştırdığınız komutlar ve aktardığınız dosya içeriği ağ üzerinde açık metin olarak taşınmaz. OpenSSH’ın resmî el kitabı, protokolün taşıma, kullanıcı kimlik doğrulama ve bağlantı olmak üzere üç katmandan oluştuğunu açıklar: taşıma katmanı şifreleme ve sunucu doğrulamasını, kimlik doğrulama katmanı kullanıcının kim olduğunu, bağlantı katmanı ise oturum ve tünel akışlarını yönetir.

Günlük işlerde SSH şu amaçlarla kullanılır:

• Sunucuya komut satırından erişmek ve servisleri yönetmek
• Dosya ve dizinleri sunucuya aktarmak
• Veritabanı veya iç servislere güvenli tünel açmak
• Dağıtım, yedekleme ve bakım betiklerini uzaktan çalıştırmak

Burada kritik nokta şudur: SSH bağlantısı güvenli olsa bile yanlış izinler veya zayıf bir kimlik doğrulama yöntemi sunucuyu açık hâle getirir. Bu yüzden bağlantı kurmak kadar, bağlantının nasıl kurulduğu da önemlidir.

Anahtar üretimi: ssh-keygen ile parola yerine anahtar

Parolayla giriş, deneme yanılma saldırılarına açık ve paylaşılan tek bir sırdır. Ortak anahtar şifrelemesi ise sunucuda yalnızca açık anahtarın bulunmasını, özel anahtarın sizin cihazınızda kalmasını sağlar. Kendi cihazınızda bir anahtar çifti üretin:

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

Komut iki dosya oluşturur: ~/.ssh/id_ed25519 özel anahtar, ~/.ssh/id_ed25519.pub ise paylaşılabilir ortak anahtardır. Özel anahtarı hiçbir zaman e-posta veya mesajla göndermeyin; sızması hâlinde sunucuya erişim doğrudan ele geçirilmiş olur. Sorulan parola cümlesi (passphrase), anahtar dosyası çalınsa bile kullanılmasını engelleyen ikinci katmandır.

Ortak anahtarı sunucuya eklemenin en kolay yolu:

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

Komut, ortak anahtarı sunucudaki ~/.ssh/authorized_keys dosyasına ekler. Elle yapmak isterseniz ortak anahtarın içeriğini o dosyanın sonuna tek satır olarak ekleyebilirsiniz. Oturum boyunca anahtarı sürekli şifre girmek istemiyorsanız aracıyı kullanın:

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

Anahtarlı girişin pratik faydası şudur: her cihaz için ayrı anahtar üretip kaybedilen cihazın anahtarını sunucudan silebilirsiniz. Parolada ise tek bir sır tüm ekip için geçerli olduğundan, değiştirme maliyeti yüksektir.

Sunucuya bağlanma ve ~/.ssh/config ile kısayol

Temel bağlantı biçimi kullanıcı adı, sunucu adresi ve isteğe bağlı porttan oluşur:

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

Son satırdaki gibi bir komut verdiğinizde SSH oturum açmaz, komutu çalıştırıp çıktıyı ekrana basar ve bağlantıyı kapatır. Bu yöntem, betik içinden tek seferlik kontrol yapmak için pratiktir.

Uzun adresleri ve port numaralarını her seferinde yazmak yerine ~/.ssh/config dosyasında kısayol tanımlayın:

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

Bu tanımdan sonra yalnızca ssh proje yazmanız yeterlidir. Ekip çalışmasında birden fazla sunucu ve müşteri ortamı olduğunda bu dosya, hangi anahtarın hangi ortama ait olduğunu görünür kılar. İzinler konusunda katı olun: ~/.ssh dizini 700, config ve özel anahtar dosyaları 600 olmalıdır; izinler açık olduğunda SSH özel anahtarı kullanmayı reddeder.

Ara bir sunucu üzerinden hedefe gitmeniz gerekiyorsa atlama sunucusu özelliğini kullanın:

ssh -J kullanici@atlama-sunucusu hedef-sunucu

Dosya kopyalama: scp ve rsync

scp, tek dosya veya küçük dizinleri hızlıca aktarmak için yeterlidir:

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

rsync ise yalnızca değişen parçaları aktardığı için büyük dizinlerde ve yedekleme işlerinde belirgin biçimde daha verimlidir:

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

Sondaki eğik çizgi anlam taşır: ./site/ kaynak dizinin içeriğini hedefe kopyalar, ./site ise dizinin kendisini hedefin altına taşır. Yedekleme senaryolarında hedefte kaynakta bulunmayan dosyaları silmek için --delete kullanılır:

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

Uyarı: --delete hedefteki fazla dosyaları geri dönüşü olmadan siler. Bu yüzden önce mutlaka --dry-run ile hangi dosyaların silineceğini listeleyin; kaynak yolun yanlış yazılması hâlinde canlı dosyalarınızı kaybedebilirsiniz.

Sunucuda gezinme ve dosya işlemleri

Sunucuya bağlandıktan sonra yönünüzü bulmak için üç komut yeterlidir: pwd bulunduğunuz dizini, ls dizin içeriğini, cd ise dizin değiştirmeyi sağlar.

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

ls -la gizli dosyaları da listeler; .env gibi dosyaların fark edilmemesi yaygın bir hatadır. cp dizinleri kopyalamaz, dizin için cp -r gerekir. find ise ad, boyut veya tarih ölçütüyle arama yapmanızı sağlar; disk dolduğunda en büyük dosyaları bulmanın en hızlı yolu budur.

Silme komutlarında dikkatli olun:

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

Uyarı: rm dosyaları geri dönüşüm kutusuna taşımaz, kalıcı olarak siler. rm -rf özellikle tehlikelidir: değişken boş kaldığında komut kök dizini hedef alabilir. Betiklerde yolu doğrulayan bir koruma kullanın:

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

Dosya içeriğini görüntüleme ve arama

Küçük dosyalar için cat, uzun dosyalar için less uygundur. Günlük kayıtlarında genellikle baştan veya sondan bir bölüm yeterlidir:

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

tail -f dosyayı izlemeye devam eder; bir sorunu yeniden üretirken canlı kaydı görmek için en pratik yöntemdir. less içinde / ile arama yapabilir, q ile çıkabilirsiniz.

Metin aramada grep standart araçtı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" .

-i büyük küçük harf ayrımını kaldırır, -r dizini özyinelemeli tarar, -n satır numarasını gösterir, -c yalnızca eşleşme sayısını verir. Çok büyük dosyalarda cat kullanmak terminali kilitleyebilir; less, head ve tail daha güvenlidir.

Dosya izinleri: chmod, chown ve ls -l okuma

ls -l çıktısı izinleri, sahibi ve grubu tek satırda gösterir:

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

İlk karakter dosya türüdür (- normal dosya, d dizin). Ardından gelen dokuz karakter üçerli üç gruba ayrılır: sahip, grup ve diğerleri. Her grupta r okuma (4), w yazma (2), x çalıştırma (1) hakkını temsil eder. Buna göre 644 sahibe okuma yazma, diğerlerine yalnızca okuma verir; 755 dizinler ve çalıştırılabilir dosyalar için yaygındır.

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

Sahiplik değiştirmek ve izin değiştirmek genellikle sudo gerektirir. chown -R komutunu çalıştırmadan önce dizinin doğru olduğundan emin olun; yanlış bir kök dizinde çalıştırıldığında sistem dosyalarının sahipliğini bozabilir.

Uyarı: chmod 777 dosyayı sunucudaki herkese yazılabilir ve çalıştırılabilir yapar; web kökünde bu ayar, yüklenen bir betiğin sunucuda çalıştırılmasının önünü açar. chmod -R 777 ise sorunu çözüyormuş gibi görünürken güvenlik açığını kalıcı hâle getirir. Doğru yaklaşım, dosya türüne uygun izni vermek ve sahipliği servis kullanıcısına atamaktır. Ayrıca SSH, izinleri açık olan özel anahtarları yok sayar; Permission denied hatasının beklenmedik nedenlerinden biri budur.

Süreç ve kaynak takibi

Sunucu yavaşladığında veya bir servis yanıt vermediğinde önce hangi sürecin kaynak tükettiğine bakılır:

ps aux | grep nginx
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
top
df -h
du -sh /var/log/*

ps aux çalışan süreçleri listeler, top ise kaynak kullanımını canlı gösterir. htop kuruluysa renkli ve klavye dostu bir alternatiftir. df -h disk doluluk oranını, du -sh ise belirli bir dizinin toplam boyutunu verir. Disk dolması, veritabanı ve web servislerinin sessizce durmasının en sık nedenlerinden biridir; bu yüzden doluluk oranı düzenli izlenmelidir.

Servisleri yönetmek için systemctl kullanılır:

systemctl status nginx
sudo systemctl restart nginx
sudo systemctl enable --now nginx

status çıktısı servisin son durumunu ve son günlük satırlarını gösterir; restart yerine reload yeterli olduğunda bağlantılar kesilmez.

Günlük kayıtlar: journalctl ve /var/log

systemd kullanan sunucularda günlükler journalctl ile okunur:

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

-u belirli bir servisi, --since zaman aralığını, -p err yalnızca hata seviyesindeki kayıtları, -b ise mevcut açılışı filtreler. Servis çöktüğünde ilk bakılacak yer burasıdır.

systemd kullanmayan sistemlerde günlükler doğrudan dosya olarak tutulur:

ls /var/log
tail -n 50 /var/log/auth.log

/var/log/auth.log (bazı dağıtımlarda /var/log/secure) başarılı ve başarısız giriş denemelerini gösterir; sürekli başarısız denemeler görüyorsanız sunucu otomatik tarama altında demektir.

Güvenlik sertleştirme: sunucuyu sıkılaştırmak

Varsayılan kurulum, yönetimi kolay olsun diye geniştir. Üretim sunucusunda şu adımlar sırayla uygulanır:

• Normal bir kullanıcı oluşturup sudo yetkisi verin ve anahtarlı girişi test edin.
• sshd yapılandırmasında PermitRootLogin no ile root girişini kapatın.
• PasswordAuthentication no ile parolayla girişi devre dışı bırakın; bunu ancak anahtarlı giriş çalıştıktan sonra yapın.
• Güvenlik duvarında yalnızca gerekli portları açın.
• Otomatik güvenlik güncellemelerini etkinleştirin.

Değişiklikten sonra yapılandırmayı doğrulayın ve servisi yeniden başlatmak yerine yeniden yükleyin:

sudo sshd -t
sudo systemctl reload ssh

Uyarı: sshd yapılandırmasını bozan bir değişiklik, sunucudan tamamen kilitlenmenize yol açar. Çalışmanızı her zaman açık bir oturum varken yapın, sshd -t ile sözdizimini doğrulayın ve yeni bir terminalde giriş yapmayı denemeden mevcut oturumu kapatmayın. Servis adı dağıtıma göre ssh veya sshd olabilir.

Tekrarlayan başarısız giriş denemelerini otomatik engellemek için fail2ban yaygın bir çözümdür:

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

Port değiştirmek tek başına güvenlik sağlamaz; yalnızca otomatik taramaların gürültüsünü azaltır. Asıl koruma, anahtarlı giriş ve parola girişinin kapatılmasıdır.

Sık yapılan hatalar ve çözümleri

Permission denied (publickey)

Sunucu, sunduğunuz anahtarı kabul etmiyor demektir. Sırayla kontrol edin: ortak anahtar authorized_keys içinde mi, ~/.ssh dizini 700, özel anahtar 600 mı, doğru kullanıcı adı mı kullanılıyor? Ayrıntı için:

ssh -v kullanici@sunucu-adresi

-v çıktısı hangi anahtar dosyalarının denendiğini ve sunucunun hangi yöntemleri kabul ettiğini gösterir.

Host key verification failed

Sunucunun anahtarı değişmiş ya da kayıtlar uyuşmuyor demektir. Yeniden kurulum ve IP devri bu duruma yol açabilir; ancak aynı hata araya giren bir cihazın da işareti olabilir. Değişikliğin gerçekten beklenen bir işlemden kaynaklandığını doğruladıktan sonra eski kaydı silin:

ssh-keygen -R sunucu-adresi

Connection refused, timed out ve no route to host

Connection refused, hedefteki SSH servisinin çalışmadığını veya farklı bir portu dinlediğini gösterir; servis durumunu ve portu kontrol edin. timed out paketlerin hiç ulaşmadığını anlatır; güvenlik duvarı kuralı, yanlış IP adresi veya ağ kesintisi ilk bakılacak yerlerdir. no route to host ise ağ katmanında yönlendirme sorununa işaret eder.

Kontrol listesi

• Anahtar çifti üretildi ve özel anahtar parola cümlesiyle korunuyor.
• ~/.ssh izinleri 700, özel anahtar ve config dosyası 600.
• Sunucuya parolasız, anahtarla giriş yapılabiliyor.
• Sık kullanılan sunucular ~/.ssh/config içinde tanımlı.
• Yedekleme ve kopyalama işleri önce --dry-run ile denendi.
• Silme komutları çalıştırılmadan önce hedef yol doğrulandı.
• Web kökünde 777 gibi geniş izinler bulunmuyor.
• Disk doluluğu ve bellek kullanımı düzenli kontrol ediliyor.
• Kritik servislerin günlükleri journalctl ile izleniyor.
• Root girişi ve parolayla giriş kapatıldı, sshd -t ile doğrulandı.

Bu maddelerin çoğu tek seferde kurulur ve aylarca sorun çıkarmaz; asıl fark, bir sorun çıktığında hangi komuta bakacağınızı bilmektir. Anlatılan komutların ayrıntılı sözdizimi için OpenSSH’ın el kitabına ve ssh komutunun Linux man sayfasına bakabilirsiniz.

Sunucu yönetimini ekibe taşımak

Komut satırı, tek bir sunucuyu yönetmek için yeterlidir; ancak ekip büyüdükçe erişimlerin kimde olduğu, dağıtımın nasıl yapıldığı ve yedeklerin nerede durduğu soruları öne çıkar. Bu noktada SSH erişimi, dağıtım betikleri ve yapılandırma yönetimi birlikte ele alınmalıdır. Kendi altyapınızı kurumsal bir çatı altında toplamak isterseniz kurumsal yazılım çözümleri ve özel yazılım projeleri sayfalarımız kapsamı özetler.

Teslim ve ortam yönetimini bütün olarak kurmak için DevOps rehberimize, arama görünürlüğü ve indeksleme sorunları için teknik SEO, INP ve tarama bütçesi rehberimize bakabilirsiniz.

Grup şirketimiz Web Tasarım Ofisi, web projelerinde barındırma, sunucu kurulumu ve bakım tarafında ekiplere destek veriyor. Sunucu tarafını sağlam bir zemine oturtmak veya mevcut kurulumunuzu gözden geçirmek için bizimle iletişime geçebilirsiniz.