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. Amri hii huomba nenosiri jipya mara mbili na haiombi 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 wa nenosiri kwa makusudi, na kurudi kwenye mfumo wakati nenosiri limeshapotea.

Fungua session ya pili kabla ya kubadili password

Fungua session ya pili ya SSH sasa na uiache ikiwa imeunganishwa. Karibu kila hitilafu katika mwongozo huu inaweza kurekebishwa kwa dakika mbili ikiwa shell moja iliyothibitishwa bado inafanya kazi, badala ya kulazimika kutumia console baada ya session ya mwisho kufungwa.

Shell iliyo wazi itaendelea kufanya kazi hata baada ya kubadili, kufunga, au kumaliza muda wa akaunti husika, kwa sababu SSH hukagua vitambulisho wakati wa kuingia (login) na havikagui tena. Isipokuwa ni sudo. Hukagua tena password yako kupitia PAM (pluggable authentication modules) pindi muda wake wa timestamp unapoisha, ambao ni dakika 15 baada ya prompt ya mwisho kwa kawaida. Kwa hivyo, password mpya hujaribiwa kikamilifu wakati ujao ambapo sudo itaiomba, si wakati wa kuingia.

Jaribu password mpya katika session ya pili wakati ile ya kwanza ikiwa bado imefunguka.

Badilisha nenosiri lako mwenyewe ukitumia passwd

passwd

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

passwd: password updated successfully ndio 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 unaoshikilia /etc/shadow hauwezi kuandikwa, hali ambayo ni ya kawaida katika recovery mode. You must choose a longer password. hutokana na pam_unix katika /etc/pam.d/common-password, ambayo hutumia ukaguzi wa urefu na ufanano kwa watumiaji wa kawaida.

Katika picha nyingi za VPS, akaunti ya msingi (ubuntu, au jina lolote ambalo mtoa huduma wako ametoa) haina nenosiri kabisa, ina SSH key pekee. passwd haina nenosiri la sasa la kulinganisha nalo, kwa 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 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 ya 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 kuilingana. sudo passwd -u deploy huiondoa alama hiyo. Soma hali ya akaunti 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 kuzuia akaunti kikamilifu, ifungie akaunti yenyewe:

sudo usermod --expiredate 1 deploy

Hiyo huweka muda wa kuisha kwa akaunti kwenye tarehe ya mwaka 1970, hivyo sshd itakataa kuingia kwa mtumiaji bila kujali kitambulisho kinachotolewa. Batilisha kitendo hiki kwa kutumia sudo usermod --expiredate '' deploy.

Epuka passwd -d. Hii 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 bora ya kuzingatia.

Kuweka nenosiri la root kunakupa kitu kimoja mahususi: njia ya kuingia kupitia console ya mtoa huduma. Console hiyo huunganishwa 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 pekee. Hakikisha seva yako inatumia nini hasa:

sudo sshd -T | grep -i permitrootlogin

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

Kuweka nenosiri kutoka kwenye hati kwa kutumia chpasswd

passwd husoma kutoka kwenye terminal na haiwezi kuendeshwa kutoka kwenye hati. 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, na inaweka nenosiri la maandishi wazi (plaintext) kwenye historia ya shell yako na kwenye logi za CI (continuous integration). Badala yake, liweke kwenye 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 hash ya SHA-512 crypt inayoanza na $6$. -e huambia chpasswd kwamba sehemu ya pili tayari imewekwa kwenye hash, kwa hivyo inanakiliwa kwenye /etc/shadow kama ilivyo. Hash hiyo ni salama kuhifadhiwa kwenye hazina (repository) au kigezo cha CI, na maandishi wazi hayajawahi kutoka kwenye mashine uliyoyachapa.

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

Jinsi ya kuhakikisha nenosiri limebadilika kweli?

Anza kwa kuangalia metadata, kisha thibitisha kwa kujaribu kuingia (login).

sudo passwd -S deploy

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

Uga wa pili unaonyesha hali: P kwa nenosiri linaloweza kutumika, L kwa lililofungwa, NP kwa nenosiri lisilokuwepo kabisa. Tarehe hiyo inaonyesha wakati nenosiri lilipobadilishwa mara ya mwisho, hivyo inapaswa kuonyesha ya leo. Namba zinazofuata ni uga wa 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 kwenye session yako.

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 haombwi nenosiri kamwe na jaribio hilo halithibitishi chochote. Nenosiri lisilo sahihi huchapisha su: Authentication failure.

Jaribio la kweli ni kuingia kupitia SSH 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 yatakayokuwezesha kuingia. Permission denied, please try again. inamaanisha 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 ya kwanza ya maingiliano (interactive) itauliza nenosiri la sasa, kisha nenosiri jipya, kabla ya kutoa shell. sudo passwd -e deploy hufanya kitu kilekile.

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

Password change required but no TTY available.

Hakuna kitakachoendelea baada ya mstari huo, na kazi hiyo itatoa tu exit code isiyo ya sifuri.

Maana ya sehemu za kuzeeka kwa nenosiri

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 ya mstari wa mtumiaji huyo katika /etc/shadow. Siku za chini (chage -m) ni muda ambao mtumiaji lazima asubiri kabla ya kubadilisha nenosiri tena, jambo linalozuia mtu kurudia nenosiri la zamani mara tu baada ya kulazimishwa kulibadilisha. Siku za juu (chage -M) ni muda ambao nenosiri linabaki kuwa halali. Siku za onyo (chage -W) ni wakati ambapo kuingia kwenye mfumo huanza kuonyesha onyo. Siku za kutokuwa na shughuli (chage -I) ni muda wa ziada baada ya nenosiri kuisha muda wake kabla ya kukataliwa kabisa. Kuisha kwa muda wa akaunti (chage -E) ni tarehe maalum ya mwisho, na hii haitegemei nenosiri.

sudo chage -M 90 -W 14 deploy

Weka mipangilio hiyo tu wakati sera inahitaji hivyo. NIST (Taasisi ya Kitaifa ya Viwango na Teknolojia ya Marekani) imeshauri tangu mwaka 2017 dhidi ya utaratibu wa kuisha kwa nenosiri mara kwa mara, kwa sababu inawasukuma watu kutumia mabadiliko yanayotabirika ya nenosiri moja, na inapendekeza kulazimisha mabadiliko pale tu kunapokuwa na ushahidi wa uvunjifu wa usalama. Nenosiri refu na la kipekee linalohifadhiwa katika meneja wa nenosiri, pamoja na SSH inayotumia funguo, 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, iliyoorodheshwa kwenye 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 Cloud (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 kwenye 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 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) kwenye console ambao ni tofauti 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 sasa:

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

KbdInteractiveAuthentication yes pamoja na PasswordAuthentication no bado huruhusu nenosiri kupita, kwa sababu njia ya keyboard-interactive hutumia stack ileile ya PAM. Kuzima moja na kuacha nyingine ndiyo njia ambayo seva inayoonekana kukubali funguo pekee (key-only) huendelea kukubali manenosiri yanayoandikwa.

Too many authentication failures kwenye 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 njia moja pekee:

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

Connection refused kwenye port iliyokuwa ikifanya kazi muda mfupi uliopita kwa kawaida inamaanisha fail2ban inayofuatilia SSH imepiga marufuku anwani yako baada ya majaribio mengi yaliyoshindikana. Kanuni yake ya kawaida ya kupiga marufuku hukataa pakiti badala ya kuipuuza, ndiyo maana kukataliwa huko kunarudi 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 la mwisho

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 uhakikishe 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 wa nenosiri, na uthibitishe hilo kwa sudo sshd -T badala ya kuamini faili uliyohariri. Kuimarisha usalama wa SSH kwenye VPS inashughulikia mipangilio mingine ya sshd inayostahili kubadilishwa, na dakika kumi za kwanza kwenye VPS mpya inaweka mipangilio hiyo katika mpangilio sahihi wa kuifanya kwenye 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 marekebisho ya dakika tano na usakinishaji upya wa 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 imeshakuthibitisha. Ikiwa hakuna akaunti kwenye seva inayoweza kutumia sudo, fungua console 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 wako 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 hapo chini unathibitisha kuwa hakuna kilichoandikwa. Sababu nyingine ni mfumo wa faili (filesystem) ambao hauwezi kuandikika, jambo unalokutana nalo katika hali ya uokoaji (recovery mode), kwa sababu / huwa imewekwa kwa kusoma tu (read-only). Endesha mount -o remount,rw / kisha jaribu tena.

Je, kubadilisha nenosiri langu la Linux kunabadilisha pia nenosiri langu 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. Hii 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 kutaharibu funguo zangu za SSH au session zangu zilizo wazi?

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

Ninawezaje kumlazimisha mtumiaji abadilishe nenosiri lake wakati wa login ijayo?

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 huchukulia nenosiri kama limekwisha muda wake, na login ya maingiliano (interactive login) inayofuata lazima iweke jipya kabla ya shell kuanza. Usifanye hivi kwa akaunti inayotumiwa na script kupitia SSH: amri isiyo ya maingiliano (non-interactive command) itafeli na Password change required but no TTY available. na haitaendesha.