Paano Palitan ang Root Password ng VPS sa Ubuntu

Paano baguhin ang root password ng iyong VPS sa Ubuntu

Para baguhin ang root password ng iyong VPS (virtual private server) sa Ubuntu, magbukas ng SSH (secure shell) session bilang user na maaaring magpatakbo ng sudo, pagkatapos ay patakbuhin ang sudo passwd root. Hihingin nito ang bagong password nang dalawang beses at hindi hihingin ang lumang password dahil napatunayan na ng sudo ang iyong pagkakakilanlan. Para baguhin naman ang sarili mong login password, patakbuhin ang passwd nang walang mga argument, at hihingin muna nito ang kasalukuyan mong password.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Iyon ang buong proseso. Ang mga sumusunod na bahagi ang karaniwang nagkakaproblema: pagtiyak na gumagana ang bagong password bago mawala ang session na maaaring gamitin para ayusin ito, pagtatakda ng mga password mula sa script, sadyang pagpapawalang-bisa ng password, at muling pag-access kapag nawala na ang password.

Magbukas ng pangalawang session bago magpalit ng password

Magbukas ngayon ng pangalawang SSH session at panatilihin itong nakakonekta. Halos lahat ng failure sa gabay na ito ay naaayos sa loob ng dalawang minuto habang may isang authenticated shell na bukas pa, ngunit mangangailangan ng pag-access sa console kapag nagsara ang huli.

Patuloy na gumagana ang shell na bukas na bago mo baguhin, i-lock, o i-expire ang account na kinabibilangan nito, dahil sinusuri ng SSH ang mga credential sa oras ng login at hindi na muling sinusuri ang mga ito. Ang exception ay sudo. Muli nitong sinusuri ang iyong password sa pamamagitan ng PAM (pluggable authentication modules) kapag nag-expire ang timestamp nito, na karaniwang 15 minuto pagkatapos ng huling prompt. Kaya unang tunay na masusubok ang bagong password sa susunod na hingin ito ng sudo, hindi sa oras ng login.

Subukan ang bagong password sa pangalawang session habang nananatiling bukas ang una.

Palitan ang sarili mong password gamit ang passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully lamang ang output na nangangahulugang napalitan ang hash sa /etc/shadow. Anumang ibang output ay nangangahulugang nanatili ang dating password.

Dalawang failure ang nangyayari rito. Ang passwd: Authentication token manipulation error, na sinusundan ng passwd: password unchanged, ay nangangahulugang mali ang kasalukuyang password na inilagay mo, o hindi maaaring sulatan ang filesystem na naglalaman ng /etc/shadow, na karaniwang kalagayan sa recovery mode. Ang You must choose a longer password. ay nagmumula sa pam_unix sa /etc/pam.d/common-password, na naglalapat ng mga pagsusuri sa haba at pagkakatulad para sa mga ordinaryong user.

Sa karamihan ng VPS image, walang password ang default account (ubuntu, o anumang pangalang ibinibigay ng iyong provider); SSH key lamang ang mayroon ito. Walang kasalukuyang password na ibe-verify ang passwd, kaya hindi nito malalampasan ang unang prompt. Sa halip, gamitin ang sudo passwd $USER. Gumagana ito dahil pinahihintulutan ng sudoers drop-in file ng image ang account na iyon na patakbuhin ang sudo nang walang password.

Palitan ang password ng ibang user gamit ang sudo passwd

sudo passwd deploy

Hindi hinihingan ang root ng lumang password, at nilalampasan ng pam_unix ang mga pagsusuri sa lakas ng password na inilalapat sa mga karaniwang user. Kaya maaaring magtakda ang root ng password na hindi kayang itakda ng user para sa sarili niya.

Hiwalay na aksyon ang pag-lock. Naglalagay ang sudo passwd -l deploy ng ! bago ang nakaimbak na hash, kaya walang password ang tutugma rito. Inaalis ito ng sudo passwd -u deploy. Basahin muli ang status gamit ang sudo passwd -S deploy.

Hindi pinipigilan ng pag-lock ng password ang user na mag-login. Gumagana pa rin ang anumang key sa kanilang ~/.ssh/authorized_keys, dahil hindi binabasa ng public key authentication ang /etc/shadow. Para ganap na pigilan ang account, i-expire mismo ang account:

sudo usermod --expiredate 1 deploy

Itinatakda nito ang pag-expire ng account sa petsa noong 1970, kaya tinatanggihan ng sshd ang login anuman ang credential na gamitin. Ibalik ito gamit ang sudo usermod --expiredate '' deploy.

Iwasan ang passwd -d. Nagtatakda ito ng walang laman na password sa halip na naka-lock na password. Sa mas lumang release na mayroon pa ring nullok sa PAM stack, ang walang laman na password ay maaaring gamitin ng kahit sino.

Kailangan ba ng password ang root sa isang VPS?

Naka-lock ang root sa Ubuntu. Ang /etc/shadow ay naglalaman ng ! sa halip na hash, at nagpi-print ang sudo passwd -S root ng linyang nagsisimula sa root L. Walang makakapag-log in bilang root gamit ang password hangga't hindi ka nagtatakda nito. Ito ang dahilan kung bakit binibigyan ka ng image ng user na may kakayahang gumamit ng sudo. Panatilihin ang pattern na gumamit ng mga user account na may least privilege sa isang VPS sa halip na root.

Isang partikular na bagay lang ang ibinibigay ng pagtatakda ng root password: paraan para makapasok gamit ang provider console. Kumokonekta ang console na ito sa virtual machine sa ilalim ng network stack, kaya patuloy itong gumagana kapag mali ang configuration ng sshd o may maling firewall rule. May kapalit din ito. Hinihingi ng root shell ng GRUB recovery menu ang root password kapag mayroon nito ang root. Dahil dito, ang tool na gagamitin mo sana para i-reset ang nakalimutang password ay nasa likod na ngayon ng parehong password.

Hindi pinapahintulutan ng pagtatakda ng root password ang root na mag-log in gamit ang SSH. Kasama ng Ubuntu ang PermitRootLogin prohibit-password, na nangangahulugang keys lang. Suriin kung ano talaga ang ginagamit ng iyong server:

sudo sshd -T | grep -i permitrootlogin

Pini-print ng sshd -T ang epektibong configuration matapos ma-resolve ang bawat linyang Include. Kaya ito lang ang maaasahang sagot kapag may mga drop-in file ang /etc/ssh/sshd_config.d/.

Magtakda ng password mula sa script gamit ang chpasswd

passwd ay nagbabasa mula sa terminal at hindi maaaring patakbuhin mula sa script. Ang chpasswd ay nagbabasa ng mga pares na user:password mula sa standard input, tig-isa bawat linya.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Gumagana ito, ngunit inilalagay nito ang plaintext password sa history ng iyong shell at sa mga log ng iyong CI (continuous integration). I-hash muna ito:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

Ang openssl passwd -6 ay humihingi ng password nang dalawang beses nang hindi ipinapakita ang input, at pagkatapos ay nagpi-print ng SHA-512 crypt hash na nagsisimula sa $6$. Sinasabi ng -e sa chpasswd na naka-hash na ang ikalawang field, kaya kinokopya ito sa /etc/shadow nang walang pagbabago. Ligtas itago ang hash sa isang repository o CI variable, at hindi umaalis sa machine kung saan mo ito ipinasok ang plaintext.

Ang Ubuntu 24.04 ay nagha-hash ng mga bagong password gamit ang yescrypt ($y$) kapag itinatakda ng passwd ang mga ito, samantalang SHA-512 ang ginagamit ng openssl passwd -6. Parehong nabe-verify ang mga ito sa pag-login dahil binabasa ng libxcrypt ang parehong format. Ayos lang ang paghahalo ng mga ito, at pareho ang gawi ng openssl passwd -6 sa bawat Ubuntu LTS release. Hindi ganoon ang chpasswd -c YESCRYPT: hindi alam ng mas lumang shadow package sa 20.04 ang pangalan ng method na iyon.

Paano tinitiyak na talagang nagbago ang password?

Magsimula sa metadata, pagkatapos ay patunayan ito sa pamamagitan ng pag-login.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

Ang ikalawang field ang state: P para sa magagamit na password, L para sa naka-lock, at NP para sa walang password. Ipinapakita ng petsa kung kailan huling binago ang password, kaya dapat itong tumugma sa petsa ngayon. Ang mga numerong kasunod nito ay ang mga aging field na tinatalakay sa ibaba.

Ang pinakaligtas na live test ay ang sudo mismo. Itinatapon ng sudo -k ang naka-cache na timestamp, at pinipilit ng sudo -v ang isang bagong prompt. Kung tinanggap doon ang bagong password, tinanggap ito ng PAM, at walang nagbago sa iyong session.

sudo -k && sudo -v

Para subukan ang ibang account, patakbuhin ang su - deploy mula sa isang unprivileged shell. Huwag patakbuhin ang sudo su - deploy, dahil hindi kailanman hinihingan ng password ang root at walang napapatunayan ang test. Ang maling password ay nagpi-print ng su: Authentication failure.

Ang aktuwal na test ay isang bagong SSH login mula sa iyong laptop habang nakabukas pa ang gumaganang session:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Ang Permission denied (publickey). dito ay nangangahulugang hindi nag-alok ang server ng password authentication, kaya walang pagbabago sa password ang makapagpapapasok sa iyo. Ang Permission denied, please try again. ay nangangahulugang nag-alok ito nito ngunit tinanggihan ang iyong inilagay.

Pilitin ang pagpapalit ng password sa susunod na login gamit ang chage

sudo chage -d 0 deploy

Itinatakda ng -d 0 ang petsa ng huling pagbabago sa epoch, kaya itinuturing ng PAM na expired ang password. Sa susunod na interactive login, hinihingi muna ang kasalukuyang password, kasunod ang bagong password, bago ibigay ang shell. Pareho mismo ang ginagawa ng sudo passwd -e deploy.

Gamitin lamang ito sa mga account na nagla-login nang interactive gamit ang password. Naaapektuhan din ng expired na password ang mga key-based login, dahil pinapatakbo ng sshd ang PAM account stage kahit key ang ginamit sa authentication. Pagkatapos, mabibigo ang naka-script na ssh deploy@203.0.113.10 'systemctl restart app' dahil dito at hihinto:

Password change required but no TTY available.

Walang tatakbo pagkatapos ng linyang iyon, at non-zero exit code lamang ang iuulat ng job.

Ano ang ibig sabihin ng mga field para sa password aging

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Ang mga numerong iyon ay fields 4 hanggang 8 ng linya ng user na iyon sa /etc/shadow. Ang minimum days (chage -m) ay kung gaano katagal dapat maghintay ang user bago muling magpalit ng password. Pinipigilan nito ang user na agad bumalik sa dating password pagkatapos ng sapilitang pagpapalit. Ang maximum days (chage -M) ay kung gaano katagal mananatiling valid ang password. Ang warning days (chage -W) ay kung kailan magsisimulang mag-print ng warning ang mga login. Ang inactive days (chage -I) ay ang grace period pagkatapos mag-expire bago tuluyang hindi na tanggapin ang password. Ang account expiry (chage -E) ay isang hard date at hiwalay ito sa password.

sudo chage -M 90 -W 14 deploy

Itakda lamang ito kapag kailangan ng policy. Mula pa noong 2017, ipinapayo ng NIST (ang US National Institute of Standards and Technology) na iwasan ang regular na password expiry. Itinutulak kasi nito ang mga tao na gumamit ng mga predictable na variation ng iisang password. Inirerekomenda nitong sapilitang magpalit lamang kapag may ebidensiya ng compromise. Mas ligtas ang isang mahaba at unique na password na naka-save sa password manager, kasama ang key based SSH, kaysa sa 90 day cycle.

Ano ang gagawin kapag nawala ang root password

Kung may account sa server na maaaring magpatakbo ng sudo, walang kailangang i-recover: nagtatakda ang sudo passwd root ng bagong password. Ang mahirap na kaso ay kapag wala nang gumaganang login.

Kailangan ng lahat ng nasa ibaba ang provider console, na karaniwang nakalista sa mga panel bilang VNC (virtual network computing) o serial console. Direktang kumokonekta ito sa virtual machine sa ilalim ng network stack, kaya hindi ito naaapektuhan ng mga setting ng sshd at firewall rules.

1. I-reboot ang server mula sa panel at i-monitor ang console.
2. Buksan ang GRUB menu. Karaniwang itinatakda ng mga cloud image ang GRUB_TIMEOUT=0, kaya pindutin nang matagal ang Shift sa BIOS boot, o paulit-ulit na pindutin ang Esc sa UEFI boot, sa sandaling magsimula ang reboot.
3. Piliin ang Advanced options for Ubuntu, pagkatapos ang entry na nagtatapos sa (recovery mode), at pagkatapos ang root sa recovery menu.
4. Patakbuhin muna ang mount -o remount,rw /. Nima-mount ng recovery ang root filesystem bilang read-only, kaya kung wala ito, mabibigo ang passwd gamit ang passwd: Authentication token manipulation error dahil hindi nito maisusulat ang /etc/shadow.
5. Patakbuhin ang passwd ubuntu para sa account na kailangan mo, pagkatapos ay i-reboot mula sa panel.

Kung may password na ang root at iyon ang nawala sa iyo, hihingin ng recovery shell ang password na iyon at hindi na magagamit ang paraang ito. Sa halip, mag-boot mula sa rescue image ng provider, i-mount ang aktuwal na disk, at baguhin ang password sa loob nito.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Basahin ang partition layout mula sa lsblk sa halip na kopyahin ang /dev/vda1 mula sa pahinang ito. Ang root partition ang pinakamalaki. Sa UEFI image, nasa tabi nito ang maliit na EFI partition na walang /etc directory.

Ano ang gagawin kapag hindi na tinatanggap ng SSH ang iyong password

Magtrabaho mula sa session na mayroon ka pa. Kung wala nang natitirang session, gamitin ang console.

Ang Permission denied, please try again. ay nangangahulugang nag-alok ang server ng password authentication at tinanggihan nito ang ipinadala mo. Karaniwang sanhi ang naka-on na caps lock o keyboard layout sa console na iba sa ginamit mo noong itinakda mo ang password.

Ang Permission denied (publickey). ay nangangahulugang hindi kailanman nag-alok ang server ng password authentication. Nakatakda sa isang lugar ang PasswordAuthentication no, at sa Ubuntu 22.04 at mas bago, karaniwan itong nasa isang drop-in file sa ilalim ng /etc/ssh/sshd_config.d/ na nag-o-override sa pangunahing file. Basahin ang mga aktuwal na value:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

Ang KbdInteractiveAuthentication yes kasabay ng PasswordAuthentication no ay nagbibigay-daan pa rin sa password, dahil ginagamit ng keyboard-interactive method ang parehong PAM stack. Kapag isa lang ang pinatay at iniwan ang isa na naka-on, patuloy na tatanggap ang server ng mga password na tina-type kahit mukhang key-only ito.

Ang Too many authentication failures sa disconnect message ay nangangahulugang nag-alok ang iyong client ng ilang key bago ito umabot sa password, at naabot ng server ang MaxAuthTries, na 6 bilang default. Pilitin ang iisang method:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Ang Connection refused sa port na gumana isang minuto lang ang nakalipas ay karaniwang nangangahulugang bina-ban ng fail2ban na nagmo-monitor sa SSH ang iyong address matapos ang paulit-ulit na mga failure. Ang default nitong ban rule ay nagre-reject ng packet sa halip na i-drop ito, kaya mabilis bumabalik ang refusal sa halip na mag-timeout. Mula sa console, inililista ng sudo fail2ban-client status sshd ang mga banned address, at inaalis ng sudo fail2ban-client set sshd unbanip 203.0.113.10 ang ban sa iyong address.

Ang password ay pansamantalang hakbang; ang mga key ang panghuling estado

Ang password na gumagana sa SSH ay password na maaaring hulaan ng bawat scanner sa internet. Gumamit ng key-based authentication upang hindi na mahalaga ang paghula. Bumuo ng key pair, i-install ang public half, at kumpirmahing nakakapag-login ang key mula sa pangalawang terminal bago ka magbago ng iba pa. Sinasaklaw ng mga pangunahing kaalaman sa pamamahala ng SSH key ang pagbuo, authorized_keys at mga passphrase.

Pagkatapos, i-off ang password authentication at kumpirmahin ito gamit ang sudo sshd -T sa halip na basta magtiwala sa file na in-edit mo. Tinutukoy ng pagpapatibay ng SSH sa isang VPS ang iba pang sshd setting na dapat baguhin, at inilalagay ng unang sampung minuto sa bagong VPS ang mga ito sa tamang pagkakasunod-sunod para sa bagong server.

Magtabi ng isang password pagkatapos nito. Ang server na key-only at may sirang sshd config ay maa-access lamang sa pamamagitan ng provider console, at humihingi ang console na iyon ng username at password. Ang account na may matibay na password na nakaimbak sa ligtas na lugar ang naghihiwalay sa limang minutong pag-aayos mula sa muling pag-install.

FAQ

Paano ko babaguhin ang root password sa aking VPS kung hindi ko alam ang dating password?

Mag-login bilang user na maaaring magpatakbo ng sudo at patakbuhin ang sudo passwd root. Nagtatakda ito ng bagong password nang hindi hinihingi ang dating password, dahil na-authenticate ka na ng sudo. Kung walang account sa server na maaaring magpatakbo ng sudo, buksan ang provider console, mag-reboot papunta sa GRUB recovery menu, piliin ang root shell entry, patakbuhin ang mount -o remount,rw /, at pagkatapos ay patakbuhin ang passwd. Kung may password na ang root at iyon ang nawala sa iyo, hihingin ito ng recovery shell. Ang natitirang paraan ay gamitin ang rescue image ng provider, i-mount ang disk, at mag-chroot.

Bakit sinasabi ng passwd ang “Authentication token manipulation error”?

Dalawang sanhi ang nagbubunga ng mensaheng iyon. Ang karaniwang sanhi ay maling sagot sa Current password: prompt. Kinukumpirma ng passwd: password unchanged line sa ilalim nito na walang naisulat. Ang isa pang sanhi ay filesystem na hindi maaaring sulatan. Ito ang nangyayari sa recovery mode dahil read-only ang pagkaka-mount ng / doon. Patakbuhin ang mount -o remount,rw / at subukan muli.

Binabago rin ba ng pagpapalit ng Linux password ang sudo password ko?

Oo. Walang sariling password ang sudo. Ina-authenticate ka nito sa pamamagitan ng PAM laban sa parehong /etc/shadow entry na ginagamit ng SSH at su, kaya iisa ang password ng bawat account. Ito rin ang dahilan kung bakit ang unang sudo prompt pagkatapos ng pagpapalit ay ang aktuwal na pagsusuri. Patakbuhin ang sudo -k && sudo -v upang pilitin ang prompt na iyon habang may gumagana ka pang session.

Masisira ba ng pagpapalit ng password ang aking SSH keys o mga bukas kong session?

Hindi. Hindi kailanman binabasa ng public key authentication ang /etc/shadow, kaya patuloy na gagana ang mga key pagkatapos ng pagpapalit ng password, pagkatapos ng passwd -l, at pagkatapos ng chage -d 0. Mananatiling bukas ang mga session na aktibo na dahil sinusuri lamang ng SSH ang credentials sa oras ng pag-login. Ang tanging nagbabago sa loob ng live session ay ang sudo, na humihingi ng bagong password kapag nag-expire ang 15 minute timestamp nito.

Paano ko pipilitin ang isang user na palitan ang kanilang password sa susunod na pag-login?

Patakbuhin ang sudo chage -d 0 deploy o sudo passwd -e deploy, na pareho ang ginagawa. Itinatakda sa epoch ang nakaimbak na petsa ng huling pagpapalit. Itinuturing ng PAM na expired ang password, kaya kailangang magtakda ng bagong password ang susunod na interactive login bago magsimula ang shell. Huwag itong gawin sa account na ginagamit ng mga script sa SSH. Mabibigo ang non-interactive command sa Password change required but no TTY available. at hindi ito tatakbo.