Resetare parola root cu ISO de rescue si chroot

Exista un fel aparte de liniste atunci cand scrii parola de root, apesi Enter si primesti “Login incorrect” pentru a treia oara. Poate parola statea intr-o notita care nu mai exista, poate un coleg a schimbat-o si a plecat din firma, poate serverul nici macar nu mai porneste destul de departe ca sa apuci sa incerci. Trucul clasic, in care editezi meniul GRUB si pornesti cu init=/bin/bash, nu te ajuta daca GRUB e protejat cu parola sau daca sistemul cade inainte sa ajunga la un shell. Ce functioneaza insa de fiecare data este cea mai veche miscare de recuperare din Linux: pornesti masina de pe alt sistem de operare, deschizi discul instalat ca pe un stick USB si intri in el cu chroot.

In acest ghid facem exact asta pe un VPS KVM. Pornim un ISO de rescue din panoul de control, gasim discul de sistem, activam LVM (si deblocam LUKS daca discul e criptat), montam tot, intram cu chroot si setam o parola noua. Dureaza in jur de 15 minute, nu atinge datele tale, iar dupa ce l-ai facut o data, o parola uitata nu mai e o urgenta, ci o treaba de rutina.

De ce metoda cu ISO de rescue merge cand restul nu mai merge

Ca sa intelegi de ce metoda e atat de sigura, ajuta sa vezi cum porneste un server. Cand VPS-ul porneste, firmware-ul virtual (BIOS sau UEFI) cauta ceva de pe care sa booteze, in ordinea configurata. In mod normal, asta e discul de sistem, unde GRUB (bootloader-ul) incarca kernelul Linux, care apoi porneste restul sistemului. Parola de root nu e stocata “in” niciunul dintre aceste programe. Ea sta sub forma de hash (o varianta amestecata, ireversibila, a parolei) intr-un fisier text obisnuit de pe disc: /etc/shadow.

De aici rezulta o observatie simpla: oricine poate porni masina de pe alt sistem de operare poate citi si modifica acel fisier. O parola pe GRUB protejeaza doar meniul GRUB. Daca firmware-ul porneste o imagine de CD inainte sa ajunga la GRUB, parola GRUB nu este ceruta niciodata. De aceea ISO-ul de rescue e solutia universala de rezerva: nu-l intereseaza daca GRUB e blocat, configurat gresit sau daca kernelul de pe disc da kernel panic la boot.

Conceptele de baza, pe intelesul tuturor

Inainte sa scriem comenzi, sa definim cativa termeni care apar la fiecare pas:

• ISO de rescue sau live: imaginea unui sistem Linux complet care ruleaza in intregime de pe CD-ul virtual si din RAM, fara sa instaleze nimic. Discul tau real ramane neatins pana cand decizi tu sa-l montezi.
• Partitie si sistem de fisiere: un disc e impartit in partitii (felii), iar fiecare partitie contine de obicei un sistem de fisiere, cum ar fi ext4 sau vfat, adica structura care organizeaza fisierele si folderele.
• Montare: atasarea unui sistem de fisiere la un folder, ca sa-l poti rasfoi. Daca montam partitia de sistem pe /mnt, atunci /etc/shadow de pe server devine vizibil ca /mnt/etc/shadow.
• LVM (Logical Volume Manager): un strat intre partitii si sistemele de fisiere care permite redimensionarea si combinarea spatiului. O partitie devine “physical volume” (PV), PV-urile formeaza un “volume group” (VG), iar VG-ul e impartit in “logical volumes” (LV) care contin sistemele de fisiere propriu-zise. Atat Debian cat si Ubuntu ofera LVM in installer si multi il aleg.
• LUKS: criptarea de disc din Linux. Daca discul e criptat, trebuie sa-l deblochezi cu parola (passphrase) inainte sa poti citi ceva.
• chroot: prescurtare de la “change root”. Porneste un program care trateaza alt folder drept /. Dupa chroot /mnt, programele vad sistemul tau instalat ca pe intreaga lume: citesc /etc/passwd-ul lui, configuratia PAM, setarile de hashing pentru parole.

De ce nu rulam pur si simplu passwd in sistemul live?

Pentru ca ar schimba parola utilizatorului din sistemul live, care dispare la urmatorul reboot. Sistemul live are propriul /etc/shadow in RAM. Avem nevoie ca passwd sa lucreze pe fisierele serverului tau, cu regulile serverului tau (Debian 13 si Ubuntu 24.04 folosesc implicit yescrypt pentru hash-uri). chroot ne da exact asta, fara sa editam hash-uri de mana.

De ce ai nevoie

• Un VPS KVM. Metoda cere o masina virtuala cu bootloader si disc propriu. Intr-un container LXC (privilegiat sau neprivilegiat) nu exista bootloader si nici boot de pe ISO, pentru ca containerele folosesc kernelul host-ului. Daca pierzi accesul root pe un VPS LXC, contacteaza suportul sau foloseste optiunile de resetare parola sau reinstalare din panou.
• Acces la panoul de client, cu optiunea de a atasa un ISO, de a schimba ordinea de boot si de a deschide consola VNC sau noVNC in browser.
• Un ISO de rescue pentru amd64. Merge oricare dintre acestea: Debian live (imaginea “standard” e mica si nu are interfata grafica), Ubuntu Desktop in modul “Try Ubuntu”, sau SystemRescue , care vine cu uneltele pentru LVM si LUKS preinstalate. Multe panouri ofera deja cateva dintre ele intr-o biblioteca de ISO-uri.
• Passphrase-ul LUKS, daca discul e criptat. Fara el, nimeni nu poate citi datele, si exact asta e rostul criptarii.
• Cam 15-30 de minute si acceptarea unei perioade de downtime: pe durata procedurii, VPS-ul ruleaza sistemul de rescue in locul serviciilor tale.

Resetare parola root cu chroot: cei 7 pasi

Iata toata procedura dintr-o privire. Fiecare caseta de mai jos corespunde unui pas numerotat din restul articolului, ca sa stii mereu unde te afli.

Pasul 1: Pornesti VPS-ul de pe ISO-ul de rescue

Intra in panoul de client DreamServer, deschide VPS-ul si cauta sectiunea de ISO sau rescue. Ataseaza ISO-ul (din biblioteca sau prin URL, in functie de ce ofera panoul), seteaza ordinea de boot astfel incat CD-ROM-ul sa fie inaintea discului si reporneste VPS-ul. Apoi deschide consola VNC sau noVNC in browser. E un ecran si o tastatura virtuale conectate direct la masina virtuala, deci functioneaza chiar si atunci cand reteaua din server e stricata.

Ce vezi mai departe depinde de ISO:

• Debian live: alegi “Live system (amd64)” din meniul de boot. Esti logat automat cu utilizatorul user (parola e live, daca ti se cere vreodata).
• Ubuntu Desktop: alegi “Try or Install Ubuntu”, apoi “Try Ubuntu” in fereastra installer-ului si deschizi un Terminal. Utilizatorul live e ubuntu, fara parola.
• SystemRescue: intrarea implicita din meniu te duce direct intr-un shell de root.

Pe Debian sau Ubuntu live, devino root ca sa nu trebuiasca sa pui sudo in fata fiecarei comenzi:

sudo -i

Prompt-ul se termina acum cu #, adica esti root in sistemul live. Toate comenzile de aici incolo presupun asta.

Optional, dar foarte util: SSH in sistemul live. Sa scrii comenzi lungi printr-o consola VNC e lent, iar copy-paste de multe ori nu merge. Daca vrei sa lipesti comenzile din acest articol, da-i sistemului live acces la retea si un server SSH. Mai intai verifica daca interfata a primit deja o adresa prin DHCP:

ip -br addr

Daca IP-ul tau public nu apare, configureaza-l manual, cu IP-ul, prefixul si gateway-ul din panou (valorile de mai jos sunt exemple, iar ens18 trebuie inlocuit cu numele interfetei din comanda anterioara):

ip link set ens18 up
ip addr add 203.0.113.10/24 dev ens18
ip route add default via 203.0.113.1
echo "nameserver 1.1.1.1" > /etc/resolv.conf

Apoi instaleaza si porneste serverul SSH si seteaza o parola temporara pentru utilizatorul live (user pe Debian live, ubuntu pe Ubuntu live):

apt update && apt install -y openssh-server
passwd user
systemctl start ssh

De pe calculatorul tau, conecteaza-te spunandu-i lui SSH sa nu salveze cheia de host a sistemului live:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@203.0.113.10

De ce aceste optiuni? Sistemul live are alte chei de host decat serverul tau. Fara ele, SSH fie ar refuza conexiunea (pentru ca s-a schimbat cheia pentru acel IP), fie ar salva cheia sistemului live in known_hosts, iar mai tarziu ai primi un avertisment urat cand te conectezi din nou la serverul real. Dupa logare, ruleaza sudo -i.

Pasul 2: Identifici discul de sistem

Acum ne uitam ce discuri si partitii exista. Optiunea -i face ca lsblk sa deseneze arborele cu caractere ASCII simple, mai usor de citit in consola:

lsblk -i -o NAME,SIZE,FSTYPE,MOUNTPOINTS

Pe un VPS instalat cu Ubuntu 24.04 si LVM, rezultatul arata cam asa:

NAME    SIZE FSTYPE      MOUNTPOINTS
loop0   1.2G squashfs    /run/live/rootfs/filesystem.squashfs
sr0     1.4G iso9660     /run/live/medium
vda      50G
|-vda1    1G vfat
|-vda2    2G ext4
`-vda3   47G LVM2_member

Cum il citesti: sr0 e CD-ul virtual cu ISO-ul, loop0 e sistemul de fisiere comprimat al sistemului live, iar vda e discul tau real. Pe KVM cu virtio, discul se numeste de obicei vda; cu SCSI emulat e sda, iar cu NVMe e nvme0n1 (partitiile arata atunci ca nvme0n1p1). Adapteaza toate comenzile de mai jos la numele tale.

Coloana FSTYPE iti spune ce e fiecare partitie:

• vfat, in jur de 1 GB sau mai mica: partitia de sistem EFI. Nu pe ea o cautam.
• ext4 mica, 1-2 GB: foarte probabil /boot. Nici pe ea.
• LVM2_member: un physical volume LVM. Sistemul tau de fisiere root e inauntru, treci la pasul 3.
• crypto_LUKS: o partitie criptata. O deblochezi in pasul 3, apoi activezi LVM-ul din interior.
• o singura partitie ext4 mare si nimic altceva: tipic pentru template-urile de VPS si imaginile cloud. Aceea e partitia root, sari peste pasul 3. (Imaginile cloud Ubuntu 24.04, de exemplu, au root pe vda1 si un /boot separat pe vda16.)

Daca sub vda3 apar deja volume LVM, sistemul live le-a activat automat. Nu e nicio problema, pasul 3 doar va confirma asta. Pentru mai multe detalii, inclusiv UUID-uri si etichete, blkid afiseaza tot ce poate identifica.

Pasul 3: Activezi LVM (si deblochezi LUKS, daca e cazul)

Sari peste acest pas daca la pasul 2 ai vazut o partitie root ext4 simpla.

Daca partitia e crypto_LUKS, deblocheaz-o mai intai. cryptroot e doar un nume ales de noi pentru dispozitivul deblocat:

cryptsetup open /dev/vda3 cryptroot

Scrie passphrase-ul cand ti se cere. Nu apare nimic pe ecran in timp ce scrii. Daca reuseste, nu primesti niciun mesaj, dar apare un dispozitiv nou, /dev/mapper/cryptroot. Daca rulezi din nou lsblk, ar trebui sa-l vezi sub vda3, cu tipul LVM2_member, pentru ca installer-ele Debian si Ubuntu pun LVM in interiorul LUKS.

Un mic detaliu: sistemul tau instalat foloseste propriul nume pentru acest dispozitiv, scris in /etc/crypttab (Debian foloseste de obicei ceva de genul vda3_crypt, Ubuntu 24.04 ceva de genul dm_crypt-0). Pentru resetarea parolei, numele nu conteaza. Conteaza doar daca vrei sa reconstruiesti initramfs-ul din chroot; in acel caz deschide dispozitivul cu acelasi nume ca in crypttab.

Acum activezi LVM:

vgscan
vgchange -ay
lvs

vgscan cauta volume group-uri pe toate discurile, vgchange -ay activeaza toate volumele logice gasite, iar lvs le listeaza. Rezultatul asteptat pe Ubuntu (coloanele lvs sunt scurtate aici):

  Found volume group "ubuntu-vg" using metadata type lvm2
  1 logical volume(s) in volume group "ubuntu-vg" now active
  LV        VG        Attr       LSize
  ubuntu-lv ubuntu-vg -wi-a----- <47.00g

Numele difera intre distributii. Ubuntu foloseste volume group-ul ubuntu-vg cu un singur LV, ubuntu-lv. Debian denumeste grupul dupa hostname, de exemplu myhost-vg, cu LV-uri numite root si swap_1 (uneori si home, var sau tmp, daca ai ales partitii separate). LV-ul root e accesibil ca /dev/VG/LV, de exemplu /dev/ubuntu-vg/ubuntu-lv, sau prin echivalentul /dev/mapper/ubuntu--vg-ubuntu--lv (device mapper dubleaza liniutele din nume, e normal).

Daca primesti “command not found” pentru vgchange sau cryptsetup, imaginea live nu are uneltele. Le instalezi cu apt install -y lvm2 cryptsetup (ai nevoie de configurarea de retea de la pasul 1) sau folosesti SystemRescue, care le include pe amandoua.

Pasul 4: Montezi sistemul de fisiere root

Daca serverul nu mai pornea din cauza erorilor de sistem de fisiere, acum e momentul sa-l verifici, inainte de montare (fsck nu se ruleaza niciodata pe un sistem de fisiere montat):

fsck -f /dev/ubuntu-vg/ubuntu-lv

Apoi montezi sistemul de fisiere root pe /mnt. Alege linia potrivita pentru structura ta:

# Ubuntu cu LVM
mount /dev/ubuntu-vg/ubuntu-lv /mnt

# Debian cu LVM (inlocuieste myhost cu numele volume group-ului tau)
mount /dev/myhost-vg/root /mnt

# partitie simpla, fara LVM
mount /dev/vda1 /mnt

Liniile care incep cu # sunt comentarii, ruleaza doar linia mount de care ai nevoie. Apoi verifica daca ai montat ce trebuie:

ls /mnt
cat /mnt/etc/os-release

Ar trebui sa vezi folderele cunoscute (bin, boot, etc, home, usr, var si asa mai departe), iar os-release ar trebui sa-ti numeasca distributia. Daca in schimb vezi grub, lost+found si fisiere de tip vmlinuz-..., ai montat din greseala /boot: ruleaza umount /mnt si incearca cealalta partitie.

Pentru resetarea parolei ajunge sistemul de fisiere root. Daca vrei sa repari si procesul de boot din chroot (reinstalare GRUB, reconstruire initramfs), uita-te in /mnt/etc/fstab si monteaza si partitiile separate /boot si EFI:

mount /dev/vda2 /mnt/boot
mount /dev/vda1 /mnt/boot/efi

Pasul 5: Bind mount pentru /dev, /proc si /sys, apoi chroot

Programele care ruleaza in chroot au in continuare nevoie de sistemele de fisiere virtuale ale kernelului: /dev (dispozitive, inclusiv terminalul in care scrii), /proc (procese) si /sys (informatii despre hardware si kernel). Pe discul tau exista doar foldere goale pentru ele. Le umplem prin “bind mount”, care face ca folderele sistemului live sa apara si intr-un al doilea loc:

mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
mount -t proc proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
chroot /mnt /bin/bash

--rbind aduce si tot ce e montat dedesubt (de exemplu /dev/pts, de care au nevoie terminalele). --make-rslave se asigura ca demontarile de mai tarziu nu se propaga inapoi si nu strica sistemul live. Ultima linie porneste un shell bash cu /mnt drept radacina.

Prompt-ul poate arata in continuare hostname-ul sistemului live, pentru ca hostname-ul tine de kernelul care ruleaza, nu de disc. Ca sa confirmi ca esti in serverul tau, verifica fisierele:

cat /etc/hostname
ls /home

Ar trebui sa vezi numele serverului si folderele home ale utilizatorilor tai. De acum, orice comanda actioneaza asupra sistemului instalat.

Pasul 6: Setezi parola noua

Acesta e momentul spre care am lucrat:

passwd root

Rezultatul asteptat:

New password:
Retype new password:
passwd: password updated successfully

Nu apare nimic pe ecran in timp ce scrii, e normal. Poti confirma starea contului cu passwd -S root: al doilea camp ar trebui sa fie P (parola utilizabila). L inseamna blocat, iar NP inseamna fara parola.

Aici conteaza o diferenta intre Debian si Ubuntu. Pe Ubuntu, contul root e blocat implicit si se presupune ca folosesti utilizatorul cu sudo. Pe Debian depinde de installer: daca ai setat o parola de root, root e activ, iar utilizatorul tau obisnuit poate nici sa nu fie in grupul sudo; daca ai lasat-o goala, root e blocat, iar primul utilizator a primit drepturi sudo. De multe ori e mai bine sa resetezi parola propriului utilizator decat sa activezi root:

getent group sudo
passwd alex

Prima comanda listeaza membrii grupului sudo (de exemplu sudo:x:27:alex). Inlocuieste alex cu numele tau de utilizator. Daca utilizatorul lipseste din grup, il adaugi cu usermod -aG sudo alex. Daca chage -l alex arata un cont expirat, anulezi expirarea cu chage -E -1 alex, iar daca passwd -S alex arata L, il deblochezi cu passwd -u alex.

Daca tot esti aici, poti reface si accesul cu cheie SSH, care oricum e solutia mai buna pe termen lung:

mkdir -p /home/alex/.ssh
echo "ssh-ed25519 AAAA...cheia-ta-publica... tu@laptop" >> /home/alex/.ssh/authorized_keys
chown -R alex:alex /home/alex/.ssh
chmod 700 /home/alex/.ssh
chmod 600 /home/alex/.ssh/authorized_keys

E important ca chown sa fie rulat in chroot: numele de utilizatori sunt cautate in /etc/passwd de pe serverul tau. In afara chroot-ului, alex ar fi cautat in sistemul live si ar putea corespunde altui ID numeric sau ar putea sa nu existe deloc.

O nota pentru cei care administreaza si sisteme din familia RHEL: acolo, cu SELinux in modul enforcing, trebuie sa rulezi touch /.autorelabel dupa ce modifici fisiere din chroot. Debian si Ubuntu folosesc AppArmor, care nu cere nimic aici.

Pasul 7: Curatenie, scoti ISO-ul si repornesti

Iesi din chroot, demonteaza totul curat si inchide LVM si LUKS. Sari peste linia vgchange daca nu ai folosit LVM si peste linia cryptsetup daca nu ai folosit LUKS:

exit
cd /
umount -R /mnt
vgchange -an ubuntu-vg
cryptsetup close cryptroot
sync
poweroff

exit te intoarce in shell-ul sistemului live. cd / se asigura ca shell-ul tau nu sta in /mnt, ceea ce ar bloca demontarea. umount -R demonteaza /mnt si tot ce e sub el, in ordinea corecta. vgchange -an dezactiveaza volume group-ul (pe Debian folosesti numele VG-ului tau), cryptsetup close blocheaza din nou dispozitivul criptat, iar sync scrie pe disc orice date ramase in asteptare.

Acum intoarce-te in panou: detaseaza ISO-ul, seteaza ordinea de boot inapoi pe disc si porneste VPS-ul. Unele panouri aplica schimbarea ordinii de boot doar dupa o oprire completa, de aceea am folosit poweroff in loc de reboot. Logheaza-te mai intai prin consola VNC cu parola noua si abia apoi incearca SSH, ca sa stii imediat daca o eventuala problema tine de parola sau de configuratia SSH.

Probleme frecvente si greseli comune

• “mount: unknown filesystem type ‘LVM2_member’” sau “‘crypto_LUKS’”: ai incercat sa montezi direct partitia container. Deblocheaz-o si activeaz-o la pasul 3, apoi monteaza volumul logic, nu vda3.
• “Volume group not found” sau nu apare niciun LV: ruleaza pvs ca sa vezi daca PV-ul e detectat. Daca discul e criptat, trebuie sa deschizi mai intai LUKS. In cazul rar in care sistemul live are propriul VG cu acelasi nume, redenumeste-l temporar pe al tau dupa UUID, cu vgrename, si readu-i numele inapoi inainte de reboot.
• “chroot: failed to run command ‘/bin/bash’: No such file or directory”: ai montat partitia gresita (de obicei /boot) sau ai pornit un ISO pentru alta arhitectura de procesor. Pentru un VPS obisnuit foloseste un ISO amd64.
• “passwd: Authentication token manipulation error”: sistemul de fisiere e read-only, plin sau /etc/shadow e imuabil. Iesi din chroot si ruleaza mount -o remount,rw /mnt; verifica spatiul liber cu df -h /mnt; verifica atributele cu lsattr /mnt/etc/shadow si scoate flag-ul i cu chattr -i /mnt/etc/shadow.
• Parola merge in consola, dar nu prin SSH: SSH are regulile lui. Atat pe Debian cat si pe Ubuntu, PermitRootLogin are implicit valoarea prohibit-password, deci root se poate loga doar cu cheie. Verifica si PasswordAuthentication in /etc/ssh/sshd_config si in fisierele din /etc/ssh/sshd_config.d/ (imaginile cloud Ubuntu au deseori acolo un 50-cloud-init.conf care o modifica).
• Parola e “gresita” imediat dupa ce ai setat-o: consola VNC poate folosi alt layout de tastatura decat crezi, asa ca simboluri ca @, #, y si z ajung altceva. Seteaza o parola temporara doar din litere mici si cifre, logheaza-te, apoi schimb-o cu passwd prin SSH, unde se foloseste tastatura ta.
• “umount: /mnt: target is busy”: un shell sau un program e inca in /mnt. Ruleaza cd /, inchide sesiunile SSH suplimentare catre sistemul live si incearca din nou.
• VPS-ul porneste tot in sistemul de rescue: ISO-ul e inca atasat sau ordinea de boot inca prefera CD-ROM-ul. Corecteaza in panou si fa o oprire completa.

Note de securitate

Procedura asta iti aminteste un adevar incomod: cine controleaza consola si procesul de boot controleaza serverul. Nicio parola, niciun GRUB blocat si nicio regula sudo nu opreste pe cineva care poate porni propriul sistem de operare pe masina ta virtuala. Cateva consecinte practice:

• Protejeaza panoul de client la fel cum protejezi root. Foloseste o parola lunga si unica si autentificare in doi pasi pe contul DreamServer. Accesul la panou inseamna practic acces root, pentru ca iti da consola si boot de pe ISO.
• O parola pe GRUB nu e o bariera de securitate impotriva boot-ului de pe ISO. Opreste doar editarea ocazionala a parametrilor de kernel din consola, nimic mai mult. Daca ai nevoie ca datele sa ramana private chiar si fata de cineva cu acces la consola, raspunsul e criptarea completa a discului cu LUKS. Compromisul: trebuie sa introduci passphrase-ul la fiecare boot (prin consola VNC), iar daca il pierzi, datele sunt pierdute definitiv.
• Prefera cheile SSH in locul parolelor. Dupa ce recapeti accesul, pastreaza PasswordAuthentication no si PermitRootLogin prohibit-password (sau no) in configuratia SSH si foloseste un manager de parole pentru parola pe care tocmai ai setat-o, ca sa nu se mai repete situatia.
• Afla de ce ai ramas fara acces. Daca esti sigur ca nimeni din echipa nu a schimbat parola, trateaza situatia ca pe un posibil compromis, nu ca pe o scapare de memorie. Uita-te in istoricul de logari inainte sa repornesti serviciile. Pe Ubuntu 24.04 exista clasicul /var/log/auth.log. Debian 13 nu instaleaza rsyslog implicit, deci logurile sunt doar in jurnalul systemd; din sistemul live il poti citi cu journalctl -D /mnt/var/log/journal. Daca ceva pare in neregula, schimba toate secretele de pe server (parole, chei API, chei SSH), nu doar parola de root.
• Nu lasa ISO-ul atasat. Pe langa bucla de boot, un ISO atasat e inca o cale de intrare in masina daca cineva obtine acces la panou.

Deci, tine metoda asta la indemana

Tehnica cu ISO de rescue si chroot e metoda care functioneaza atunci cand toate celelalte trucuri de recuperare esueaza: GRUB blocat, boot stricat, disc criptat cu LVM, toate. Pornesti ISO-ul, gasesti discul, activezi LVM, montezi, faci chroot, rulezi passwd, faci curatenie. Sapte pasi, cam un sfert de ora, iar datele tale nu se misca niciun bit. Merita sa o exersezi o data pe o masina de test, pentru ca acelasi chroot e si calea prin care repari un GRUB stricat sau un update de kernel esuat.

Daca vrei un server unde ai toate acestea la indemana, un VPS KVM de la DreamServer vine cu acces la consola si boot de pe ISO direct din panou. Iar daca preferi sa nu ajungi niciodata singur in fata unui server blocat la 2 noaptea, echipa noastra de administrare servere se poate ocupa de recuperarea accesului, de securizarea SSH si de backup-uri in locul tau.

Intrebari frecvente

Pot edita /etc/shadow de mana in loc sa folosesc chroot?

Poti, dar e usor sa gresesti: ar trebui sa generezi singur un hash yescrypt corect si sa-l lipesti in campul potrivit fara sa strici fisierul. O alternativa mai curata la un chroot complet este passwd --root /mnt root (sau chpasswd -R /mnt), care ii spune unealtei sa lucreze pe sistemul montat. Chroot-ul complet ramane util pentru ca in aceeasi sesiune poti repara si grupurile sudo, cheile SSH si problemele de boot.

Se sterg sau se modifica datele mele?

Nu. Singurul fisier care se schimba e /etc/shadow (plus orice alt fisier pe care il editezi intentionat). Montarea si citirea unui sistem de fisiere nu modifica datele. Singura actiune riscanta ar fi rularea fsck pe un sistem de fisiere montat, de aceea il rulam inainte de montare.

Merge si daca discul e criptat cu LUKS?

Da, cu conditia sa stii passphrase-ul LUKS. Deblochezi partitia cu cryptsetup open la pasul 3 si continui normal. Fara passphrase nu exista nicio cale de intrare, exact ce promite criptarea.

De ce nu merge noua parola de root prin SSH?

Pentru ca Debian si Ubuntu folosesc implicit PermitRootLogin prohibit-password, care permite logarea root prin SSH doar cu cheie. Logheaza-te prin SSH cu utilizatorul cu sudo sau foloseste consola VNC pentru root. Nu recomandam schimbarea acestei setari ca sa permiti parole pentru root.

Pot folosi metoda asta pe un VPS LXC?

Nu. Containerele LXC, privilegiate sau neprivilegiate, folosesc kernelul host-ului si nu au bootloader propriu, deci nu ai in ce sa pornesti un ISO. Pentru LXC foloseste functiile de resetare parola sau reinstalare din panou, sau contacteaza suportul.