[Aior]

Linux'ta root parolasını (çoğu kişinin aradığı adıyla root şifresini) değiştirmek, sisteme girebiliyorsanız iki dakikalık bir iştir. Parolayı unuttuysanız ve sunucu sizi içeri almıyorsa iş bambaşka bir hâl alır. İkisini tek rehberde topladık, çünkü "root parolasını nasıl değiştiririm?" sorusunun arkasında neredeyse her zaman aşağıdaki altı durumdan biri vardır. Rehber bir karar tablosuyla başlıyor; kendi satırınızı bulup doğrudan ilgili bölüme geçebilirsiniz.

Başlamadan iki not. Birincisi, unutulan bir root parolasını sıfırlamak çoğu zaman makineyi yeniden başlatmak, yani servisi kısa bir süre durdurmak demektir; üretim (production) sunucusunda bunu bir bakım penceresine koyun ve işiniz bitince denetim izini (audit trail) kontrol edin (7. bölüm). İkincisi, buradaki kurtarma yöntemleri sahibi ya da yöneticisi olduğunuz sistemler içindir; başkasına ait bir sunucuya erişemiyorsanız sahibine veya sağlayıcıya başvurun.

Hangi durumdasınız?​

Durum	Yapılacak	Bölüm
root olarak girebiliyorsunuz	passwd	1
sudo yetkili bir hesabınız var	sudo passwd root (Ubuntu'da çoğu zaman gerekmez)	1
Parola kayıp ama fiziksel ya da konsol erişimi var (VPS panelindeki VNC/web konsolu dahil)	Root kabuğuyla açılış: rd.break, kurtarma modu veya init=/bin/bash	2 ve 3
Konsolu olmayan VPS veya bulut sunucu	Sağlayıcının kurtarma (rescue) sistemi, chroot, passwd	4
Windows'ta WSL	wsl -u root, ardından passwd kullanıcı-adı	5
Docker, Podman veya LXC konteyneri	Konteynere root olarak exec; kalıcı ayar imajda	5

1) Çalışan sistemde root parolasını değiştirmek​

root oturumundaysanız tek komut yeter:

passwd

Komut yeni parolayı iki kez sorar; yazarken ekranda hiçbir şey görünmez. pam_pwquality kullanan sistemlerde (örneğin RHEL ailesi) root zayıf bir parola belirlerse "BAD PASSWORD" uyarısı görür, ama parola yine de kabul edilir, çünkü enforce_for_root seçeneği varsayılan olarak kapalıdır. Uyarının ardından başarı mesajı geldiyse parola değişmiştir.

sudo yetkili bir hesaptan, eski parolayı bilmeden root'un ya da herhangi bir kullanıcının parolasını ayarlayabilirsiniz; sudo yalnızca kendi parolanızı sorar:

sudo passwd root
sudo passwd ahmet

Betiklerde parolayı etkileşimsiz ayarlamak için chpasswd kullanılır. Düz metin parola yerine önceden üretilmiş bir hash vermek daha güvenlidir:

openssl passwd -6                  # parolayı sorar, SHA-512 hash'ini yazdırır
echo 'root:HASH' | chpasswd -e     # HASH yerine üretilen değeri koyun

Hash'i tek tırnak içinde verin ki içindeki $ işaretlerini kabuk yorumlamasın. HISTCONTROL değişkeninde ignorespace ya da ignoreboth varsa, komutun başına koyduğunuz bir boşluk komutun kabuk geçmişine yazılmasını engeller. Kurulum araçlarının kendi yolları vardır: kickstart'ta rootpw --iscrypted, Ansible'da user modülüyle password_hash filtresi, cloud-init'te chpasswd anahtarı. Hangisini kullanırsanız kullanın, değeri koda gömmek yerine bir parola kasasından (secrets store) okuyun.

Ubuntu ve Debian'da root neden kilitli olabilir?​

Ubuntu, root hesabını kilitli bir parolayla kurar: parola alanında hiçbir parolanın eşleşemeyeceği bir değer bulunur, bu yüzden kimse doğrudan root olarak giriş yapamaz. Debian'da kurulum sırasında root parolasını boş bırakırsanız aynı düzen kurulur: root hesabı kapatılır ve ilk kullanıcı sudo ile yönetici yetkisi alır. Bu sistemlerde root'a sudo ile geçersiniz:

sudo -i        # root oturum kabuğu (root'un ortamı, /root dizini)
sudo -s        # oturum açmadan root kabuğu, bulunduğunuz dizinde kalır
sudo komut     # tek bir komutu root olarak çalıştırır

sudo passwd root ile root'a gerçek bir parola verebilirsiniz, ama çoğu sunucuda buna gerek yoktur. root'u kilitli tutun; biri açtıysa yeniden kilitleyin:

sudo passwd -l root

Kilitleme hakkında bilinmesi gereken iki şey var. Birincisi, passwd -l yalnızca parolayla doğrulamayı kapatır, hesabı kapatmaz: /root/.ssh/authorized_keys içinde bir SSH anahtarı varsa o anahtarla giriş yapılabilir. root'un SSH ile hiç girememesini istiyorsanız 7. bölümdeki PermitRootLogin no ayarını kullanın ya da anahtarı kaldırın. passwd(1) kılavuzunun hesapları kapatmak için önerdiği usermod --expiredate 1 yöntemini root'a uygulamayın: süresi dolmuş bir root hesabı, hesabı PAM üzerinden denetleyen servisleri (örneğin root'un cron işlerini) de durdurabilir.

İkincisi, durumu tek bakışta görebilirsiniz:

passwd -S root

Debian ve Ubuntu'da ikinci alan kilitli parola için L, kullanılabilir parola için P, parolasız hesap için NP gösterir; RHEL ailesinde aynı alan LK, PS veya NP olarak, yanında parantez içinde kısa bir açıklamayla görünebilir. NP her iki tarafta da tehlikelidir: parola alanı boştur ve PAM yapılandırmasına göre parolasız girişe izin verebilir. (Ubuntu 25.10'dan itibaren sudo komutunu Rust ile yazılmış sudo-rs paketi sağlıyor; yukarıdaki kullanımlar değişmiyor.)

2) RHEL, AlmaLinux ve Rocky Linux 8/9'da unutulan root parolasını sıfırlama (rd.break)​

Bu, Red Hat'in RHEL 8 ve 9 için belgelediği yöntemdir; aynı adımlar ikili uyumlu (binary compatible) yeniden derlemeler olan AlmaLinux ve Rocky Linux'ta da çalışır. Konsol erişimi gerekir: fiziksel ekran, IPMI/iDRAC/iLO ya da sanallaştırma platformunuzun veya sağlayıcınızın verdiği VNC/web konsolu.

1. Sistemi yeniden başlatın; GRUB ekranında varsayılan girdiyi seçip e tuşuna basın.
2. linux ile başlayan satırı bulun, satırın sonuna gidin ve bir boşluk bırakarak rd.break ekleyin. Satırın geri kalanına dokunmayın.
3. Ctrl+x ile açılışı başlatın. Sistem, asıl sistem devreye girmeden önce initramfs içindeki switch_root:/# isteminde durur.
4. Asıl kök dosya sistemi /sysroot altında salt-okunur bağlıdır; önce yazılabilir olarak yeniden bağlayın.
5. chroot ortamına geçin, parolayı ayarlayın ve bir sonraki açılış için SELinux yeniden etiketlemesi (relabel) isteyin; bu ortamda yazılan /etc/shadow yanlış SELinux bağlamıyla (context) kalır.
6. chroot'tan çıkmak için exit, switch_root isteminden çıkmak için bir kez daha exit yazın; açılış kaldığı yerden sürer.

Komutlar sırasıyla:

mount -o remount,rw /sysroot
chroot /sysroot
passwd
touch /.autorelabel
exit
exit

Yeniden etiketleme sonraki açılışta çalışır ve Red Hat'in de uyardığı gibi büyük bir diskte uzun sürebilir. İş bitince makine kendiliğinden yeniden başlar; ilk açılış yavaşsa müdahale etmeyin, ardından yeni parolayla root olarak girip deneyin.

Pratikte iki takılma noktası çıkar. Red Hat'in RHEL 7 kılavuzuna göre initramfs istemi, linux satırındaki son console= aygıtında açılır. Bulut imajlarında bu satır çoğu zaman console=ttyS0,... ile biter; istem seri konsola gider ve VNC ekranında hiçbir şey görmezsiniz. Bu durumda seri konsolu kullanın ya da yalnızca o açılış için satırın sonuna console=tty0 ekleyin. Disk LUKS ile şifreliyse açılışta parola sorulur; aynı kılavuza göre istem günlük mesajlarının arasında kaybolabilir, Backspace'e basınca görünür.

Aynı RHEL 7 kılavuzu, yeniden etiketlemeyi beklemek istemeyenler için bir kısayol da anlatır: rd.break'in yanına enforcing=0 eklerseniz SELinux o açılışta izin verici (permissive) modda çalışır ve touch /.autorelabel adımını atlayabilirsiniz. Açılış tamamlanınca root olarak girip yalnızca o dosyanın bağlamını düzeltin ve zorlayıcı (enforcing) moda dönün:

restorecon /etc/shadow
setenforce 1
getenforce        # Enforcing yazmalı

enforcing=0 bir çekirdek parametresidir ve RHEL 8/9'da da geçerlidir; yine de bu kısayolu yalnızca sonrasındaki restorecon adımını unutmayacaksanız kullanın.

3) Debian ve Ubuntu: kurtarma modu veya init=/bin/bash​

Ubuntu'da en kolay yol kurtarma menüsüdür. Açılışta Shift tuşunu basılı tutun (BIOS) ya da Esc tuşuna, gerekirse birkaç kez basın (UEFI). GRUB menüsünde Advanced options for Ubuntu'yu, ardından sonu (recovery mode) ile biten girdiyi, açılan menüde de "root – Drop to root shell prompt" seçeneğini seçin. Kök dosya sistemi salt-okunur bağlıdır, önce yazılabilir yapın:

mount -o remount,rw /
passwd ahmet          # Ubuntu'da genelde kaybolan, kendi kullanıcınızın parolasıdır
passwd root           # yalnızca root'a gerçekten parola vermek istiyorsanız

Ardından exit yazıp menüye dönün ve resume ile normal açılışa devam edin.

Ubuntu'da root kilitli olduğu için bu kabuk genellikle parola sormadan açılır. root'a bir parola verilmişse kurtarma modu tam da o parolayı ister. Debian'ın kurtarma girdisinde bu menü hiç yoktur: root parolası belirlenmiş bir sistemde doğrudan o parola sorulur, root kilitliyse kabuk hiç açılmayabilir. Parolayı bilmiyorsanız güvenilir yol init=/bin/bash'tir.

GRUB satırını 2. bölümdeki gibi düzenleyin, ama sona rd.break yerine init=/bin/bash ekleyin. Hiçbir servis çalışmadan doğrudan root kabuğuna düşersiniz:

mount -o remount,rw /
passwd root           # ya da: passwd kullanıcı-adı
sync

Şimdi düzgün çıkmanız gerekir. init çalışmadığı için olağan reboot komutu işe yaramaz. Ya denetimi systemd'ye devredip açılışı sürdürün ya da zorla yeniden başlatın:

exec /sbin/init
# ya da:
mount -o remount,ro /
reboot -f

reboot -f init sistemine başvurmaz ve çoğu durumda dosya sistemlerini düzgün ayırmaz (unmount); önce sync ve salt-okunur yeniden bağlama yapmanızın nedeni budur. SELinux etkinse (RHEL ailesinde standart; AppArmor kullanan Debian ve Ubuntu'da seyrek) çıkmadan önce touch /.autorelabel komutunu da çalıştırın.

4) Konsolu olmayan VPS veya bulut sunucu​

Açılış ekranını göremiyorsanız GRUB yöntemleri işe yaramaz; bir alt katmana inmeniz gerekir. Önce panele bakın: VNC ya da web konsolu varsa aslında konsol erişiminiz vardır ve 2. ile 3. bölümler doğrudan uygulanır. Bazı bulut panellerinde "root parolasını sıfırla" türünden bir işlev de bulunur; neye ihtiyaç duyduğunu (çoğu zaman bir konuk aracısı ya da yeniden başlatma) sağlayıcınızın belgesinden kontrol edin.

Sağlayıcının kurtarma (rescue) sistemi. Birçok sağlayıcı, sunucunuzu RAM'den çalışan küçük bir kurtarma Linux'uyla açabilir (örneğin Hetzner Rescue System, OVHcloud rescue modu, DigitalOcean Recovery ISO). Diskleriniz bu ortamda takılıdır ama bağlanmamıştır (unmounted). AWS'te karşılığı, örneği (instance) durdurup kök diskini (EBS birimi) yardımcı bir örneğe takmaktır. Kurtarma ortamında:

lsblk -f                           # disk, bölüm ve dosya sistemlerini gösterir
mount /dev/sda2 /mnt               # kök bölümünüz; vda2 veya nvme0n1p2 de olabilir
mount /dev/sda1 /mnt/boot          # yalnızca /boot ayrı bir bölümdeyse
for d in dev proc sys run; do mount --rbind /$d /mnt/$d; done
chroot /mnt
passwd root
# touch /.autorelabel              # yalnızca SELinux kullanan sistemlerde
exit
sync
# panelde açılışı yeniden diske alın ve sunucuyu yeniden başlatın

Kök dosya sistemi LVM üzerindeyse önce vgchange -ay çalıştırın ve mantıksal birimi bağlayın; adı lsblk çıktısında görünür (örneğin /dev/mapper/almalinux-root). Disk LUKS ile şifreliyse bağlamadan önce açın:

cryptsetup luksOpen /dev/sda2 root
mount /dev/mapper/root /mnt        # LUKS içinde LVM varsa önce vgchange -ay

Bilmediğiniz bir LUKS parolasını sıfırlayamazsınız; şifreleme tam olarak bunun için vardır. Birim açıldıktan sonra Linux parolasını her zamanki gibi değiştirebilirsiniz.

cloud-init. Bulut imajlarında ilk açılış parolası çoğu zaman cloud-init'ten gelir. chpasswd ve ssh_pwauth değerlerini sunucunun user-data'sında ayarlayabilirsiniz, ama bunları uygulayan modül her örnek için yalnızca bir kez çalışır (once-per-instance). Bu yüzden var olan bir sunucuda user-data'yı değiştirmek, cloud-init durumunu temizleyip (cloud-init clean) yeniden başlatmadıkça genellikle etkisizdir. cloud-init clean sonraki açılışı ilk açılış gibi çalıştırır: diğer modüller de yeniden çalışır ve varsayılan ayarlarla SSH ana makine anahtarları (host keys) yeniden üretilir. Üretimde bunu iyi tartın; kurtarma ya da konsol yolu çoğu zaman daha basittir. Ayrıca cloud-init varsayılan olarak disable_root uygular: root'un authorized_keys dosyasındaki anahtarın önüne, "Please login as the user ... rather than the user root" mesajını yazıp bağlantıyı kapatan zorunlu bir komut (forced command) ekler. root olarak anahtarla giriş "çalışıyor" görünüp sizi hemen dışarı atıyorsa nedeni budur.

Hipervizör tarafı. Ana makineyi (host) siz yönetiyorsanız konuğun (guest) parolasını onu açmadan da ayarlayabilirsiniz. libguestfs ile virt-customize -a disk.qcow2 --root-password password:YENI kullanılır; konuk kapalı olmalıdır, SELinux kullanan konuklarda --selinux-relabel ekleyin, password: yerine fileOSYA seçicisi de parolayı komut geçmişinin dışında tutar. Çalışan konuklarda Proxmox'ta qm guest passwd <vmid> root, libvirt'te virsh set-user-password <domain> root YENI kullanılabilir; ikisi de konukta QEMU guest agent'ın çalışmasını gerektirir.

5) Windows'ta WSL ve konteynerler​

WSL​

WSL kullanıcınızın (sudo çalıştıran hesabın) parolasını unuttuysanız yukarıdakilerin hiçbirine gerek yok. PowerShell'den dağıtıma root olarak girip kullanıcının parolasını yenileyin:

# PowerShell'de:
wsl -u root
# açılan root kabuğunda:
passwd kullanici-adiniz
exit

Varsayılan olmayan bir dağıtım için önce adını öğrenin, sonra -d ile belirtin:

wsl -l -v
wsl -d Ubuntu-24.04 -u root

wsl -u root parola sormadan root kabuğu açtığı için WSL'de root'un kendisi için kurtarılacak bir şey yoktur; kaybolan, normal kullanıcının sudo parolasıdır ve yukarıdaki komutlar bunu düzeltir.

Konteynerler​

Docker veya Podman konteynerinde root parolasının pratikte pek anlamı yoktur: konteyner motorunu yönetebilen herkes, parola olmadan içeride root kabuğu açabilir:

docker exec -it -u root <konteyner> sh
podman exec -it -u root <konteyner> sh

Çalışan bir konteynerin içinde passwd ile değiştirdiğiniz parola, konteyner silinip imajdan yeniden oluşturulduğunda kaybolur. Bir uygulama gerçekten bir kimlik bilgisine ihtiyaç duyuyorsa onu imaja gömmeyin; çalışma anında bir sır (secret) olarak verin. LXD/Incus sistem konteynerlerinde lxc exec <ad> -- passwd root (Incus'ta incus exec), Proxmox LXC'de ise pct enter <vmid> ile konteynere girip passwd kullanabilirsiniz.

6) passwd başarısız olunca: "Authentication token manipulation error" ve kalite reddi​

"Authentication token manipulation error" (PAM_AUTHTOK_ERR), passwd'nin değişikliği yazamadığı anlamına gelir. En sık nedenler, kontrol sırasıyla:

• Salt-okunur dosya sistemi. Kurtarma kabuklarında en sık neden budur: yeniden bağlamayı unuttunuz. Red Hat de bu hatayı tam bu durum için anar. Çözüm: mount -o remount,rw / (rd.break'te /sysroot).
• Disk ya da inode dolu. /etc/shadow geçici bir dosya üzerinden yeniden yazılır; boş yer yoksa yazma başarısız olur. df -h / ve df -i / ile kontrol edin.
• Değiştirilemez (immutable) /etc/shadow. Dosyaya immutable biti konmuşsa root bile yazamaz. lsattr /etc/shadow ile görün, chattr -i /etc/shadow ile kaldırın; bu biti kimin ve neden koyduğunu da araştırın.
• Yanlış SELinux bağlamı. Çevrimdışı düzenlemeden sonra görülür; EL kurtarma yönteminin touch /.autorelabel ya da restorecon /etc/shadow ile bitmesinin nedeni budur.

Başka bir hata türü, parolanın zayıf bulunup reddedilmesidir. pam_pwquality modülü uzunluğu ve karakter sınıflarını /etc/security/pwquality.conf dosyasına göre denetler: minlen varsayılan olarak 8'dir; dcredit, ucredit, lcredit ve ocredit negatif bir sayıya ayarlanırsa sırasıyla rakam, büyük harf, küçük harf ve diğer karakterler için en az o sayıda karakter bulunması zorunlu olur; dictcheck sözlük sözcüklerini reddeder. Parolayı root ayarlıyorsa enforce_for_root varsayılan olarak kapalı olduğundan zayıf parola yalnızca uyarıyla geçer. Bu acil durumda işe yarar, ama sonrasında düzgün bir parola koyun.

İki komşu mesaj da sık görülür. "Have exhausted maximum number of retries for service": yeni parola denetimi geçemedi ya da iki giriş eşleşmedi ve izin verilen deneme sayısı (retry) doldu; passwd'yi yeniden çalıştırın. "Authentication token lock busy": passwd parola dosyalarını kilitleyemedi. Kurtarma kabuğunda bu mesaj da salt-okunur dosya sisteminden kaynaklanabilir; çalışan bir sistemde ise o anda parola dosyalarını düzenleyen başka bir işlem (useradd, vipw ya da bir yapılandırma yönetimi çalıştırması) olabilir, bitmesini bekleyip yeniden deneyin.

7) Sıfırladıktan sonra: kapıyı kapatın ve kayıt tutun​

Parolayı yeniledikten sonra, internet ile sunucunuz arasında yalnızca bu parolanın durmadığından emin olun.

SSH'ta root için parola yerine anahtar kullanın. /etc/ssh/sshd_config dosyasında ya da ana yapılandırmanın genellikle en başta Include ettiği /etc/ssh/sshd_config.d/ dizinindeki bir dosyada:

PermitRootLogin prohibit-password

prohibit-password güncel OpenSSH sürümlerinde zaten varsayılandır ve RHEL 9 da root'un parolayla SSH girişini varsayılan olarak kapatır. Bu ayar root'u anahtarla içeri alır, parolayla asla almaz; böylece root parolasına SSH üzerinden kaba kuvvet (brute-force) denemesi anlamsız hâle gelir. root'u SSH'tan tamamen yasaklamak için no kullanın. sshd her yönerge (keyword) için okuduğu ilk değeri kullanır; drop-in dizini genellikle en başta dahil edildiğinden oradaki bir dosya ana dosyadaki satırın önüne geçer. Değişiklikten önce anahtarla ya da sudo yetkili başka bir hesapla girebildiğinizi doğrulayın ve mevcut oturumu kapatmadan yeni bir bağlantıyla deneyin:

sshd -t && systemctl reload sshd     # Debian/Ubuntu'da: systemctl reload ssh
sshd -T | grep -i permitrootlogin    # etkin değeri gösterir

Denetim izini kontrol edin. Parola değişikliği günlüğe düşer. RHEL, AlmaLinux ve Rocky'de /var/log/secure, Debian ve Ubuntu'da /var/log/auth.log dosyasına bakın. Debian 12'den itibaren rsyslog varsayılan olarak kurulmadığı için yeni kurulmuş bir Debian sisteminde bu dosya olmayabilir; o durumda günlüğü (journal) okuyun:

journalctl -t passwd
journalctl _COMM=sudo
ausearch -m USER_CHAUTHTOK    # auditd kuruluysa
last                          # oturum geçmişi; Debian 13'te wtmpdb last

Günlükleri merkezi bir kayıt sunucusuna da gönderin; sunucu ele geçirilse bile kayıtlar korunur.

Güçlü bir parola seçin. Burada sabit bir karakter sayısı dayatmıyoruz, çünkü kurallar kurumdan kuruma değişir. Güvenli genel kural şudur: parola yöneticisinin ürettiği uzun ve rastgele bir parola kullanın (biz 24 karakterin altına inmiyoruz) ve her sunucuda farklı olsun ki tek bir sızıntı bütün sunuculara taşınmasın. Parolayı takvime göre değil olaya göre değiştirin (sızıntı şüphesi, ekipten ayrılan biri); NIST SP 800-63B de periyodik zorunlu değişimi önermez, değişimi ele geçirilme belirtisine bağlar. Daha geniş resim için sunucu sertleştirme rehberimize bakın. Bu adımlar sırasında bir komut "bu komut root yetkisiyle çalıştırılmalıdır" diye yanıt verirse (çoğu zaman sudo unutulmuştur), bu hata için hazırladığımız başlık sudo ve PATH kaynaklı nedenleri adım adım anlatır.

Sıkça sorulan sorular​

Yeni root parolası koymak için eskisini bilmem gerekir mi?
Hayır. Zaten root iseniz ya da sudo yetkiniz varsa passwd ve sudo passwd root eski parolayı sormaz; sudo yalnızca kendi parolanızı ister. Eski parola, normal bir kullanıcı kendi parolasını değiştirirken gerekir.

Parolayı değiştirmek açık oturumları veya servisleri etkiler mi?
Hayır. Parola değişikliği açık oturumları kapatmaz, çalışan servisleri durdurmaz. Kesintiyi kurtarma yöntemlerinin gerektirdiği yeniden başlatma yaratır; 1. bölümdeki canlı passwd yeniden başlatma gerektirmez.

rd.break ile sıfırladım, açılış çok uzun sürüyor. Normal mi?
Evet. Bu, touch /.autorelabel'in başlattığı SELinux yeniden etiketlemesidir ve büyük diskte uzun sürer. Bitmesini bekleyin; makine kendini yeniden başlatır. Bir dahaki sefere 2. bölümdeki enforcing=0 kısayolunu kullanabilirsiniz.

passwd "Authentication token manipulation error" veriyor. Ne yapmalıyım?
Büyük olasılıkla dosya sistemini yazılabilir olarak yeniden bağlamadınız. mount -o remount,rw / (ya da /sysroot) çalıştırıp tekrar deneyin. Sorun bu değilse dolu disk, değiştirilemez /etc/shadow (lsattr) ve SELinux bağlamını kontrol edin.

Ubuntu'da root'a parola vermeli miyim?
Çoğu sunucuda gerek yok. root'u kilitli tutup sudo kullanmak, korumanız gereken parolalardan birini ortadan kaldırır. root parolası en çok sulogin'in parola istediği acil durum (emergency) ve kurtarma (rescue) kabuklarında işe yarar; root kilitliyken bu kabuklar açılmayabilir ve o zaman 3. bölümdeki GRUB yöntemlerine dönersiniz. Parola koyarsanız uzun ve benzersiz olsun, bir parola yöneticisinde saklayın.

Birinin parolayı bu yollarla sıfırlamasını nasıl engellerim?
Fiziksel ya da konsol erişimi pratikte root erişimi demektir. Açılış satırının düzenlenmesini engellemek için GRUB parolası koyun, çevrimdışı bir chroot'un diski okuyamaması için diski LUKS ile şifreleyin, IPMI/VNC konsolunu ve sağlayıcı panelinizi güçlü parola ve iki adımlı doğrulamayla koruyun. Ayrıntılar sertleştirme başlığında.

Sonuç ve sonraki adımlar​

Karar tablosunda kendi satırınızı bulun ve yalnızca o bölümü uygulayın: çalışan makinede passwd, RHEL ailesinde rd.break, Debian ve Ubuntu'da kurtarma modu ya da init=/bin/bash, konsolsuz VPS'te sağlayıcının kurtarma sistemi, Windows'ta wsl -u root. passwd değişikliği kaydedemiyorsa neden neredeyse her zaman salt-okunur dosya sistemi, dolu disk, değiştirilemez dosya ya da SELinux'tur. İş bitince root'un SSH girişini PermitRootLogin prohibit-password ile anahtara bağlayın, yeni parolayı bir parola yöneticisinde saklayın ve değişikliğin günlüklere düştüğünü doğrulayın. VPS seçerken pakette web konsolu ve kurtarma modu olup olmadığını önceden sorun; böyle bir günde sizi destek talebi beklemekten kurtarır. AIOR sanal sunucu paketlerinde root erişimi, yeniden kurulum ve snapshot seçenekleri pakete göre netleştirilir; kurtarma işini kendiniz yapmak istemiyorsanız uygun paketlerde yönetim hizmeti ayrıca teklif edilebilir. Dağıtımınıza ya da sağlayıcınıza özel sorularınızı bu başlıkta sorabilirsiniz.

Changing the root password on Linux is a two-minute job when you can log in. When you have forgotten it and the server will not let you in, it is a different job entirely. Both belong in one guide, because "how do I reset the root password?" almost always turns out to be one of the six situations below. Start with the decision table, find your row and jump straight to that section.

Two notes before you touch anything. First, resetting a forgotten root password usually means a reboot, so plan a short outage on a production host and check the audit trail when you are done (section 7). Second, these recovery procedures are for machines you own or administer; if you are locked out of someone else's server, go to its owner or provider.

Which situation are you in?​

Situation	What to do	Section
You can log in as root	Run passwd	1
You have a sudo account	sudo passwd root (often unnecessary on Ubuntu)	1
Password lost, but you have physical or console access (including a VPS panel's VNC/web console)	Boot to a root shell: rd.break, recovery mode or init=/bin/bash	2 and 3
VPS or cloud server with no console	Provider's rescue system, chroot, passwd	4
WSL on Windows	wsl -u root, then passwd username	5
Docker, Podman or LXC container	Exec in as root; set anything permanent in the image	5

1) Change the root password on a running system​

If you are logged in as root, it is one command:

passwd

It asks for the new password twice and never echoes it. On systems that use pam_pwquality (the RHEL family, for example), a weak password set by root triggers a "BAD PASSWORD" warning but is accepted anyway, because enforce_for_root is off by default. If a success message follows the warning, the password has changed.

From a sudo account you can set root's password, or any user's, without knowing the old one; sudo asks only for your own password:

sudo passwd root
sudo passwd alice

In scripts, chpasswd sets passwords non-interactively. Feeding it a pre-generated hash is safer than plain text:

openssl passwd -6                  # prompts for the password, prints a SHA-512 hash
echo 'root:HASH' | chpasswd -e     # replace HASH with that output

Keep the hash in single quotes so the shell does not expand its $ signs. If HISTCONTROL contains ignorespace or ignoreboth, a leading space keeps the command out of shell history. Provisioning tools have their own mechanisms: rootpw --iscrypted in kickstart, the user module with the password_hash filter in Ansible, the chpasswd key in cloud-init. Whichever you use, read the value from a secrets store instead of hard-coding it.

Why root may be locked on Ubuntu and Debian​

Ubuntu installs the root account with a locked password: the password field holds a value that no password can match, so nobody can log in as root directly. Debian does the same if you leave the root password empty in the installer: the root account is disabled and the first user gets sudo. On these systems you become root through sudo:

sudo -i        # root login shell (root's environment, /root)
sudo -s        # root shell without a login; stays in the current directory
sudo command   # run one command as root

You can give root a real password with sudo passwd root, but most servers do not need one. Keep it locked, and re-lock it if someone enabled it:

sudo passwd -l root

Two things to understand about locking. First, passwd -l disables password authentication only, not the account: if /root/.ssh/authorized_keys holds a key, that key still logs in. To keep root off SSH entirely, use PermitRootLogin no (section 7) or remove the key. Do not reach for usermod --expiredate 1, which the passwd(1) manual suggests for disabling accounts: an expired root account can also stop services that check the account through PAM, such as root's cron jobs.

Second, you can check the state at a glance:

passwd -S root

On Debian and Ubuntu the second field reads L for a locked password, P for a usable one and NP for none; RHEL-family systems may show LK, PS or NP with a short description in parentheses. NP is dangerous in either case: the password field is empty, and depending on the PAM configuration that can allow a login without a password. (From Ubuntu 25.10, sudo is provided by sudo-rs, a Rust implementation; the commands above work the same.)

2) Reset a forgotten root password on RHEL, AlmaLinux and Rocky Linux 8/9 (rd.break)​

This is the procedure Red Hat documents for RHEL 8 and 9, and the same steps work on the binary-compatible rebuilds AlmaLinux and Rocky Linux. You need console access: a physical screen, IPMI/iDRAC/iLO, or the VNC/web console of your virtualisation platform or provider.

1. Reboot and, on the GRUB screen, highlight the default entry and press e.
2. Find the line that starts with linux, move to its end and append rd.break after a space. Leave the rest of the line alone.
3. Press Ctrl+x to boot. The system stops at a switch_root:/# prompt inside the initramfs, before the real system takes over.
4. The real root filesystem is mounted read-only under /sysroot, so remount it read-write first.
5. Enter the chroot, set the password and request an SELinux relabel for the next boot; /etc/shadow written from this environment ends up with the wrong SELinux context.
6. Type exit to leave the chroot and exit again to leave the switch_root prompt; the boot carries on.

The commands in order:

mount -o remount,rw /sysroot
chroot /sysroot
passwd
touch /.autorelabel
exit
exit

The relabel runs on the next boot and, as Red Hat warns, can take a long time on a large disk. The machine reboots by itself when it finishes, so leave a slow first boot alone, then log in as root with the new password to confirm.

Two snags come up in practice. Red Hat's RHEL 7 guide notes that the initramfs prompt appears on the last console= device on the linux line. Cloud images often end that line with console=ttyS0,..., so the prompt goes to the serial console and the VNC screen shows nothing; use the serial console, or append console=tty0 for that one boot. And if the disk is LUKS-encrypted, you are asked for the passphrase during boot; according to the same guide the prompt can be buried under log messages, and pressing Backspace brings it into view.

The same RHEL 7 guide describes a shortcut for when you do not want to wait for the relabel. Add enforcing=0 next to rd.break: SELinux runs in permissive mode for that boot, and you can skip touch /.autorelabel. Once the system is up, log in as root, fix the context of that one file and return to enforcing mode:

restorecon /etc/shadow
setenforce 1
getenforce        # should print Enforcing

enforcing=0 is a kernel parameter and works on RHEL 8 and 9 as well; just do not use the shortcut unless you will remember the restorecon step afterwards.

3) Debian and Ubuntu: recovery mode or init=/bin/bash​

On Ubuntu the easy path is the recovery menu. Hold Shift during boot (BIOS) or press Esc, possibly several times (UEFI), to reach GRUB. Choose Advanced options for Ubuntu, then the entry ending in (recovery mode), then "root – Drop to root shell prompt". The root filesystem is mounted read-only, so remount it first:

mount -o remount,rw /
passwd alice          # on Ubuntu it is usually your own user's password that is lost
passwd root           # only if you really want root to have a password

Then type exit to return to the menu and choose resume to continue a normal boot.

Because root is locked on Ubuntu, this shell usually opens without asking for a password. If root has a password, recovery mode asks for exactly that password. Debian's recovery entry has no such menu at all: on a system with a root password it asks for that password straight away, and if root is locked it may not give you a shell. When you do not know the password, init=/bin/bash is the reliable route.

Edit the GRUB line as in section 2, but append init=/bin/bash instead of rd.break. You land in a bare root shell with no services running:

mount -o remount,rw /
passwd root           # or: passwd username
sync

Now you have to leave cleanly. With no init running, the normal reboot command does not work. Either hand control to systemd and let the boot continue, or force a reboot:

exec /sbin/init
# or:
mount -o remount,ro /
reboot -f

reboot -f does not contact the init system and in most cases does not unmount filesystems properly, which is why you sync and remount read-only first. If SELinux is enabled (standard on the RHEL family, rare on Debian and Ubuntu, which use AppArmor), also run touch /.autorelabel before you leave.

4) VPS or cloud server with no console​

If you cannot see the boot screen, the GRUB methods are no use and you have to work one layer down. Check the panel first: if it offers a VNC or web console, you do have console access and sections 2 and 3 apply directly. Some cloud panels also have a "reset root password" function; check your provider's documentation for what it needs (often a guest agent or a reboot).

Provider rescue system. Many providers can boot your server into a small rescue Linux that runs from RAM (for example Hetzner's Rescue System, OVHcloud rescue mode or DigitalOcean's Recovery ISO). Your disks are attached but not mounted. On AWS the equivalent is to stop the instance and attach its root EBS volume to a helper instance. In the rescue environment:

lsblk -f                           # disks, partitions and filesystems
mount /dev/sda2 /mnt               # your root partition; may be vda2 or nvme0n1p2
mount /dev/sda1 /mnt/boot          # only if /boot is a separate partition
for d in dev proc sys run; do mount --rbind /$d /mnt/$d; done
chroot /mnt
passwd root
# touch /.autorelabel              # only on SELinux systems
exit
sync
# switch the panel back to booting from disk, then reboot

If the root filesystem is on LVM, run vgchange -ay first and mount the logical volume; lsblk shows its name (for example /dev/mapper/almalinux-root). If it is LUKS-encrypted, open it before mounting:

cryptsetup luksOpen /dev/sda2 root
mount /dev/mapper/root /mnt        # with LVM inside LUKS, run vgchange -ay first

You cannot reset a LUKS passphrase you do not know; that is exactly what the encryption is for. Once the volume is open, you can change the Linux password as usual.

cloud-init. On cloud images the first-boot password often comes from cloud-init. You can set chpasswd and ssh_pwauth in the instance's user-data, but the module that applies them runs once per instance, so editing user-data on an existing server usually does nothing unless you also clear cloud-init's state (cloud-init clean) and reboot. That makes the next boot behave like a first boot: other modules run again too, and with default settings the SSH host keys are regenerated, so think twice before doing it in production; the rescue or console route is usually simpler. Note also that cloud-init applies disable_root by default: it puts a forced command in front of root's key in authorized_keys that prints "Please login as the user ... rather than the user root" and closes the connection. That is why key login as root seems to work and then drops you straight back out.

Hypervisor side. If you run the host, you can set a guest's password without booting it. With libguestfs, use virt-customize -a disk.qcow2 --root-password password:NEW; the guest must be shut down, add --selinux-relabel for SELinux guests, and the file:FILENAME selector instead of password: keeps the password out of your shell history. For running guests, Proxmox has qm guest passwd <vmid> root and libvirt has virsh set-user-password <domain> root NEW; both need the QEMU guest agent running in the guest.

5) WSL on Windows and containers​

WSL​

If you forgot the password of your WSL user (the account that runs sudo), you need none of the above. From PowerShell, enter the distribution as root and reset that user's password:

# in PowerShell:
wsl -u root
# in the root shell that opens:
passwd your-username
exit

For a distribution that is not the default, look up its name and pass it with -d:

wsl -l -v
wsl -d Ubuntu-24.04 -u root

Because wsl -u root opens a root shell without a password, there is nothing to recover for root itself on WSL; what people lose is their normal user's sudo password, and the commands above fix that.

Containers​

In a Docker or Podman container a root password rarely means anything: anyone who can manage the container engine can already open a root shell inside without one:

docker exec -it -u root <container> sh
podman exec -it -u root <container> sh

A password you change with passwd inside a running container disappears when the container is removed and recreated from its image. If an application genuinely needs a credential, do not bake it into the image; pass it in at run time as a secret. For LXD/Incus system containers use lxc exec <name> -- passwd root (incus exec on Incus), and on Proxmox LXC enter the container with pct enter <vmid> and run passwd there.

6) When passwd fails: "Authentication token manipulation error" and quality rejections​

"Authentication token manipulation error" (PAM_AUTHTOK_ERR) means passwd could not write the change. The usual causes, in the order worth checking:

• Read-only filesystem. The most common cause in rescue and recovery shells: you forgot the remount. Red Hat's documentation names this exact error for that case. Fix: mount -o remount,rw / (or /sysroot under rd.break).
• Disk or inodes full. /etc/shadow is rewritten through a temporary file, which fails when there is no free space. Check with df -h / and df -i /.
• Immutable /etc/shadow. If someone set the immutable bit, even root cannot write the file. See it with lsattr /etc/shadow, clear it with chattr -i /etc/shadow, and find out who set it and why.
• Wrong SELinux context after an offline edit; this is why the EL recovery procedure ends with touch /.autorelabel or restorecon /etc/shadow.

A different failure is a password rejected as too weak. The pam_pwquality module checks length and character classes against /etc/security/pwquality.conf: minlen defaults to 8; setting dcredit, ucredit, lcredit or ocredit to a negative number requires at least that many digits, uppercase, lowercase or other characters respectively; dictcheck rejects dictionary words. When root sets the password, enforce_for_root is off by default, so a weak password only produces a warning and still goes through. That is handy in an emergency, but set a proper password afterwards.

Two neighbouring messages are also common. "Have exhausted maximum number of retries for service" means the new password failed the checks, or the two entries did not match, as many times as the retry setting allows; just run passwd again. "Authentication token lock busy" means passwd could not lock the password files. In a recovery shell a read-only filesystem can cause this one too; on a running system another process (useradd, vipw or a configuration-management run) may be editing the files, so wait for it to finish and retry.

7) After the reset: close the door and keep a record​

Once the password is reset, make sure it is not the only thing standing between the internet and your server.

Use keys instead of the root password for SSH. In /etc/ssh/sshd_config, or in a file under /etc/ssh/sshd_config.d/, which the main config usually Includes near the top:

PermitRootLogin prohibit-password

prohibit-password is already the default in current OpenSSH, and RHEL 9 also disables root password login over SSH by default. It lets root in with a key but never with a password, which makes brute-forcing the root password over SSH pointless. Use no to keep root off SSH altogether. sshd uses the first value it obtains for each keyword, and because the drop-in directory is usually included near the top, a file there overrides the line in the main file. Before you change anything, make sure you can log in with a key or another sudo account, and test from a new connection while keeping your current session open:

sshd -t && systemctl reload sshd     # on Debian/Ubuntu: systemctl reload ssh
sshd -T | grep -i permitrootlogin    # shows the effective value

Check the audit trail. A password change is logged. On RHEL, AlmaLinux and Rocky look in /var/log/secure; on Debian and Ubuntu in /var/log/auth.log. Since Debian 12, rsyslog is no longer installed by default, so a fresh Debian system may not have that file; read the journal instead:

journalctl -t passwd
journalctl _COMM=sudo
ausearch -m USER_CHAUTHTOK    # if auditd is installed
last                          # login history; wtmpdb last on Debian 13

Ship these logs to a central log server as well, so the record survives even if the host is compromised.

Choose a strong password. We do not impose a fixed character count here, because rules differ between organisations. The safe general rule: use a long random password generated by a password manager (we do not go below 24 characters), unique per server so one leak cannot be replayed across your fleet. Change it when something happens (a suspected leak, someone leaving the team) rather than on a calendar; NIST SP 800-63B also advises against forced periodic changes and ties a change to evidence of compromise. For the wider picture, see our server hardening guide. If a command in these steps answers "this command must be run as root" (usually because sudo was left off), our thread on that error walks through the sudo and PATH causes step by step.

FAQ​

Do I need the old root password to set a new one?
No. If you are already root or have sudo, passwd and sudo passwd root do not ask for it; sudo asks only for your own password. You need the old password only when a normal user changes their own.

Will changing the password log everyone out or break services?
No. Changing the password does not end open sessions or stop running services. The downtime comes from the reboot that the recovery procedures need; the live passwd in section 1 needs no reboot.

I reset it with rd.break and the boot is taking ages. Is that normal?
Yes. That is the SELinux relabel triggered by touch /.autorelabel, and it is slow on a big disk. Let it finish; the machine reboots itself. Next time you can use the enforcing=0 shortcut from section 2.

passwd says "Authentication token manipulation error". What now?
You most likely did not remount the filesystem read-write. Run mount -o remount,rw / (or /sysroot) and try again. If that is not it, check for a full disk, an immutable /etc/shadow (lsattr) and the SELinux context.

Should I give root a password on Ubuntu?
On most servers, no. Keeping root locked and using sudo means one less secret to protect. A root password mostly matters for the emergency and rescue shells where sulogin asks for it; with root locked those shells may refuse to open, and you fall back to the GRUB methods in section 3. If you do set one, make it long and unique and keep it in a password manager.

How do I stop someone else resetting the password this way?
Physical or console access is effectively root access. Set a GRUB password to block editing of the boot line, encrypt the disk with LUKS so an offline chroot cannot read it, and protect the IPMI/VNC console and your provider panel with strong passwords and two-factor authentication. The hardening thread covers the details.

Conclusion and next steps​

Find your row in the decision table and follow that section only: passwd on a running machine, rd.break on the RHEL family, recovery mode or init=/bin/bash on Debian and Ubuntu, the provider's rescue system on a console-less VPS, or wsl -u root on Windows. When passwd cannot save the change, the cause is nearly always a read-only filesystem, a full disk, an immutable file or SELinux. Afterwards, restrict root SSH to keys with PermitRootLogin prohibit-password, store the new password in a password manager and confirm that the change shows up in your logs. When you choose a VPS, ask up front whether the plan includes a web console and a rescue mode; on a day like this it saves you waiting on a support ticket. On AIOR VPS hosting plans, root access, reinstall and snapshot options are confirmed per plan, and on eligible plans management can be quoted separately if you would rather not handle recovery yourself. Questions about your specific distribution or provider are welcome in this thread.