Sunucuda Root ile Çalışmak Neden Riskli? Kullanıcı Açma Rehberi

Yönetimsiz bir VDS aldınız, e-postadaki root bilgileriyle bağlandınız ve her şeyi o hesapla yapmaya başladınız: paket kurulumu, dosya kopyalama, servis yeniden başlatma, hatta rm -rf ile temizlik. Bir süre sonra bir yerde "root girişini kapatın" tavsiyesini okuyup PermitRootLogin no satırını yazdınız, SSH'ı yeniden başlattınız ve oturumu kapattınız. Şimdi sunucunuza hiçbir şekilde giremiyorsunuz. Bu senaryo forumlarda haftada birkaç kez sorulur ve nedeni hep aynıdır: root yerine kullanıcı oluşturma adımı atlanıp doğrudan kapatma adımına geçilmiştir.

Bu yazıda sunucuda sürekli root kullanmanın somut risklerini, sudo yetkili bir kullanıcının nasıl açılacağını, SSH anahtarının bu yeni kullanıcıya nasıl taşınacağını ve root girişini kilitlenmeden nasıl kapatacağınızı anlatacağım. Türkçe kaynakların çoğu ya sadece adduser komutunu verir ya da sadece PermitRootLogin no satırını gösterir; ikisinin doğru sırası, aradaki anahtar kopyalama adımı ve "ikinci bir oturum açmadan ilkini kapatma" kuralı bir arada neredeyse hiçbir yerde yoktur. Aşağıdaki sıralamaya harfiyen uyarsanız kilitlenme ihtimaliniz sıfıra yakındır.

Sunucuda Root ile Çalışmak Neden Riskli#

Root, Linux'ta hiçbir yetki kontrolüne tabi olmayan tek hesaptır; dosya izinleri, sahiplik kontrolleri ve çekirdek düzeyindeki kısıtlar root için geçerli değildir. Bu, hem gücünün hem de riskinin kaynağıdır.

Riski dört başlıkta toplayabiliriz:

1. Yazım hatası geri alınamaz. rm -rf /var/www /html yazmak ile rm -rf /var/www/html yazmak arasında bir boşluk fark vardır; root olarak ilkini yazdığınızda sistem size hiçbir şey sormaz. Normal bir kullanıcı olarak aynı komut Permission denied verir ve siz hatayı fark edersiniz. Yıllardır gördüğüm en pahalı veri kayıplarının önemli bir kısmı bu tek boşluktan çıkmıştır.

2. Kaçak dosya sahiplikleri. Root olarak bir web dizinine dosya kopyaladığınızda dosyalar root:root sahipliğiyle oluşur. Web sunucusu (www-data, apache, nginx) o dosyaları okuyabilir ama yazamaz; sonra "WordPress eklenti güncellemesi FTP bilgisi istiyor" ya da "yükleme dizinine yazılamıyor" hataları başlar. Sonra çözüm diye chmod -R 777 yapılır ve bu kez gerçek bir güvenlik açığı doğar. Bu zincirin başlangıcı root ile çalışmaktır.

3. Kimin ne yaptığı belli olmaz. Ekipte üç kişi varsa ve üçü de root ile giriyorsa, auth.log dosyasında yalnızca "root giriş yaptı" satırları görürsünüz. Bir yapılandırma bozulduğunda kimin ne zaman ne yaptığını bulamazsınız. Herkesin kendi kullanıcısı olduğunda ise sudo her ayrıcalıklı komutu kullanıcı adıyla birlikte günlüğe yazar:

Aug 11 10:22:41 srv1 sudo: mehmet : TTY=pts/0 ; PWD=/etc/nginx ; USER=root ; COMMAND=/bin/systemctl reload nginx

4. Otomatik saldırıların hedefi hazır. İnternete açık her sunucunun 22 numaralı portuna sürekli parola denemesi gelir ve bu denemelerin ezici çoğunluğu root kullanıcı adıyla yapılır. Saldırganın bilmesi gereken tek şey parolanızdır, çünkü kullanıcı adı zaten evrensel olarak bilinir. Kendi sunucunuzda bunu şöyle görebilirsiniz:

sudo grep 'Failed password' /var/log/auth.log | grep -c 'for root'

Kullanıcı adınızı root dışında bir şey yaptığınızda saldırganın tahmin etmesi gereken iki bilgi olur ve otomatik botların büyük kısmı devre dışı kalır.

Karşılaştırma tablosu, iki yaklaşımın farkını netleştirir:

Doğru Sıra: Önce Kullanıcı, Sonra Root Girişini Kapatma#

Bu yazının en kritik bölümü budur. Sıralama şu şekildedir ve hiçbir adım atlanmaz:

1. Yeni kullanıcıyı oluşturun ve parolasını belirleyin.

2. Kullanıcıya sudo yetkisi verin.

3. SSH genel anahtarınızı bu kullanıcının authorized_keys dosyasına kopyalayın.

4. Mevcut root oturumunuzu KAPATMADAN ikinci bir terminal açıp yeni kullanıcıyla giriş yapın.

5. İkinci oturumda sudo whoami çalıştırıp root yanıtı aldığınızı doğrulayın.

6. Ancak bundan sonra sshd_config içinde root girişini kapatın.

7. Yapılandırmayı sshd -t ile sözdizimi açısından test edin.

8. SSH servisini yeniden yükleyin.

9. Üçüncü bir terminalde yeniden giriş yapıp her şeyin çalıştığını doğrulayın.

10. Şimdi ilk root oturumunu kapatabilirsiniz.

11. adımı atlayan herkes er ya da geç kilitlenir. Nedeni şudur: sshd yapılandırması yeniden yüklendiğinde mevcut oturumlar kapanmaz, yalnızca yeni bağlantılar yeni kurallara tabi olur. Yani elinizde açık bir root oturumu varken hatalı bir yapılandırma yazsanız bile o oturumdan geri düzeltebilirsiniz. Oturumu kapattığınız anda bu güvenlik ağı kaybolur.

Sudo Yetkili Kullanıcı Nasıl Oluşturulur#

Debian ve Ubuntu'da adduser betiği en pratik yoldur; ev dizinini oluşturur, kabuk atar, parolayı sorar:

adduser mehmet

Çıktı şöyledir:

Adding user `mehmet' ...
Adding new group `mehmet' (1001) ...
Adding new user `mehmet' (1001) with group `mehmet' ...
Creating home directory `/home/mehmet' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully

AlmaLinux, Rocky Linux ve RHEL ailesinde adduser yoktur, useradd vardır ve parolayı ayrı belirlemeniz gerekir:

useradd -m -s /bin/bash mehmet
passwd mehmet

-m ev dizinini oluşturur, -s /bin/bash giriş kabuğunu atar. Bu ikisini unutursanız kullanıcı SSH'a girer ama ev dizini olmaz ve $HOME hataları başlar.

Parolayı belirlerken uzun ve rastgele bir dize seçin; bu hesabın parolası artık sunucunuzun ana kapısıdır. Ayrıntılar için sunucu root şifresi değiştirme yazısındaki parola bölümüne bakabilirsiniz.

Sudo yetkisi verme#

Yetki, kullanıcıyı doğru gruba eklemekle verilir ve grup adı dağıtıma göre değişir:

# Debian / Ubuntu
usermod -aG sudo mehmet

# AlmaLinux / Rocky / CentOS / RHEL
usermod -aG wheel mehmet

⚠️ -a bayrağını asla unutmayın. usermod -G sudo mehmet yazarsanız kullanıcının mevcut tüm ek grupları silinir ve yerine yalnızca sudo yazılır. Bu, www-data ya da docker grubundaki bir kullanıcının yetkisini sessizce kaybetmesine yol açar.

Yetkiyi doğrulayın:

groups mehmet
sudo -l -U mehmet

İkinci komutun çıktısında (ALL : ALL) ALL satırını görüyorsanız iş tamamdır. Grup ve kullanıcı yönetiminin tamamı için Linux kullanıcı ve grup yönetimi yazısına bakın.

Grup değişikliği neden hemen etkili olmuyor#

Sık karşılaşılan bir tuzak: kullanıcıyı gruba eklediniz ama o kullanıcı zaten açık bir oturumdaysa sudo hâlâ "kullanıcı sudoers dosyasında değil" diyor. Sebep, grup üyeliklerinin oturum açılırken hesaplanmasıdır. Kullanıcının oturumu kapatıp yeniden açması gerekir. Test amaçlı hemen görmek isterseniz:

su - mehmet
groups

SSH Anahtarını Yeni Kullanıcıya Kopyalama#

Parolayla giriş kuracaksanız bu adımı atlayabilirsiniz, ama önerim anahtarla girmeniz yönünde. Anahtarınız root'un authorized_keys dosyasındaysa yeni kullanıcıya kopyalanması gerekir — aksi hâlde root girişini kapattığınızda anahtarınız da işlevsiz kalır.

En temiz yöntem, kendi bilgisayarınızdan ssh-copy-id çalıştırmaktır:

ssh-copy-id mehmet@sunucu-ip

Bu komut parolayla bir kez bağlanır, dizini ve dosyayı doğru izinlerle oluşturur, anahtarı ekler. Anahtarınız yoksa önce üretmeniz gerekir; adımlar için SSH anahtarı nasıl oluşturulur yazısına bakın.

Sunucu üzerinde root'un anahtarlarını yeni kullanıcıya taşımak isterseniz, izinlere dikkat ederek şunu yapın:

mkdir -p /home/mehmet/.ssh
cp /root/.ssh/authorized_keys /home/mehmet/.ssh/authorized_keys
chown -R mehmet:mehmet /home/mehmet/.ssh
chmod 700 /home/mehmet/.ssh
chmod 600 /home/mehmet/.ssh/authorized_keys

Bu dört satırdaki chown ve chmod adımları isteğe bağlı değildir. OpenSSH, izinleri fazla gevşek olan bir .ssh dizinini ya da authorized_keys dosyasını sessizce yok sayar ve size yalnızca Permission denied (publickey) der. Sunucu tarafında /var/log/auth.log dosyasında ise şu satırı görürsünüz:

Authentication refused: bad ownership or modes for directory /home/mehmet/.ssh

Aynı hata ev dizininin kendisi grup yazılabilir olduğunda da çıkar; chmod 755 /home/mehmet ile düzeltilir. Bu hata ailesinin tamamı için SSH permission denied publickey hatası yazısına bakabilirsiniz.

İkinci Oturumla Test Etme#

Bu adım, tüm yazının sigortasıdır. Mevcut root oturumunuz açık kalacak. Yeni bir terminal penceresi (Windows'ta yeni bir PuTTY oturumu) açın ve yeni kullanıcıyla bağlanın:

ssh mehmet@sunucu-ip

Bağlandıktan sonra üç şeyi sırayla doğrulayın:

whoami
# mehmet

sudo whoami
# [sudo] password for mehmet:
# root

sudo systemctl status sshd --no-pager

Üçünün de beklendiği gibi çalıştığını gördüyseniz devam edebilirsiniz. Herhangi biri hata verdiyse root girişini kapatmayın, önce sorunu ilk oturumdan düzeltin.

Bu noktada sudo her seferinde parola soruyor diye rahatsız olabilirsiniz. Bu bir kusur değil, özelliktir: makinenizin başından kalktığınızda açık kalan bir terminal, parola sorulmadığı takdirde tam yetkili bir kapı olur. Varsayılan olarak parola bir kez girildiğinde 15 dakika sorulmaz; bu süreyi sudoers içinden ayarlayabilirsiniz.

SSH'ta Root Girişini Kapatma#

Artık güvenli biçimde kapatabilirsiniz. Yapılandırma dosyası /etc/ssh/sshd_config. Modern dağıtımlarda /etc/ssh/sshd_config.d/ altında da parça dosyalar bulunur ve bu parçalar ana dosyayı ezebilir; bu yüzden düzenlemeyi orada yapmak daha temizdir:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

İçerik:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers mehmet
MaxAuthTries 3

Satırların anlamı:

• PermitRootLogin no — root SSH ile hiçbir şekilde giremez. Anahtarla girmeye izin vermek isterseniz prohibit-password yazın; bu, otomasyon betikleriniz root anahtarıyla bağlanıyorsa gereklidir.
• PasswordAuthentication no — parolayla giriş tamamen kapanır, yalnızca anahtar kabul edilir. ⚠️ Bunu yalnızca anahtarla girişi test ettikten sonra açın.
• AllowUsers mehmet — yalnızca listelenen kullanıcılar bağlanabilir. Birden fazla kullanıcı boşlukla ayrılır.
• MaxAuthTries 3 — bir bağlantıda izin verilen deneme sayısı.

Dosyayı kaydettikten sonra mutlaka sözdizimi testi yapın:

sudo sshd -t

Komut sessizce çıkarsa yapılandırma geçerlidir. Hata varsa satır numarasıyla söyler:

/etc/ssh/sshd_config.d/99-hardening.conf line 3: Bad configuration option: PubkeyAuthentification

Bu testi atlayıp servisi yeniden başlatmak, sshd servisinin hiç açılmaması ve sunucuya hiçbir şekilde bağlanamamanız demektir. Test geçtiyse yapılandırmayı uygulayın:

sudo systemctl reload sshd

reload yerine restart da çalışır ve ikisi de mevcut oturumları düşürmez; ancak reload daha yumuşak bir yoldur. Sonra üçüncü bir terminal açıp tekrar giriş yapın. Çalışıyorsa ilk root oturumunuzu artık kapatabilirsiniz.

Bu noktada SSH portunu da varsayılan 22'den değiştirmek isteyebilirsiniz; bu, güvenlikten çok günlük gürültüsünü azaltan bir önlemdir ve adımları SSH portu değiştirme yazısında anlatılıyor. Güvenlik duvarında yeni portu açmadan servisi taşımayın, aynı kilitlenme senaryosu oradan da yaşanır.

Sudo Yapılandırmasını Sıkılaştırma#

sudoers dosyasını asla doğrudan düzenlemeyin. Sözdizimi hatası yaptığınızda sudo tümüyle çalışmaz hâle gelir ve root girişi de kapalıysa sunucunuza müdahale edemezsiniz. Doğru araç visudo'dur; kaydetmeden önce sözdizimini doğrular:

sudo visudo

Kendi kurallarınızı ana dosyaya değil, ayrı bir parçaya yazmak daha güvenlidir:

sudo visudo -f /etc/sudoers.d/90-ekip

Faydalı birkaç ayar:

# Parola sorma aralığını 5 dakikaya indir
Defaults timestamp_timeout=5

# Her sudo komutunu ayrı bir dosyaya da yaz
Defaults logfile="/var/log/sudo.log"

# Yanlış parola girildiğinde uyarı e-postası
Defaults mail_badpass

# Belirli bir kullanıcıya yalnızca servis yönetimi yetkisi
deploy ALL=(root) /bin/systemctl restart nginx, /bin/systemctl reload nginx

Son satır, en az yetki prensibinin somut örneğidir: deploy kullanıcısı yalnızca iki komutu root olarak çalıştırabilir, başka hiçbir şeyi yapamaz. Bu yaklaşımın mantığı için en az yetki prensibi ve ileri düzey yapılandırma için sudo ve sudoers yapılandırma yazılarına bakabilirsiniz.

⚠️ NOPASSWD: ALL kullanmayın. Bu ayar, kullanıcının parola sormadan her şeyi root olarak yapmasına izin verir; yani root ile çalışmanın tüm riskini geri getirir, üstelik yanlış bir güvenlik hissiyle. Yalnızca belirli komutlar için ve otomasyon zorunluluğu varsa kullanın:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx

Günlük Kullanımda Doğru Alışkanlıklar#

Kurulum bitti; şimdi alışkanlık meselesi. Yıllardır uyguladığım ve ekiplere önerdiğim kurallar:

Root kabuğunda uzun süre kalmayın. sudo -i ile root'a geçmek bazen gerekir (üst üste on ayrıcalıklı komut çalıştıracaksanız), ama iş biter bitmez exit yazın. Terminal başlığınızda root olduğunuzu gösteren bir renk kullanın; kırmızı bir istem, o pencerede dikkatli olmanız gerektiğini hatırlatır.

Tehlikeli komutları önce echo ile deneyin. Bir rm ya da find -delete yazarken, komutu önce echo ile ya da -print ile çalıştırıp hangi dosyaları hedeflediğini görün:

find /var/www -name '*.log' -mtime +30 -print
# çıktı doğruysa
find /var/www -name '*.log' -mtime +30 -delete

Her ekip üyesine kendi hesabını açın. Ortak bir "admin" hesabı, denetim izini sıfırlar. Birisi ekipten ayrıldığında yalnızca sudo deluser --remove-home ayrilan ya da daha temkinli olarak sudo usermod -L ayrilan ile hesabı kilitlersiniz; kimsenin parola değiştirmesi gerekmez.

Anahtarları düzenli denetleyin. Ayda bir, sunucudaki tüm authorized_keys dosyalarını okuyun:

sudo find /root /home -name authorized_keys -exec echo '--- {}' \; -exec cat {} \;

Tanımadığınız bir anahtar görürseniz bu, bir güvenlik olayının ilk işaretidir.

Servisleri kendi kullanıcılarıyla çalıştırın. Bir Node.js veya Python uygulamasını root olarak çalıştırmayın; uygulamada bir açık bulunduğunda saldırgan doğrudan root olur. systemd birim dosyasında User= ve Group= tanımlayın.

Fail2ban kurun. Root girişini kapatmak, otomatik denemeleri durdurmaz; yalnızca hedefini şaşırtır. Tekrarlayan başarısız denemeleri IP bazlı engellemek için fail2ban kurulumu adımlarını uygulayın.

Yeni sunucuda yapılacak işlerin bütünlüklü listesi için VDS satın alma sonrası ilk adımlar ve sunucu sertleştirme kontrol listesi yazıları iyi bir yol haritası sunar.

Kilitlendiyseniz Ne Yapmalısınız#

Sıralamayı bozdunuz ve giremiyorsunuz. Panik yapmayın; sunucu duruyor ve kurtarma yolu var.

Birinci yol: sağlayıcı konsolu (VNC/KVM). Müşteri panelinizde "Konsol", "VNC" ya da "Uzak Ekran" adıyla bir seçenek vardır. Bu ekran SSH'tan tamamen bağımsızdır ve sunucunun fiziksel klavyesine bağlanmış gibi çalışır; SSH servisi kapalı olsa bile açılır. Buradan root parolanızla giriş yapıp hatalı satırı düzeltin:

nano /etc/ssh/sshd_config.d/99-hardening.conf
sshd -t
systemctl reload sshd

Konsol ekranında Türkçe klavye düzeni farklı davranabilir; parolanızda @, #, _ gibi karakterler varsa doğru tuşa bastığınızdan emin olun. Bu, konsolda "parola yanlış" sanılan durumların en yaygın nedenidir.

İkinci yol: kurtarma (rescue) modu. Root parolası da bilinmiyorsa sunucuyu kurtarma imajıyla açın, ana diski bağlayın ve chroot ile içeri girin:

mount /dev/vda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash
passwd root
nano /etc/ssh/sshd_config
exit

Sonra normal moda dönüp yeniden başlatın. Disk aygıtının adı (/dev/vda1, /dev/sda1) altyapıya göre değişir; lsblk ile görebilirsiniz.

Üçüncü yol: destek talebi. Konsol erişimi olmayan bir paket kullanıyorsanız sağlayıcınıza kurtarma modu talebi açın. Bu yolun süresi diğer ikisinden uzundur, bu yüzden konsol erişimi olan bir pakette çalışmak baştan avantajdır. Genel bağlantı sorunlarını eleme sırası için sunucuma bağlanamıyorum yazısı işinizi görür.

Sıkça Sorulan Sorular#

Root girişini kapatınca sunucuyu yönetemez miyim#

Yönetirsiniz, hiçbir yetki kaybı olmaz. PermitRootLogin no yalnızca SSH üzerinden root kullanıcı adıyla giriş yapmayı engeller; sudo yetkili kullanıcınızla bağlandıktan sonra sudo ya da sudo -i ile root yetkisini kullanmaya devam edersiniz. Ayrıca sağlayıcının konsol ekranından root ile giriş yapmak da hâlâ mümkündür. Yani kapattığınız şey yetki değil, internete açık bir saldırı yüzeyidir.

adduser ve useradd arasındaki fark nedir#

adduser Debian ve Ubuntu'ya özgü bir yardımcı betiktir; ev dizinini oluşturur, kabuk atar, parolayı sorar ve /etc/skel içeriğini kopyalar. useradd ise tüm dağıtımlarda bulunan alt seviye komuttur ve varsayılan olarak bunların hiçbirini yapmaz. RHEL ailesinde adduser genelde useradd komutuna sembolik bağdır, yani interaktif değildir. Bu yüzden AlmaLinux ya da Rocky Linux'ta useradd -m -s /bin/bash kullanici yazıp ardından passwd kullanici çalıştırmanız gerekir.

Yeni kullanıcı sudo yazınca kullanıcı sudoers dosyasında değil hatası alıyor#

Bu hatanın en yaygın nedeni, kullanıcının gruba eklendikten sonra oturumunu yenilememiş olmasıdır; grup üyelikleri oturum açılırken hesaplanır. Kullanıcı çıkıp yeniden girdiğinde sorun çözülür. İkinci ihtimal yanlış grup adıdır: Debian/Ubuntu'da sudo, RHEL ailesinde wheel grubu geçerlidir. Üçüncü ihtimal, usermod -aG yerine -a bayrağı olmadan usermod -G yazılmış olması ve kullanıcının diğer gruplarının silinmiş olmasıdır; groups kullanici çıktısıyla doğrulayın.

Root parolasını tamamen kaldırmak gerekir mi#

Gerekmez ve genelde önerilmez. Root parolası, SSH kapalı olduğunda bile sağlayıcının konsol ekranından giriş yapmanızı sağlayan acil durum anahtarınızdır; kaldırırsanız kurtarma senaryosunda elinizde yalnızca kurtarma modu kalır. Doğru yaklaşım, root parolasını uzun ve rastgele belirleyip bir parola yöneticisinde saklamak ve SSH'ta root girişini kapatmaktır. Hesabı tümden kilitlemek isterseniz passwd -l root kullanabilirsiniz, ancak bunu yapmadan önce sudo kullanıcınızla konsoldan giriş yapabildiğinizi test edin.

Kaç tane sudo yetkili kullanıcı olmalı#

Sunucuya gerçekten müdahale eden her kişi için bir tane, o kadar. Ortak hesap kullanmak denetim izini yok eder; gereğinden fazla kişiye yetki vermek ise saldırı yüzeyini büyütür. Uygulama dağıtımı gibi otomasyon işleri için ayrı bir hesap açın ve ona sudoers içinde yalnızca ihtiyaç duyduğu komutları tanımlayın. Ekipten biri ayrıldığında hesabını usermod -L ile kilitleyip anahtarını authorized_keys dosyasından silmek yeterlidir; kimsenin parola değiştirmesine gerek kalmaz.

sudo her seferinde parola soruyor, kapatabilir miyim#

Teknik olarak kapatabilirsiniz ama tam yetki için kapatmayın. NOPASSWD: ALL tanımı, açık kalmış bir terminale erişen herkese sınırsız root yetkisi verir ve root ile çalışmanın riskini geri getirir. Parola sorma sıklığını azaltmak istiyorsanız visudo ile Defaults timestamp_timeout=30 yazarak süreyi uzatabilirsiniz. Yalnızca otomasyon gerektiren tek tek komutlar için NOPASSWD tanımı yapmak kabul edilebilir bir orta yoldur.

Root ile açılmış dosyaların sahipliğini nasıl düzeltirim#

Web dizininde root sahipliğinde kalmış dosyaları web sunucusunun kullanıcısına devretmeniz gerekir. Debian/Ubuntu'da Apache ve Nginx genelde www-data, RHEL ailesinde apache ya da nginx kullanıcısıyla çalışır; cPanel sunucularında ise dosyalar hesabın kendi kullanıcısına ait olmalıdır. Komut sudo chown -R www-data:www-data /var/www/site biçimindedir. Sahiplik düzeldikten sonra izinleri de düzeltin: dizinler için 755, dosyalar için 644 uygundur. chmod 777 asla çözüm değildir, yalnızca sorunu güvenlik açığına dönüştürür.

SSH anahtarım varken parola girişini de kapatmalı mıyım#

Evet, anahtarla girişi test ettikten sonra PasswordAuthentication no yapmanızı öneririm. Parola girişi açık kaldığı sürece sunucunuz otomatik parola denemelerine hedef olmaya devam eder ve sizin anahtar kullanmanız bu trafiği durdurmaz. Kapatmadan önce mutlaka ikinci bir terminalden anahtarla giriş yapabildiğinizi doğrulayın, çünkü anahtar dosya izinleri hatalıysa anahtar da parola da çalışmaz ve kilitlenirsiniz. Ekipteki herkesin anahtarının yüklü olduğundan da emin olun.

Kapanış#

Root yerine sudo yetkili bir kullanıcıyla çalışmak, sunucu güvenliğinde en düşük maliyetli ve en yüksek getirili tek değişikliktir: beş dakikalık bir kurulumla yazım hatalarına karşı bir emniyet kemeri kazanır, kim ne yaptı sorusuna cevap verebilir hâle gelir ve otomatik saldırıların hedefini şaşırtırsınız. Kritik olan tek şey sıralamadır — önce kullanıcıyı açın, yetkiyi verin, anahtarı taşıyın, ikinci bir oturumla test edin, ancak ondan sonra root girişini kapatın. Bu sıralamaya uyduğunuz sürece kilitlenmeniz pratikte imkânsızdır; bozduğunuzda ise elinizde yalnızca konsol ekranı kalır.

Bu adımların hepsini uygulayabilmek için tam kök erişimine ve acil durumlarda konsol bağlantısına ihtiyacınız var; VDS sunucu paketleri bunu sağlar, daha yüksek kaynak esnekliği isteyenler için bulut sunucu seçeneği de aynı erişimi sunar. Kullanıcı yönetimi, sertleştirme ve güvenlik duvarı kurallarını kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz bu bakımı devralır. Tüm sunucu ailesini karşılaştırmak için sunucu paketleri sayfasına göz atabilirsiniz.