Jinsi ya kubadilisha nenosiri la root kwenye Ubuntu

Jinsi ya kubadilisha nenosiri la root la VPS yako kwenye Ubuntu

Ili kubadilisha nenosiri la root la VPS (virtual private server) yako kwenye Ubuntu, fungua kikao cha SSH (secure shell) kama mtumiaji anayeweza kutumia sudo, kisha endesha sudo passwd root. Itakuomba nenosiri jipya mara mbili na haitaomba nenosiri la zamani, kwa sababu sudo imeshathibitisha utambulisho wako. Ili kubadilisha nenosiri lako la kuingia badala yake, endesha passwd bila hoja zozote, na itakuomba nenosiri lako la sasa kwanza.

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

Hiyo ndiyo operesheni nzima. Kila kitu hapa chini ni sehemu inayoweza kwenda vibaya: kuthibitisha kuwa nenosiri jipya linafanya kazi kabla ya kupoteza kikao kinachoweza kurekebisha tatizo, kuweka nenosiri kutoka kwenye script, kulimaliza muda wake kwa makusudi, na kurudi ndani wakati nenosiri limeshapotea.

Fungua kikao cha pili kabla ya kubadili nenosiri

Fungua kikao cha pili cha SSH sasa na ukiache kikiwa kimeunganishwa. Karibu kila hitilafu katika mwongozo huu inaweza kurekebishwa ndani ya dakika mbili ukiwa na shell moja iliyothibitishwa, lakini itahitaji ufikiaji wa console pindi kikao cha mwisho kitakapofungwa.

Shell iliyo wazi inaendelea kufanya kazi hata baada ya kubadili, kufunga, au kumaliza muda wa akaunti inayomiliki, kwa sababu SSH hukagua vitambulisho wakati wa kuingia (login) na havikagui tena. Isipokuwa ni sudo. Hukagua tena nenosiri lako kupitia PAM (pluggable authentication modules) pindi muda wake wa timestamp unapoisha, ambao kwa kawaida ni dakika 15 baada ya prompt ya mwisho. Kwa hivyo, nenosiri jipya hujaribiwa kikamilifu wakati wa kwanza ambapo sudo litakuomba, si wakati wa kuingia.

Jaribu nenosiri jipya katika kikao cha pili wakati kikao cha kwanza kikiwa bado wazi.

Badilisha nenosiri lako mwenyewe kwa kutumia passwd

passwd

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

passwd: password updated successfully ndiyo matokeo pekee yanayoashiria kuwa hash iliyo katika /etc/shadow imebadilishwa. Matokeo mengine yoyote yanamaanisha kuwa nenosiri la zamani bado linatumika.

Kuna aina mbili za hitilafu zinazoweza kutokea hapa. passwd: Authentication token manipulation error, ikifuatiwa na passwd: password unchanged, inamaanisha kuwa nenosiri la sasa ulilochapa si sahihi, au mfumo wa faili (filesystem) unaoshikilia /etc/shadow hauwezi kuandikika, hali ambayo ni ya kawaida ukiwa katika recovery mode. You must choose a longer password. hutokana na pam_unix ndani ya /etc/pam.d/common-password, ambayo hutumia ukaguzi wa urefu na ufanano kwa watumiaji wa kawaida.

Katika picha (images) nyingi za VPS, akaunti ya msingi (ubuntu, au jina lolote ambalo mtoa huduma wako ametoa) haina nenosiri kabisa, bali hutumia SSH key pekee. passwd haina nenosiri la sasa la kulinganisha nalo, hivyo haiwezi kupita hatua ya kwanza ya maombi. Tumia sudo passwd $USER badala yake, ambayo hufanya kazi kwa sababu faili ya sudoers ya picha hiyo inaruhusu akaunti hiyo kuendesha sudo bila kuhitaji nenosiri.

Badilisha nenosiri la mtumiaji mwingine kwa kutumia sudo passwd

sudo passwd deploy

Root haulizwi nenosiri la zamani, na pam_unix huruka ukaguzi wa nguvu wa nenosiri unaotumika kwa watumiaji wa kawaida, hivyo root anaweza kuweka nenosiri ambalo mtumiaji asingeweza kujiwekea mwenyewe.

Kufunga (locking) ni kitendo tofauti. sudo passwd -l deploy huweka ! mbele ya hash iliyohifadhiwa, hivyo hakuna nenosiri linaloweza kuendana nayo. sudo passwd -u deploy huiondoa alama hiyo. Soma hali ya sasa kwa kutumia sudo passwd -S deploy.

Kufunga nenosiri hakumzuii mtumiaji huyo kuingia kwenye mfumo. Ufunguo wowote uliopo kwenye ~/.ssh/authorized_keys yake utaendelea kufanya kazi, kwa sababu uthibitishaji wa public key hauisomi /etc/shadow. Ili kusimamisha akaunti kikamilifu, ifungie akaunti yenyewe:

sudo usermod --expiredate 1 deploy

Hiyo huweka muda wa mwisho wa akaunti kuwa tarehe ya mwaka 1970, hivyo sshd hukataa kuingia bila kujali kitambulisho kinachotolewa. Tendua kitendo hiki kwa sudo usermod --expiredate '' deploy.

Epuka passwd -d. Hiyo huweka nenosiri tupu badala ya nenosiri lililofungwa, na kwenye toleo la zamani ambalo bado lina nullok katika PAM stack, nenosiri tupu ni kitu ambacho mtu yeyote anaweza kukitumia.

Je, root inahitaji nenosiri kwenye VPS?

Ubuntu inakuja ikiwa imefunga akaunti ya root. /etc/shadow inashikilia ! badala ya hash, na sudo passwd -S root inachapisha mstari unaoanza na root L. Hakuna kinachoweza kuingia kama root kwa kutumia nenosiri hadi utakapoliweka, ndiyo maana image inakupa mtumiaji mwenye uwezo wa sudo badala yake. Kufanya kazi kupitia akaunti za watumiaji wenye upendeleo mdogo kwenye VPS badala ya kufanya kazi kama root ndiyo mbinu ya kuzingatia.

Kuweka nenosiri la root kunakupa kitu kimoja mahususi: njia ya kuingia kupitia console ya mtoa huduma. Console hiyo inaunganishwa kwenye mashine pepe (virtual machine) chini ya mtandao, kwa hivyo inaendelea kufanya kazi wakati sshd imesanidiwa vibaya au sheria ya firewall si sahihi. Pia ina gharama zake. Shell ya root katika menyu ya uokoaji ya GRUB huomba nenosiri la root wakati root inalo, kwa hivyo zana ambayo ungetumia kuweka upya nenosiri lililosahaulika sasa inalindwa na nenosiri hilo hilo.

Kuweka nenosiri la root hakuruhusu root kuingia kupitia SSH. Ubuntu inakuja na PermitRootLogin prohibit-password, ambayo inamaanisha funguo (keys) pekee. Angalia kile ambacho seva yako inatumia kihalisi:

sudo sshd -T | grep -i permitrootlogin

sshd -T inachapisha usanidi halisi baada ya kila mstari wa Include kutatuliwa, kwa hivyo ndiyo jibu la kweli pekee pindi /etc/ssh/sshd_config.d/ inaposhikilia faili za ziada (drop-in files).

Kuweka nenosiri kutoka kwenye script kwa kutumia chpasswd

passwd husoma kutoka kwenye terminal na haiwezi kuendeshwa kupitia script. chpasswd husoma jozi za user:password kwenye standard input, moja kwa kila mstari.

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

Hiyo inafanya kazi, lakini inaweka nenosiri la maandishi wazi (plaintext) kwenye historia ya shell yako na kwenye logi za CI (continuous integration). Badala yake, liweke kwenye mfumo wa hash kwanza:

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

openssl passwd -6 huomba nenosiri mara mbili bila kulionyesha kwenye skrini, kisha huchapisha SHA-512 crypt hash inayoanza na $6$. -e huambia chpasswd kwamba sehemu ya pili tayari imeshafanyiwa hashing, hivyo inanakiliwa kwenye /etc/shadow kama ilivyo. Hash hiyo ni salama kuhifadhiwa kwenye repository au variable ya CI, na nenosiri la maandishi wazi halitoki kamwe kwenye mashine uliyolichapa.

Ubuntu 24.04 hufanya hashing ya manenosiri mapya kwa kutumia yescrypt ($y$) wakati passwd inapoyaweka, wakati openssl passwd -6 inakupa SHA-512. Zote mbili huthibitishwa wakati wa kuingia (login), kwa sababu libxcrypt inasoma miundo yote miwili. Kuchanganya njia hizi ni sawa, na openssl passwd -6 hufanya kazi kwa namna ileile kwenye kila toleo la Ubuntu LTS, jambo ambalo chpasswd -c YESCRYPT halifanyi: kifurushi cha zamani cha shadow kwenye 20.04 hakijui jina hilo la njia. Hash hizo hudumu hata wakati wa kuboresha toleo la mfumo, kwa hivyo kuhamisha seva ya 24.04 kwenda 26.04 hakukulazimishi kuweka upya nenosiri la mtu yeyote.

Je, unathibitishaje kuwa nenosiri limebadilika kweli?

Anza kwa kuangalia metadata, kisha uthibitishe kwa kufanya login.

sudo passwd -S deploy

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

Sehemu ya pili ni hali ya nenosiri: P kwa nenosiri linaloweza kutumika, L kwa lililofungwa, NP kwa nenosiri lisilokuwepo kabisa. Tarehe hiyo inaonyesha wakati nenosiri lilipobadilishwa mara ya mwisho, kwa hivyo inapaswa kuonyesha tarehe ya leo. Namba zinazofuata ni sehemu za muda wa matumizi (aging fields) zilizofafanuliwa hapa chini.

Jaribio salama zaidi la moja kwa moja ni sudo yenyewe. sudo -k hufuta timestamp iliyohifadhiwa kwenye cache na sudo -v hulazimisha ombi jipya la nenosiri. Ikiwa nenosiri jipya litakubaliwa hapo, basi PAM imelikubali, na hakuna kilichobadilika kuhusu session yako ya sasa.

sudo -k && sudo -v

Ili kujaribu akaunti nyingine, endesha su - deploy kutoka kwenye shell isiyo na upendeleo (unprivileged shell). Usiendeshe sudo su - deploy, kwa sababu root hajawahi kuombwa nenosiri na jaribio hilo halithibitishi chochote. Nenosiri lisilo sahihi huchapisha su: Authentication failure.

Jaribio la kweli ni kufanya SSH login mpya kutoka kwenye laptop yako, huku session inayofanya kazi ikiwa bado imefunguka:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). hapa inamaanisha seva haijawahi kutoa chaguo la uthibitishaji kwa nenosiri, kwa hivyo hakuna mabadiliko ya nenosiri yatakayokuruhusu kuingia. Permission denied, please try again. inamaanisha kuwa seva ilitoa chaguo hilo lakini ikakataa ulichokiandika.

Lazimisha mtumiaji kubadili nenosiri wakati wa login inayofuata kwa kutumia chage

sudo chage -d 0 deploy

-d 0 huweka tarehe ya mabadiliko ya mwisho kuwa epoch, hivyo PAM huchukulia nenosiri kama limekwisha muda wake. Login inayofuata ya kiingiliano huomba nenosiri la sasa, kisha huomba nenosiri jipya, kabla ya kutoa shell. sudo passwd -e deploy hufanya kitu kilekile.

Itumie tu kwa akaunti zinazoingia kwa njia ya kiingiliano kwa kutumia nenosiri. Nenosiri lililokwisha muda wake huathiri pia login zinazotumia funguo (key-based logins), kwa sababu sshd huendesha hatua ya akaunti ya PAM hata wakati ufunguo ndio umethibitisha utambulisho. Hivyo, ssh deploy@203.0.113.10 'systemctl restart app' inayotumia script itafeli na kusimama:

Password change required but no TTY available.

Hakuna chochote kinachoendelea baada ya mstari huo, na kazi hiyo huripoti tu exit code isiyo ya sifuri.

Maana ya sehemu za 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

Namba hizo ni sehemu ya 4 hadi 8 ya mstari wa mtumiaji huyo katika /etc/shadow. Siku za chini (chage -m) ni muda ambao mtumiaji lazima asubiri kabla ya kubadili tena, jambo linalozuia mtu kurudi moja kwa moja kwenye password ya zamani baada ya kulazimishwa kuibadili. Siku za juu (chage -M) ni muda ambao password inabaki kuwa halali. Siku za onyo (chage -W) ni wakati ambapo kuingia kwenye mfumo (logins) huanza kuonyesha onyo. Siku za kutokuwa hai (chage -I) ni muda wa ziada baada ya muda wa password kuisha kabla ya kukataliwa kabisa. Muda wa mwisho wa akaunti (chage -E) ni tarehe rasmi ya kufungwa, na hii haitegemei password.

sudo chage -M 90 -W 14 deploy

Weka mipangilio hiyo tu pale sera inapohitaji. NIST (Taasisi ya Kitaifa ya Viwango na Teknolojia ya Marekani) imeshauri tangu mwaka 2017 dhidi ya utaratibu wa kumaliza muda wa password mara kwa mara, kwa sababu inawasukuma watu kutumia mabadiliko yanayotabirika ya password moja, na inapendekeza kulazimisha mabadiliko pale tu kunapokuwa na ushahidi wa uvunjifu wa usalama. Password ndefu na ya kipekee inayohifadhiwa kwenye password manager, pamoja na SSH inayotumia key, ni bora kuliko mzunguko wa siku 90.

Nini cha kufanya unapopoteza nenosiri la root

Ikiwa akaunti yoyote kwenye seva inaweza kutumia sudo, hakuna cha kurejesha: sudo passwd root huweka nenosiri jipya. Hali ngumu ni pale ambapo hakuna login inayofanya kazi kabisa.

Kila kitu hapa chini kinahitaji console ya mtoa huduma, inayoorodheshwa katika paneli nyingi kama VNC (virtual network computing) au serial console. Hii huunganishwa kwenye mashine pepe (virtual machine) chini ya mtandao, kwa hivyo mipangilio ya sshd na sheria za firewall haziathiri console hii.

1. Anzisha upya (reboot) seva kutoka kwenye paneli na ufuatilie console.
2. Pata menyu ya GRUB. Picha za mfumo wa wingu (cloud images) kwa kawaida huweka GRUB_TIMEOUT=0, kwa hivyo shikilia Shift kwenye BIOS boot, au bonyeza Esc mara kwa mara kwenye UEFI boot, mara tu reboot inapoanza.
3. Chagua Advanced options for Ubuntu, kisha ingizo linaloishia na (recovery mode), kisha root katika menyu ya kurejesha (recovery menu).
4. Tekeleza mount -o remount,rw / kwanza. Hali ya kurejesha huweka mfumo wa faili wa root katika hali ya kusoma pekee (read-only), kwa hivyo bila hatua hii, passwd itafeli na kutoa passwd: Authentication token manipulation error kwa sababu haiwezi kuandika kwenye /etc/shadow.
5. Tekeleza passwd ubuntu kwa akaunti unayohitaji, kisha anzisha upya seva kutoka kwenye paneli.

Ikiwa root tayari ina nenosiri na ndilo ulilopoteza, shell ya kurejesha itakuomba nenosiri hilo na njia hiyo itakuwa imefungwa. Badala yake, anzisha (boot) picha ya uokoaji (rescue image) ya mtoa huduma, kisha weka (mount) diski halisi na ubadilishe nenosiri ukiwa 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 partition kutoka lsblk badala ya kunakili /dev/vda1 kutoka ukurasa huu. Partition ya root ndiyo ile kubwa. Kwenye picha ya UEFI, inakaa kando ya partition ndogo ya EFI ambayo haina saraka ya /etc hata kidogo.

Nini cha kufanya wakati SSH inakataa nenosiri lako

Tumia session uliyo nayo sasa. Ikiwa hakuna session iliyobaki, tumia console.

Permission denied, please try again. inamaanisha seva ilitoa fursa ya uthibitishaji kwa nenosiri lakini ikakataa ulichotuma. Sababu za kawaida ni caps lock, au mpangilio wa kibodi (keyboard layout) wa console unaotofautiana na ule uliotumia wakati wa kuweka nenosiri hilo.

Permission denied (publickey). inamaanisha seva haikutoa fursa ya uthibitishaji kwa nenosiri hata kidogo. PasswordAuthentication no imewekwa mahali fulani, na kwenye Ubuntu 22.04 na matoleo mapya zaidi, kwa kawaida hupatikana kwenye faili ya ziada ndani ya /etc/ssh/sshd_config.d/ ambayo inabatilisha 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 ileile. Kuzima moja na kuacha nyingine ikiwa imewashwa ndiyo njia ambayo seva inayoonekana kukubali funguo pekee (key-only) huendelea kukubali nenosiri lililoandikwa.

Mstari huo huo ndio unaoonekana pia wakati ufunguo (key) unapokataliwa, kwa hivyo ikiwa ulikuwa unatoa ufunguo badala ya nenosiri, mpangilio wa nenosiri wa seva ni moja tu ya makosa matano yanayosababisha Permission denied (publickey), na matokeo ya ssh -v yatakueleza ni kosa lipi unalo.

Too many authentication failures katika ujumbe wa kukatwa kwa muunganisho inamaanisha mteja wako alijaribu funguo kadhaa kabla ya kufikia nenosiri, na seva ilifikia MaxAuthTries, ambayo ni 6 kwa chaguo-msingi. Lazimisha mbinu moja pekee:

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

Connection refused kwenye port iliyokuwa ikifanya kazi dakika moja iliyopita kwa kawaida inamaanisha fail2ban inayofuatilia SSH imepiga marufuku anwani yako baada ya majaribio mengi yaliyoshindwa. Kanuni yake ya kawaida ya kupiga marufuku hukataa pakiti badala ya kuipuuza, ndiyo maana kukataliwa huko hurudi haraka badala ya kusubiri muda uishe (timeout). Kutoka kwenye console, sudo fail2ban-client status sshd huorodhesha anwani zilizopigwa marufuku na sudo fail2ban-client set sshd unbanip 203.0.113.10 huondoa marufuku ya anwani yako.

Nenosiri ni hatua ya awali, funguo ndio lengo kuu

Nenosiri linalofanya kazi kupitia SSH ni nenosiri ambalo kila skana kwenye Internet inaweza kulikisia. Hamia kwenye uthibitishaji kwa kutumia funguo (key-based authentication) na kukisia huko hakutakuwa na maana tena. Tengeneza jozi ya funguo, sakinisha nusu ya umma (public key), na uthibitishe kuwa ufunguo huo unakuingiza kwenye mfumo kutoka kwenye terminal ya pili kabla ya kubadilisha kitu kingine chochote. Misingi ya usimamizi wa funguo za SSH inashughulikia utengenezaji, authorized_keys na misemo ya siri (passphrases).

Kisha zima uthibitishaji kwa nenosiri, na uthibitishe hilo kwa kutumia sudo sshd -T badala ya kuamini faili uliyohariri. Kuimarisha usalama wa SSH kwenye VPS hupitia mipangilio mingine ya sshd inayofaa kubadilishwa, na dakika kumi za kwanza kwenye VPS mpya hupanga hatua hizo kwa ajili ya seva mpya.

Hifadhi nenosiri moja baada ya hapo. Seva inayotumia funguo pekee ikiwa na usanidi mbovu wa sshd inaweza kufikiwa tu kupitia console ya mtoa huduma, na console hiyo huomba jina la mtumiaji na nenosiri. Akaunti yenye nenosiri imara ulilohifadhi ndilo linalotofautisha kati ya marekebisho ya dakika tano na kusakinisha upya mfumo.

FAQ

Ninawezaje kubadilisha nenosiri la root kwenye VPS yangu ikiwa silijui la zamani?

Ingia kama mtumiaji anayeweza kutumia sudo na uendeshe sudo passwd root. Hii huweka nenosiri jipya bila kuuliza la zamani, kwa sababu sudo tayari imekuthibitisha. Ikiwa hakuna akaunti kwenye seva inayoweza kutumia sudo, fungua konsole ya mtoa huduma wako, anzisha upya seva (reboot) kwenye menyu ya uokoaji ya GRUB, chagua ingizo la shell la root, endesha mount -o remount,rw /, kisha endesha passwd. Ikiwa root tayari ina nenosiri na ndilo ulilopoteza, shell ya uokoaji itakuuliza nenosiri hilo, na njia iliyobaki ni kutumia rescue image ya mtoa huduma huku diski ikiwa imewekwa (mounted) na kuingizwa kwenye chroot.

Kwa nini passwd inasema "Authentication token manipulation error"?

Sababu mbili husababisha ujumbe huo. Ya kawaida ni jibu lisilo sahihi kwenye prompt ya Current password:, na mstari wa passwd: password unchanged chini yake unathibitisha kuwa hakuna kilichoandikwa. Nyingine ni mfumo wa faili (filesystem) ambao hauwezi kuandikwa, jambo ambalo hukutana nalo katika hali ya uokoaji (recovery mode), kwa sababu / huwa imewekwa kwa ajili ya kusoma tu (read-only). Endesha mount -o remount,rw / na ujaribu tena.

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

Ndiyo. sudo haina nenosiri lake lenyewe. Inakuthibitisha kupitia PAM dhidi ya ingizo lilelile la /etc/shadow ambalo SSH na su hutumia, kwa hivyo kuna nenosiri moja kwa kila akaunti. Hiyo ndiyo sababu prompt ya kwanza ya sudo baada ya mabadiliko ndiyo jaribio la kweli. Endesha sudo -k && sudo -v ili kulazimisha prompt hiyo wakati bado una session inayofanya kazi.

Je, kubadilisha nenosiri langu kutavunja funguo zangu za SSH au session zangu zilizo wazi?

Hapana. Uthibitishaji wa public key hauisomi /etc/shadow, kwa hivyo funguo zinaendelea kufanya kazi baada ya kubadilisha nenosiri, baada ya passwd -l, na baada ya chage -d 0. Session ambazo tayari ziko wazi zinabaki wazi, kwa sababu SSH hukagua vitambulisho wakati wa kuingia (login) pekee. Kitu pekee kinachobadilika ndani ya session iliyo hai ni sudo, ambayo itaomba nenosiri jipya mara tu muda wake wa dakika 15 utakapokwisha.

Ninawezaje kumlazimisha mtumiaji abadilishe nenosiri lake wakati ujao atakapoingia?

Endesha sudo chage -d 0 deploy, au sudo passwd -e deploy, ambayo hufanya kitu kilekile. Tarehe ya mwisho ya mabadiliko iliyohifadhiwa huhamishiwa kwenye epoch, PAM inachukulia nenosiri kama limekwisha muda wake, na login inayofuata ya maingiliano (interactive) lazima iweke nenosiri jipya kabla ya shell kuanza. Usifanye hivi kwa akaunti inayotumiwa na hati (scripts) kupitia SSH: amri isiyo ya maingiliano itashindwa na Password change required but no TTY available. na haitaendeshwa kamwe.