Jinsi ya kubadilisha nenosiri la root kwenye VPS Ubuntu

Jinsi ya kubadilisha nenosiri la root kwenye VPS yako kwa Ubuntu

Ili kubadilisha nenosiri la root la VPS yako (seva pepe binafsi) kwenye Ubuntu, fungua kipindi cha SSH (shell salama) ukiwa kama mtumiaji anayeweza kuendesha sudo, kisha endesha sudo passwd root. Itaomba nenosiri jipya mara mbili na haiombi la zamani, kwa sababu sudo tayari imethibitisha utambulisho wako. Ili kubadilisha nenosiri lako la kuingia badala yake, endesha passwd bila hoja, nayo itaomba nenosiri lako la sasa kwanza.

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

Huo ndio utaratibu wote. Yafuatayo yanaeleza sehemu zinazoweza kushindikana: kuthibitisha kuwa nenosiri jipya linafanya kazi kabla ya kupoteza kipindi kinachoweza kutumika kurekebisha tatizo, kuweka manenosiri kutoka kwenye script, kulifanya moja liishe kwa makusudi, na kurejesha ufikiaji wakati nenosiri tayari limepotea.

Fungua kikao cha pili kabla ya kubadilisha nenosiri

Fungua kikao cha pili cha SSH sasa na ukiache kikiwa kimeunganishwa. Takriban hitilafu zote katika mwongozo huu hutatuliwa ndani ya dakika mbili wakati shell moja iliyothibitishwa bado iko hai, lakini huhitaji kufikia koni mara ya mwisho inapofungwa.

Shell ambayo tayari imefunguliwa huendelea kufanya kazi baada ya kubadilisha, kufunga au kumaliza muda wa akaunti yake, kwa sababu SSH hukagua vitambulisho wakati wa kuingia na haivikagui tena. Isipokuwa ni sudo. Hukagua tena nenosiri lako kupitia PAM (pluggable authentication modules) muhuri wa muda wake unapoisha, kwa kawaida dakika 15 baada ya ombi la mwisho. Kwa hiyo, nenosiri jipya hujaribiwa kikamilifu mara ya kwanza wakati sudo linapoliomba, si wakati wa kuingia.

Jaribu nenosiri jipya katika kikao cha pili huku cha kwanza kikiwa kimefunguliwa.

Badilisha nenosiri lako mwenyewe kwa passwd

passwd

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

passwd: password updated successfully ndiyo jibu pekee linalomaanisha kuwa heshi katika /etc/shadow ilibadilishwa. Jibu lingine lolote linamaanisha kuwa nenosiri la zamani bado linatumika.

Hitilafu mbili hutokea hapa. passwd: Authentication token manipulation error ikifuatiwa na passwd: password unchanged inamaanisha kuwa nenosiri la sasa uliloingiza si sahihi, au mfumo wa faili unaohifadhi /etc/shadow hauwezi kuandikwa. Hii ndiyo hali ya kawaida katika recovery mode. You must choose a longer password. inatokana na pam_unix katika /etc/pam.d/common-password, ambayo hutumia ukaguzi wa urefu na ufanano kwa watumiaji wa kawaida.

Kwenye picha nyingi za VPS, akaunti chaguo-msingi (ubuntu, au jina lolote ambalo mtoa huduma wako huweka) haina nenosiri kabisa; ina SSH key pekee. passwd haina nenosiri la sasa la kuthibitisha, kwa hiyo haiwezi kupita kidokezo cha kwanza. Tumia sudo passwd $USER badala yake. Hii hufanya kazi kwa sababu faili ya sudoers drop-in ya picha hiyo inaruhusu akaunti hiyo kuendesha sudo bila nenosiri.

Badilisha nenosiri la mtumiaji mwingine kwa sudo passwd

sudo passwd deploy

root haulizwi nenosiri la zamani, na pam_unix huruka ukaguzi wa uimara unaotumika kwa watumiaji wa kawaida. Kwa hiyo, root inaweza kuweka nenosiri ambalo mtumiaji huyo hangeweza kujiwekea mwenyewe.

Kufunga nenosiri ni hatua tofauti. sudo passwd -l deploy huweka ! mbele ya heshi iliyohifadhiwa, hivyo hakuna nenosiri linaloendana nayo. sudo passwd -u deploy huiondoa. Soma hali hiyo kwa sudo passwd -S deploy.

Kufunga nenosiri hakumzuii mtumiaji huyo kuingia. Ufunguo wowote katika ~/.ssh/authorized_keys yake bado utafanya kazi, kwa sababu uthibitishaji wa ufunguo wa umma hausomi /etc/shadow. Ili kuzuia akaunti kabisa, muda wa akaunti lazima uishe:

sudo usermod --expiredate 1 deploy

Hii huweka kuisha kwa akaunti kwenye tarehe ya mwaka 1970, hivyo sshd hukataa kuingia bila kujali kitambulisho kinachotolewa. Batilisha mabadiliko hayo kwa sudo usermod --expiredate '' deploy.

Epuka passwd -d. Huweka nenosiri tupu badala ya kulifunga. Katika toleo la zamani ambalo bado lina nullok kwenye mkusanyiko wa PAM, nenosiri tupu ni nenosiri ambalo mtu yeyote anaweza kutumia.

Je, root anahitaji nenosiri kwenye VPS?

Ubuntu husambaza root ikiwa imefungwa. /etc/shadow huhifadhi ! badala ya heshi, na sudo passwd -S root huchapisha mstari unaoanza na root L. Hakuna anayeweza kuingia kama root kwa kutumia nenosiri hadi uweke nenosiri hilo. Ndiyo sababu image hukupatia mtumiaji mwenye uwezo wa kutumia sudo. Endelea kutumia akaunti za mtumiaji zenye haki ndogo kwenye VPS badala ya root.

Kuweka nenosiri la root kunakupa jambo moja mahususi: njia ya kuingia kupitia console ya mtoa huduma. Console hiyo huunganishwa na mashine pepe chini ya safu ya mtandao. Kwa hiyo, huendelea kufanya kazi wakati sshd imesanidiwa vibaya au sheria ya firewall si sahihi. Pia kuna gharama. Menyu ya uokoaji ya GRUB huomba nenosiri la root wakati root ina nenosiri. Hivyo, zana unayotumia kuweka upya nenosiri lililosahaulika sasa inalindwa na nenosiri hilo hilo.

Kuweka nenosiri la root hakumruhusu root kuingia kupitia SSH. Ubuntu husambaza PermitRootLogin prohibit-password, linalomaanisha kuwa funguo pekee ndizo zinazoruhusiwa. Kagua kile ambacho server yako hutumia:

sudo sshd -T | grep -i permitrootlogin

sshd -T huchapisha usanidi unaotumika baada ya kila mstari wa Include kutatuliwa. Kwa hiyo, hilo ndilo jibu sahihi pekee wakati /etc/ssh/sshd_config.d/ lina faili za drop-in.

Weka nenosiri kutoka kwenye hati ya script kwa kutumia chpasswd

passwd husoma kutoka kwenye terminal na haiwezi kuendeshwa kutoka kwenye script. chpasswd husoma jozi za user:password kutoka kwenye ingizo la kawaida, jozi moja kwa kila mstari.

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

Hii inafanya kazi, lakini huweka nenosiri la maandishi wazi kwenye historia ya shell yako na kwenye kumbukumbu za CI (continuous integration). Lihash kwanza badala yake:

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

openssl passwd -6 huomba nenosiri mara mbili bila kulionyesha, kisha huchapisha hash ya SHA-512 crypt inayoanza na $6$. -e huiambia chpasswd kwamba sehemu ya pili tayari imekuwa hashed, kwa hiyo inanakiliwa kwenye /etc/shadow kama ilivyo. Hash hiyo ni salama kuhifadhiwa kwenye repository au kwenye variable ya CI, na nenosiri la maandishi wazi haliondoki kwenye mashine uliyoliandikia.

Ubuntu 24.04 huhash nenosiri jipya kwa kutumia yescrypt ($y$) wakati passwd inapoyaweka, huku openssl passwd -6 ikikupa SHA-512. Zote mbili huthibitishwa wakati wa kuingia, kwa sababu libxcrypt husoma miundo yote miwili. Kuzichanganya ni sawa, na openssl passwd -6 hufanya kazi kwa njia ileile katika kila toleo la Ubuntu LTS, tofauti na chpasswd -c YESCRYPT: kifurushi cha zamani cha shadow kwenye 20.04 hakijui jina hilo la mbinu.

Unaangaliaje kama nenosiri lilibadilika kweli?

Anza kwa metadata, kisha thibitisha kwa kuingia.

sudo passwd -S deploy

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

Sehemu ya pili ni hali: P kwa nenosiri linaloweza kutumika, L kwa lililofungwa, na NP kwa kutokuwa na nenosiri kabisa. Tarehe inaonyesha wakati nenosiri lilibadilishwa mara ya mwisho, kwa hiyo inapaswa kuwa ya leo. Nambari zinazofuata ni sehemu za muda wa uhalali zilizoelezwa hapa chini.

Jaribio salama zaidi la moja kwa moja ni sudo yenyewe. sudo -k huondoa muhuri wa muda uliohifadhiwa, na sudo -v hulazimisha kidokezo kipya. Ikiwa nenosiri jipya linakubaliwa hapo, PAM imelipokea, na hakuna chochote kuhusu kikao chako kilichobadilika.

sudo -k && sudo -v

Ili kujaribu akaunti nyingine, endesha su - deploy kutoka kwenye shell isiyo na mamlaka ya ziada. Usiendeshe sudo su - deploy, kwa sababu root haulizwi nenosiri kamwe na jaribio hilo halithibitishi chochote. Nenosiri lisilo sahihi huchapisha su: Authentication failure.

Jaribio halisi ni kuingia upya kupitia SSH kutoka kwenye kompyuta yako ya mkononi, huku kikao kinachofanya kazi kikiwa bado wazi:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). hapa inamaanisha kuwa seva haikutoa uthibitishaji wa nenosiri kamwe, kwa hiyo hakuna mabadiliko ya nenosiri yatakayokuwezesha kuingia. Permission denied, please try again. inamaanisha kuwa iliutoa na ikakataa ulichoandika.

Lazimisha kubadilisha nenosiri wakati wa kuingia kunakofuata kwa kutumia chage

sudo chage -d 0 deploy

-d 0 huweka tarehe ya mabadiliko ya mwisho kuwa epoch, hivyo PAM huchukulia nenosiri kuwa limekwisha muda wake. Kuingia kunakofuata kwa njia shirikishi huomba nenosiri la sasa, kisha nenosiri jipya, kabla ya kutoa shell. sudo passwd -e deploy hufanya jambo hilo hilo.

Itumie tu kwa akaunti zinazoingia kwa njia shirikishi kwa kutumia nenosiri. Nenosiri lililokwisha muda wake huathiri pia kuingia kwa kutumia key, kwa sababu sshd huendesha hatua ya akaunti ya PAM hata kama key ndiyo iliyothibitisha mtumiaji. ssh deploy@203.0.113.10 'systemctl restart app' iliyoandikwa kwenye script hushindwa kwa kosa hili na kusimama:

Password change required but no TTY available.

Hakuna kinachoendeshwa baada ya mstari huo, na kazi huripoti tu exit code isiyo sifuri.

Sehemu za muda wa uhalali wa nenosiri zinamaanisha nini

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

Nambari hizo ni sehemu ya 4 hadi 8 za mstari wa mtumiaji huyo katika /etc/shadow. Siku za chini (chage -m) ni muda ambao mtumiaji lazima asubiri kabla ya kubadilisha nenosiri tena. Hii huzuia mtu kurudi moja kwa moja kwenye nenosiri la zamani baada ya kulazimishwa kulibadilisha. Siku za juu (chage -M) ni muda ambao nenosiri hubaki halali. Siku za onyo (chage -W) huonyesha wakati kuingia kunapoanza kuchapisha onyo. Siku za kutotumika (chage -I) ni kipindi cha nyongeza baada ya nenosiri kuisha muda wake, kabla halijakoma kabisa kukubaliwa. Muda wa kuisha kwa akaunti (chage -E) ni tarehe ya mwisho isiyobadilika, na hautegemei nenosiri.

sudo chage -M 90 -W 14 deploy

Weka thamani hiyo tu pale sera inapohitaji. NIST (Taasisi ya Kitaifa ya Viwango na Teknolojia ya Marekani) imekuwa ikishauri tangu 2017 dhidi ya kuisha kwa nenosiri mara kwa mara, kwa sababu hatua hiyo huwasukuma watu kutumia mabadiliko yanayotabirika ya nenosiri moja. Pia inapendekeza kulazimisha mabadiliko pale tu kunapokuwa na ushahidi wa uvunjaji wa usalama. Nenosiri refu na la kipekee lililohifadhiwa katika kidhibiti cha manenosiri, pamoja na SSH inayotumia funguo, ni bora kuliko mzunguko wa siku 90.

Cha kufanya unapopoteza nenosiri la root

Ikiwa akaunti yoyote kwenye seva inaweza kuendesha sudo, hakuna kitu cha kurejesha: sudo passwd root huweka jipya. Hali ngumu ni kutokuwa na kuingia kunakofanya kazi kabisa.

Kila kitu hapa chini kinahitaji konsoli ya mtoa huduma, ambayo kwenye paneli nyingi huorodheshwa kama VNC (virtual network computing) au konsoli ya serial. Huunganishwa moja kwa moja na mashine pepe chini ya stack ya mtandao, kwa hiyo mipangilio ya sshd na kanuni za firewall haziathiri.

1. Washa upya seva kutoka kwenye paneli na ufuatilie konsoli.
2. Fungua menyu ya GRUB. Picha za cloud kwa kawaida huweka GRUB_TIMEOUT=0, kwa hiyo shikilia Shift wakati wa kuwasha kupitia BIOS, au bonyeza Esc mara kwa mara wakati wa kuwasha kupitia UEFI, mara tu kuwasha upya kunapoanza.
3. Chagua Advanced options for Ubuntu, kisha ingizo linaloishia kwa (recovery mode), halafu root katika menyu ya urejeshaji.
4. Endesha mount -o remount,rw / kwanza. Urejeshaji huweka mfumo wa faili wa root katika hali ya kusoma pekee, kwa hiyo bila amri hii passwd hushindwa kwa passwd: Authentication token manipulation error kwa sababu haiwezi kuandika /etc/shadow.
5. Endesha passwd ubuntu kwa akaunti unayohitaji, kisha washa upya kutoka kwenye paneli.

Ikiwa root tayari ina nenosiri na hilo ndilo ulilopoteza, shell hiyo ya urejeshaji italiomba na njia hiyo itafungwa. Washa badala yake picha ya uokoaji ya mtoa huduma, kisha weka diski halisi na ubadilishe nenosiri ndani yake.

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

Soma mpangilio wa partitions kutoka lsblk badala ya kunakili /dev/vda1 kutoka kwenye ukurasa huu. Partition ya root ndiyo kubwa. Kwenye picha ya UEFI, iko kando ya partition ndogo ya EFI ambayo haina kabisa saraka ya /etc.

Unachofanya SSH inapoacha kukubali nenosiri lako

Fanya kazi kutoka kwenye kipindi ambacho bado unacho. Ikiwa hakuna kipindi kilichosalia, tumia kiweko.

Permission denied, please try again. inamaanisha kuwa seva ilitoa uthibitishaji wa nenosiri na ikakataa ulichotuma. Sababu za kawaida ni caps lock au mpangilio wa kibodi wa kiweko kutofautiana na uliotumia ulipoweka nenosiri.

Permission denied (publickey). inamaanisha kuwa seva haikutoa kamwe uthibitishaji wa nenosiri. PasswordAuthentication no imewekwa mahali fulani, na katika Ubuntu 22.04 na matoleo ya baadaye kwa kawaida hupatikana katika faili ya drop-in chini ya /etc/ssh/sshd_config.d/ inayobatilisha faili kuu. Soma thamani zinazotumika:

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

KbdInteractiveAuthentication yes pamoja na PasswordAuthentication no bado huruhusu nenosiri kupita, kwa sababu mbinu ya keyboard-interactive hutumia PAM stack hiyo hiyo. Kuzima moja na kuacha nyingine ikiwa imewashwa husababisha seva inayoonekana kukubali funguo pekee iendelee kukubali nenosiri lililoandikwa.

Too many authentication failures katika ujumbe wa kukata muunganisho inamaanisha kuwa mteja wako ulitoa funguo kadhaa kabla ya kufikia nenosiri, na seva ikafikia MaxAuthTries, ambayo kwa chaguo-msingi ni 6. Lazimisha kutumia mbinu moja:

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

Connection refused kwenye port iliyofanya kazi dakika moja iliyopita kwa kawaida inamaanisha kuwa fail2ban inayofuatilia SSH ilipiga marufuku anwani yako baada ya kushindwa mara kadhaa. Kanuni yake ya kawaida ya marufuku hukataa packet badala ya kuiacha ipite bila kujibiwa, ndiyo maana ukataliwaji hurudi haraka badala ya muunganisho kuisha kwa timeout. Kutoka kwenye kiweko, sudo fail2ban-client status sshd huorodhesha anwani zilizopigwa marufuku na sudo fail2ban-client set sshd unbanip 203.0.113.10 huondoa yako.

Nenosiri ni hatua ya mpito, funguo ndilo lengo la mwisho

Nenosiri linalofanya kazi kupitia SSH ni nenosiri ambalo kila kichanganuzi kwenye intaneti kinaweza kujaribu kukisia. Tumia uthibitishaji unaotegemea funguo ili makisio hayo yasiwe na umuhimu. Tengeneza jozi ya funguo, sakinisha sehemu ya umma, kisha thibitisha kuwa ufunguo unakufanya uingie kutoka kwenye terminali ya pili kabla ya kubadilisha jambo lingine lolote. Misingi ya usimamizi wa funguo za SSH inaeleza utengenezaji, authorized_keys na kaulisiri.

Kisha zima uthibitishaji wa nenosiri, na uthibitishe hilo kwa sudo sshd -T badala ya kuamini faili uliyohariri. Kuimarisha usalama wa SSH kwenye VPS inaeleza mipangilio mingine ya sshd inayofaa kubadilishwa, na Dakika kumi za kwanza kwenye VPS mpya inaipanga kwa mpangilio wa kuitekeleza kwenye seva mpya.

Baada ya hapo, hifadhi nenosiri moja. Seva inayotumia funguo pekee na yenye usanidi wa sshd ulioharibika inaweza kufikiwa kupitia kiweko cha mtoa huduma pekee, na kiweko hicho huomba jina la mtumiaji na nenosiri. Akaunti yenye nenosiri thabiti ulilohifadhi ndiyo hutofautisha urekebishaji wa dakika tano na usakinishaji upya.

FAQ

Nabadilishaje nenosiri la root kwenye VPS yangu ikiwa sijui la zamani?

Ingia kama mtumiaji anayeweza kuendesha sudo, kisha uendeshe sudo passwd root. Inaweka nenosiri jipya bila kuuliza la zamani, kwa sababu sudo tayari imekuthibitisha. Ikiwa hakuna akaunti kwenye mfumo inayoweza kuendesha sudo, fungua dashibodi ya mtoa huduma, washa upya mfumo kwenye menyu ya urejeshaji ya GRUB, chagua ingizo la ganda la root, endesha mount -o remount,rw /, kisha uendeshe passwd. Ikiwa root tayari ina nenosiri na hilo ndilo ulilopoteza, ganda la urejeshaji litakuuliza nenosiri hilo. Katika hali hiyo, tumia image ya uokoaji ya mtoa huduma, huku diski ikiwa imewekwa na mfumo wa faili ukiwa umewekwa kwa chroot.

Kwa nini passwd inaonyesha "Authentication token manipulation error"?

Sababu mbili husababisha ujumbe huo. Sababu ya kawaida ni jibu lisilo sahihi kwenye kidokezo cha Current password:, na mstari wa passwd: password unchanged chini yake unathibitisha kuwa hakuna kilichoandikwa. Sababu nyingine ni mfumo wa faili ambao hauwezi kuandikwa. Hilo hutokea katika hali ya urejeshaji kwa sababu / imewekwa kwa hali ya kusoma pekee. Endesha mount -o remount,rw /, kisha ujaribu tena.

Je, kubadilisha nenosiri langu la Linux hubadilisha pia nenosiri langu la sudo?

Ndiyo. sudo haina nenosiri lake yenyewe. Hukuthibitisha kupitia PAM kwa kutumia ingizo lilelile la /etc/shadow linalotumiwa na SSH na su, kwa hiyo kila akaunti ina nenosiri moja. Ndiyo sababu kidokezo cha kwanza cha sudo baada ya mabadiliko ndicho kipimo halisi. Endesha sudo -k && sudo -v ili kulazimisha kidokezo hicho wakati bado una kipindi kinachofanya kazi.

Je, kubadilisha nenosiri langu kutaharibu funguo zangu za SSH au vipindi vyangu vilivyo wazi?

Hapana. Uthibitishaji kwa ufunguo wa umma hausomi /etc/shadow, kwa hiyo funguo zitaendelea kufanya kazi baada ya kubadilisha nenosiri, baada ya passwd -l, na baada ya chage -d 0. Vipindi ambavyo tayari vimefunguliwa vitaendelea kuwa wazi kwa sababu SSH hukagua vitambulisho wakati wa kuingia pekee. Kitu kimoja kinachobadilika ndani ya kipindi kinachoendelea ni sudo, ambacho huomba nenosiri jipya mara moja muda wake wa dakika 15 unapoisha.

Namlazimishaje mtumiaji abadilishe nenosiri lake wakati wa kuingia kunakofuata?

Endesha sudo chage -d 0 deploy, au sudo passwd -e deploy, ambayo hufanya jambo hilohilo. Tarehe iliyohifadhiwa ya mabadiliko ya mwisho huhamishwa hadi epoch, PAM huchukulia nenosiri kuwa limekwisha muda wake, na kuingia kunakofuata kwa njia shirikishi lazima kuweka nenosiri jipya kabla ganda halijaanza. Usifanye hivi kwa akaunti inayotumiwa na hati kupitia SSH: amri isiyo shirikishi itashindwa kwa Password change required but no TTY available. na haitatekelezwa.