เปลี่ยนรหัสผ่าน root ของ VPS บน Ubuntu ด้วย passwd

วิธีเปลี่ยนรหัสผ่าน root ของ VPS บน Ubuntu

หากต้องการเปลี่ยนรหัสผ่าน root ของ VPS (เซิร์ฟเวอร์เสมือนส่วนตัว) บน Ubuntu ให้เปิดเซสชัน SSH (secure shell) ในชื่อผู้ใช้ที่สามารถเรียกใช้ sudo ได้ จากนั้นเรียกใช้ sudo passwd root ระบบจะขอรหัสผ่านใหม่ 2 ครั้ง และจะไม่ขอรหัสผ่านเดิม เพราะ sudo ได้ยืนยันตัวตนของคุณแล้ว หากต้องการเปลี่ยนรหัสผ่านเข้าสู่ระบบของตนเองแทน ให้เรียกใช้ passwd โดยไม่ระบุอาร์กิวเมนต์ ระบบจะขอรหัสผ่านปัจจุบันก่อน

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

ขั้นตอนมีเพียงเท่านี้ ส่วนด้านล่างอธิบายกรณีที่มักเกิดปัญหา ได้แก่ การตรวจสอบว่ารหัสผ่านใหม่ใช้งานได้ก่อนที่คุณจะสูญเสียเซสชันที่ใช้แก้ไขปัญหาได้ การกำหนดรหัสผ่านจากสคริปต์ การทำให้รหัสผ่านหมดอายุโดยตั้งใจ และการกลับเข้าสู่ระบบเมื่อสูญเสียรหัสผ่านไปแล้ว

เปิดเซสชันที่สองก่อนเปลี่ยนรหัสผ่าน

เปิดเซสชัน SSH ที่สองตอนนี้และปล่อยให้เชื่อมต่ออยู่ ความล้มเหลวเกือบทั้งหมดในคู่มือนี้แก้ไขได้ภายใน 2 นาทีขณะที่ยังมี shell ที่ยืนยันตัวตนแล้วใช้งานอยู่ และจะต้องเข้าถึงคอนโซลเมื่อเซสชันสุดท้ายปิดลง

shell ที่เปิดอยู่แล้วจะยังทำงานต่อได้หลังจากคุณเปลี่ยน ล็อก หรือทำให้บัญชีที่ shell นั้นใช้หมดอายุ เนื่องจาก SSH ตรวจสอบข้อมูลรับรองตอนเข้าสู่ระบบและจะไม่ตรวจสอบซ้ำ ข้อยกเว้นคือ sudo ซึ่งจะตรวจสอบรหัสผ่านของคุณอีกครั้งผ่าน PAM (โมดูลการยืนยันตัวตนแบบเสียบได้) เมื่อ timestamp หมดอายุ โดยค่าเริ่มต้นคือ 15 นาทีหลังจากมีการแจ้งถามครั้งล่าสุด ดังนั้น การทดสอบรหัสผ่านใหม่จริงครั้งแรกจะเกิดขึ้นเมื่อ sudo ขอรหัสผ่านนั้น ไม่ใช่ตอนเข้าสู่ระบบ

ทดสอบรหัสผ่านใหม่ในเซสชันที่สอง โดยปล่อยให้เซสชันแรกเปิดอยู่

เปลี่ยนรหัสผ่านของคุณเองด้วย passwd

passwd

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

passwd: password updated successfully เป็นเอาต์พุตเพียงรายการเดียวที่หมายความว่าแฮชใน /etc/shadow ถูกแทนที่แล้ว หากเป็นอย่างอื่น แสดงว่ารหัสผ่านเดิมยังคงใช้งานอยู่

กรณีนี้มีความล้มเหลวเกิดขึ้น 2 รายการ passwd: Authentication token manipulation error ตามด้วย passwd: password unchanged หมายความว่า รหัสผ่านปัจจุบันที่คุณป้อนไม่ถูกต้อง หรือไม่สามารถเขียนลงระบบไฟล์ที่เก็บ /etc/shadow ได้ ซึ่งเป็นสถานะปกติในโหมดกู้คืน You must choose a longer password. มาจาก pam_unix ใน /etc/pam.d/common-password ซึ่งใช้ตรวจสอบความยาวและความคล้ายคลึงสำหรับผู้ใช้ทั่วไป

ในอิมเมจ VPS ส่วนใหญ่ บัญชีเริ่มต้น (ubuntu หรือชื่ออื่นที่ผู้ให้บริการจัดเตรียมไว้) จะไม่มีรหัสผ่าน มีเพียงคีย์ SSH เท่านั้น passwd จึงไม่มีรหัสผ่านปัจจุบันให้ตรวจสอบ และไม่สามารถผ่านพรอมต์แรกได้ ให้ใช้ sudo passwd $USER แทน ซึ่งทำงานได้เนื่องจากไฟล์ drop-in ของ sudoers ของอิมเมจอนุญาตให้บัญชีนั้นเรียกใช้ sudo โดยไม่ต้องใช้รหัสผ่าน

เปลี่ยนรหัสผ่านของผู้ใช้อื่นด้วย sudo passwd

sudo passwd deploy

root จะไม่ถูกถามรหัสผ่านเดิม และ pam_unix จะข้ามการตรวจสอบความปลอดภัยของรหัสผ่านที่ใช้กับผู้ใช้ทั่วไป ดังนั้น root จึงสามารถตั้งรหัสผ่านที่ผู้ใช้นั้นไม่สามารถตั้งได้ด้วยตนเอง

การล็อกเป็นการดำเนินการแยกต่างหาก sudo passwd -l deploy จะใส่ ! ไว้หน้าค่าแฮชที่จัดเก็บ ทำให้ไม่มีรหัสผ่านใดตรงกับค่านั้น sudo passwd -u deploy จะลบอักขระดังกล่าวออก อ่านสถานะกลับมาได้ด้วย sudo passwd -S deploy

การล็อกรหัสผ่านไม่ได้หยุดผู้ใช้นั้นจากการเข้าสู่ระบบ ~/.ssh/authorized_keys ใด ๆ ในไฟล์ดังกล่าวยังคงใช้งานได้ เนื่องจากการตรวจสอบสิทธิ์ด้วยกุญแจสาธารณะไม่เคยอ่าน /etc/shadow หากต้องการหยุดบัญชีโดยสมบูรณ์ ให้ทำให้บัญชีหมดอายุ:

sudo usermod --expiredate 1 deploy

การดำเนินการนี้จะตั้งวันหมดอายุของบัญชีเป็นวันที่ในปี 1970 ดังนั้น sshd จะปฏิเสธการเข้าสู่ระบบไม่ว่าจะมีข้อมูลรับรองใดก็ตาม ยกเลิกการดำเนินการนี้ด้วย sudo usermod --expiredate '' deploy

หลีกเลี่ยง passwd -d เนื่องจากคำสั่งนี้จะตั้งรหัสผ่านว่างแทนการล็อก และใน release รุ่นเก่าที่มี nullok อยู่ใน PAM stack รหัสผ่านว่างจะเป็นรหัสผ่านที่ใครก็ใช้ได้

VPS บัญชี root จำเป็นต้องมีรหัสผ่านหรือไม่

Ubuntu มาพร้อมกับการล็อกบัญชี root ไว้ /etc/shadow เก็บค่า ! แทนแฮช และ sudo passwd -S root แสดงบรรทัดที่ขึ้นต้นด้วย root L จนกว่าจะตั้งรหัสผ่าน จะไม่มีสิ่งใดเข้าสู่ระบบในฐานะ root ด้วยรหัสผ่านได้ ด้วยเหตุนี้อิมเมจจึงจัดเตรียมผู้ใช้ที่สามารถใช้ sudo ให้คุณแทน การทำงานผ่าน บัญชีผู้ใช้ที่มีสิทธิ์น้อยที่สุดบน VPS แทนการทำงานในฐานะ root คือแนวทางที่ควรรักษาไว้

การตั้งรหัสผ่าน root ให้ประโยชน์เฉพาะอย่างหนึ่ง คือเปิดทางเข้าสู่ระบบผ่านคอนโซลของผู้ให้บริการ คอนโซลดังกล่าวเชื่อมต่อกับเครื่องเสมือนใต้ชั้น network stack จึงยังใช้งานได้เมื่อกำหนดค่า sshd ผิดหรือกฎไฟร์วอลล์ไม่ถูกต้อง แต่ก็มีต้นทุนเช่นกัน เมื่อ root มีรหัสผ่าน เมนูกู้คืนของ GRUB จะขอรหัสผ่าน root ก่อนเปิด root shell ดังนั้นเครื่องมือที่คุณจะใช้รีเซ็ตรหัสผ่านที่ลืมจึงถูกป้องกันด้วยรหัสผ่านเดียวกันนั้น

การตั้งรหัสผ่าน root ไม่ได้ทำให้ root เข้าสู่ระบบผ่าน SSH ได้ Ubuntu มาพร้อมกับ PermitRootLogin prohibit-password ซึ่งหมายความว่าอนุญาตเฉพาะคีย์เท่านั้น ตรวจสอบว่าเซิร์ฟเวอร์ของคุณใช้งานการตั้งค่าใดจริง:

sudo sshd -T | grep -i permitrootlogin

sshd -T แสดงการตั้งค่าที่มีผลหลังจากประมวลผลทุกบรรทัด Include แล้ว ดังนั้นจึงเป็นคำตอบที่ถูกต้องเพียงคำตอบเดียวเมื่อ /etc/ssh/sshd_config.d/ มีไฟล์ drop-in อยู่

ตั้งรหัสผ่านจากสคริปต์ด้วย chpasswd

passwd อ่านข้อมูลจากเทอร์มินัลโดยตรง จึงไม่สามารถควบคุมจากสคริปต์ได้ ส่วน chpasswd อ่านคู่ user:password จากอินพุตมาตรฐาน โดยให้มี 1 คู่ต่อบรรทัด

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

วิธีนี้ใช้งานได้ แต่จะบันทึกรหัสผ่านแบบข้อความธรรมดาไว้ในประวัติ shell และในบันทึก CI (continuous integration) ให้แฮชรหัสผ่านก่อนแทน:

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

openssl passwd -6 ขอให้ป้อนรหัสผ่าน 2 ครั้งโดยไม่แสดงอักขระ จากนั้นจะแสดงค่าแฮชแบบ SHA-512 crypt ที่ขึ้นต้นด้วย $6$ -e แจ้งให้ chpasswd ทราบว่าฟิลด์ที่ 2 ถูกแฮชไว้แล้ว จึงคัดลอกค่าไปยัง /etc/shadow ตามเดิม แฮชนี้สามารถจัดเก็บไว้ใน repository หรือในตัวแปร CI ได้อย่างปลอดภัย และรหัสผ่านแบบข้อความธรรมดาจะไม่ออกจากเครื่องที่คุณป้อนรหัสผ่าน

Ubuntu 24.04 จะแฮชรหัสผ่านใหม่ด้วย yescrypt ($y$) เมื่อ passwd เป็นผู้ตั้งรหัสผ่าน ขณะที่ openssl passwd -6 ให้แฮชแบบ SHA-512 ทั้งสองรูปแบบตรวจสอบได้ขณะเข้าสู่ระบบ เนื่องจาก libxcrypt รองรับทั้งสองรูปแบบ การใช้รูปแบบทั้งสองปะปนกันไม่มีปัญหา และ openssl passwd -6 จะทำงานเหมือนกันใน Ubuntu LTS ทุกรุ่น ส่วน chpasswd -c YESCRYPT ไม่เป็นเช่นนั้น: shadow package รุ่นเก่าบน 20.04 ไม่รู้จักชื่อวิธีดังกล่าว

จะตรวจสอบได้อย่างไรว่ารหัสผ่านเปลี่ยนแปลงแล้วจริง

เริ่มจากข้อมูลเมตา แล้วตรวจสอบให้ยืนยันด้วยการเข้าสู่ระบบ

sudo passwd -S deploy

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

ฟิลด์ที่สองคือสถานะ: P หมายถึงรหัสผ่านใช้งานได้, L หมายถึงถูกล็อก และ NP หมายถึงไม่มีรหัสผ่านเลย วันที่ระบุคือวันที่เปลี่ยนรหัสผ่านครั้งล่าสุด ดังนั้นควรเป็นวันที่ปัจจุบัน ตัวเลขหลังจากนั้นคือฟิลด์อายุรหัสผ่านที่อธิบายไว้ด้านล่าง

วิธีทดสอบที่ปลอดภัยที่สุดในระบบที่กำลังทำงานคือ sudo เอง sudo -k จะทิ้งค่าประทับเวลาที่แคชไว้ และ sudo -v จะบังคับให้แสดงพรอมต์ใหม่ หากระบบยอมรับรหัสผ่านใหม่ในขั้นตอนนี้ แสดงว่า PAM ยอมรับรหัสผ่านแล้ว และเซสชันของคุณไม่ได้เปลี่ยนแปลง

sudo -k && sudo -v

หากต้องการทดสอบบัญชีอื่น ให้เรียกใช้ su - deploy จาก shell ที่ไม่มีสิทธิ์ระดับผู้ดูแล อย่าเรียกใช้ sudo su - deploy เนื่องจาก root จะไม่ถูกขอรหัสผ่าน และการทดสอบจะไม่ยืนยันอะไร รหัสผ่านที่ไม่ถูกต้องจะแสดง su: Authentication failure

การทดสอบจริงคือการเข้าสู่ระบบ SSH ใหม่จากแล็ปท็อปของคุณ โดยเปิดเซสชันที่ใช้งานได้เดิมไว้:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). ในที่นี้หมายความว่าเซิร์ฟเวอร์ไม่ได้เสนอการยืนยันตัวตนด้วยรหัสผ่าน ดังนั้นการเปลี่ยนรหัสผ่านจะไม่ช่วยให้เข้าสู่ระบบได้ Permission denied, please try again. หมายความว่าเซิร์ฟเวอร์เสนอวิธีดังกล่าว แต่ปฏิเสธค่าที่คุณป้อน

บังคับให้เปลี่ยนรหัสผ่านในการเข้าสู่ระบบครั้งถัดไปด้วย chage

sudo chage -d 0 deploy

-d 0 กำหนดวันที่เปลี่ยนรหัสผ่านครั้งล่าสุดเป็น epoch ทำให้ PAM ถือว่ารหัสผ่านหมดอายุ การเข้าสู่ระบบแบบโต้ตอบครั้งถัดไปจะขอรหัสผ่านปัจจุบัน จากนั้นขอรหัสผ่านใหม่ ก่อนที่จะให้ shell sudo passwd -e deploy ทำงานเหมือนกันทุกประการ

ใช้วิธีนี้เฉพาะกับบัญชีที่เข้าสู่ระบบแบบโต้ตอบด้วยรหัสผ่านเท่านั้น รหัสผ่านที่หมดอายุยังส่งผลต่อการเข้าสู่ระบบด้วย key เพราะ sshd จะเรียกใช้ขั้นตอน PAM account แม้ key จะเป็นสิ่งที่ใช้ยืนยันตัวตนก็ตาม หากเรียกใช้ ssh deploy@203.0.113.10 'systemctl restart app' ในสคริปต์ คำสั่งจะล้มเหลวด้วยข้อความนี้และหยุดทำงาน:

Password change required but no TTY available.

คำสั่งหลังจากบรรทัดดังกล่าวจะไม่ทำงาน และงานจะแจ้งเพียงรหัสการออกจากโปรแกรมที่ไม่เป็นศูนย์เท่านั้น

ความหมายของฟิลด์อายุรหัสผ่าน

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

ตัวเลขเหล่านั้นคือฟิลด์ที่ 4 ถึง 8 ในบรรทัดของผู้ใช้นั้นใน /etc/shadow วันขั้นต่ำ (chage -m) คือระยะเวลาที่ผู้ใช้ต้องรอก่อนจะเปลี่ยนรหัสผ่านอีกครั้ง ซึ่งช่วยป้องกันไม่ให้ผู้ใช้เปลี่ยนรหัสผ่านวนกลับไปเป็นรหัสผ่านเดิมทันทีหลังจากถูกบังคับให้เปลี่ยน วันสูงสุด (chage -M) คือระยะเวลาที่รหัสผ่านยังคงใช้งานได้ วันแจ้งเตือน (chage -W) คือจำนวนวันก่อนหมดอายุที่การเข้าสู่ระบบจะเริ่มแสดงคำเตือน วันไม่ใช้งาน (chage -I) คือระยะผ่อนผันหลังรหัสผ่านหมดอายุ ก่อนที่ระบบจะไม่ยอมรับรหัสผ่านนั้นอีกต่อไป การหมดอายุของบัญชี (chage -E) คือวันที่กำหนดตายตัว และไม่ขึ้นอยู่กับรหัสผ่าน

sudo chage -M 90 -W 14 deploy

กำหนดค่านี้เฉพาะเมื่อข้อกำหนดของนโยบายระบุให้ต้องใช้เท่านั้น NIST (สถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา) แนะนำมาตั้งแต่ 2017 ไม่ให้บังคับรหัสผ่านหมดอายุเป็นประจำ เนื่องจากทำให้ผู้ใช้มีแนวโน้มสร้างรูปแบบดัดแปลงที่คาดเดาได้จากรหัสผ่านเดิม และแนะนำให้บังคับเปลี่ยนรหัสผ่านเมื่อมีหลักฐานว่าถูกเจาะระบบ รหัสผ่านแบบยาวและไม่ซ้ำกันซึ่งจัดเก็บใน password manager ร่วมกับ SSH ที่ใช้คีย์ มีความปลอดภัยมากกว่าการเปลี่ยนรหัสผ่านทุก 90 วัน

เมื่อคุณลืมรหัสผ่าน root ควรทำอย่างไร

หากบัญชีใดก็ตามบนเครื่องสามารถเรียกใช้ sudo ได้ ก็ไม่จำเป็นต้องกู้คืนรหัสผ่าน: sudo passwd root จะตั้งรหัสผ่านใหม่ กรณีที่ยุ่งยากคือไม่สามารถเข้าสู่ระบบด้วยบัญชีใดได้เลย

ขั้นตอนทั้งหมดด้านล่างต้องใช้คอนโซลของผู้ให้บริการ ซึ่งในแผงควบคุมส่วนใหญ่มักแสดงเป็น VNC (virtual network computing) หรือ serial console คอนโซลนี้เชื่อมต่อกับ virtual machine ใต้ network stack ดังนั้นการตั้งค่า sshd และกฎไฟร์วอลล์จึงไม่มีผลกับคอนโซลดังกล่าว

1. รีบูตเซิร์ฟเวอร์จากแผงควบคุม แล้วเฝ้าดูคอนโซล
2. เปิดเมนู GRUB โดย cloud image มักตั้งค่า GRUB_TIMEOUT=0 ไว้ ดังนั้นให้กด Shift ค้างไว้เมื่อบูตด้วย BIOS หรือกด Esc ซ้ำ ๆ เมื่อบูตด้วย UEFI ทันทีที่เริ่มรีบูต
3. เลือก Advanced options for Ubuntu จากนั้นเลือก entry ที่ลงท้ายด้วย (recovery mode) แล้วเลือก root ในเมนู recovery
4. เรียกใช้ mount -o remount,rw / ก่อน เนื่องจาก recovery จะ mount root filesystem แบบอ่านอย่างเดียว หากไม่ทำขั้นตอนนี้ passwd จะล้มเหลวด้วย passwd: Authentication token manipulation error เพราะไม่สามารถเขียน /etc/shadow ได้
5. เรียกใช้ passwd ubuntu สำหรับบัญชีที่ต้องการ จากนั้นรีบูตจากแผงควบคุม

หาก root มีรหัสผ่านอยู่แล้วและรหัสผ่านนั้นเป็นรหัสที่คุณลืม recovery shell จะขอให้ป้อนรหัสผ่านดังกล่าว และจะไม่สามารถดำเนินการต่อด้วยวิธีนี้ได้ ให้บูต rescue image ของผู้ให้บริการแทน จากนั้น mount ดิสก์จริงและเปลี่ยนรหัสผ่านภายในระบบดังกล่าว

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

ตรวจสอบโครงสร้างพาร์ทิชันจาก lsblk แทนการคัดลอก /dev/vda1 จากหน้านี้ พาร์ทิชัน root คือพาร์ทิชันขนาดใหญ่ ใน image ที่ใช้ UEFI พาร์ทิชันนี้จะอยู่ถัดจาก EFI partition ขนาดเล็ก ซึ่งไม่มีไดเรกทอรี /etc อยู่เลย

เมื่อ SSH หยุดยอมรับรหัสผ่าน

ทำงานจากเซสชันที่ยังใช้งานได้ หากไม่มีเซสชันเหลืออยู่ ให้ใช้คอนโซล

Permission denied, please try again. หมายความว่าเซิร์ฟเวอร์เสนอการยืนยันตัวตนด้วยรหัสผ่าน แต่ปฏิเสธข้อมูลที่คุณส่ง สาเหตุที่พบบ่อยคือเปิด caps lock อยู่ หรือรูปแบบแป้นพิมพ์ของคอนโซลแตกต่างจากที่ใช้เมื่อตั้งรหัสผ่าน

Permission denied (publickey). หมายความว่าเซิร์ฟเวอร์ไม่ได้เสนอการยืนยันตัวตนด้วยรหัสผ่านเลย มีการตั้งค่า PasswordAuthentication no ไว้ที่ใดที่หนึ่ง และใน Ubuntu 22.04 ขึ้นไป การตั้งค่านี้มักอยู่ในไฟล์ drop-in ภายใต้ /etc/ssh/sshd_config.d/ ซึ่งมีผลแทนที่ไฟล์หลัก อ่านค่าที่มีผลจริง:

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

การตั้งค่า KbdInteractiveAuthentication yes ร่วมกับ PasswordAuthentication no ยังคงอนุญาตให้ใช้รหัสผ่านได้ เนื่องจากวิธี keyboard-interactive ใช้ PAM stack เดียวกัน การปิดวิธีหนึ่งแต่เปิดอีกวิธีไว้ ทำให้เซิร์ฟเวอร์ที่ดูเหมือนอนุญาตเฉพาะคีย์ยังคงยอมรับรหัสผ่านที่พิมพ์ได้

Too many authentication failures ในข้อความตัดการเชื่อมต่อหมายความว่าไคลเอนต์ของคุณเสนอคีย์หลายรายการก่อนจะถึงรหัสผ่าน และเซิร์ฟเวอร์พบค่า MaxAuthTries ซึ่งมีค่าเริ่มต้นเป็น 6 บังคับให้ใช้วิธีเดียว:

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

Connection refused บนพอร์ตที่ใช้งานได้เมื่อครู่นี้ มักหมายความว่า fail2ban ที่เฝ้าตรวจสอบ SSH แบนที่อยู่ของคุณหลังจากการพยายามที่ล้มเหลวหลายครั้ง กฎการแบนเริ่มต้นจะปฏิเสธแพ็กเก็ตแทนการทิ้งแพ็กเก็ต จึงทำให้การปฏิเสธกลับมาอย่างรวดเร็วแทนที่จะหมดเวลา จากคอนโซล sudo fail2ban-client status sshd จะแสดงที่อยู่ที่ถูกแบน และ sudo fail2ban-client set sshd unbanip 203.0.113.10 จะยกเลิกการแบนที่อยู่ของคุณ

รหัสผ่านเป็นขั้นตอนเปลี่ยนผ่าน ส่วนคีย์คือสถานะปลายทาง

รหัสผ่านที่ใช้งานผ่าน SSH ได้ คือรหัสผ่านที่เครื่องสแกนทุกเครื่องบนอินเทอร์เน็ตสามารถลองเดาได้ ให้เปลี่ยนไปใช้การยืนยันตัวตนด้วยคีย์ เพื่อให้การเดารหัสผ่านไม่มีผลอีกต่อไป สร้างคู่คีย์ ติดตั้งคีย์สาธารณะ และยืนยันว่าคีย์สามารถเข้าสู่ระบบจากเทอร์มินัลที่สองได้ ก่อนเปลี่ยนแปลงสิ่งอื่น พื้นฐานการจัดการคีย์ SSH อธิบายการสร้างคีย์ authorized_keys และข้อความรหัสผ่าน

จากนั้นปิดการยืนยันตัวตนด้วยรหัสผ่าน และยืนยันการตั้งค่าด้วย sudo sshd -T แทนการเชื่อถือไฟล์ที่คุณแก้ไข การเสริมความปลอดภัยให้ SSH บน VPS อธิบายการตั้งค่า sshd อื่น ๆ ที่ควรเปลี่ยน และ 10 นาทีแรกบน VPS เครื่องใหม่ จัดลำดับการดำเนินการบนเซิร์ฟเวอร์ใหม่

หลังจากนั้นให้เก็บรหัสผ่านไว้ 1 ชุด เซิร์ฟเวอร์ที่อนุญาตเฉพาะคีย์ซึ่งมีการตั้งค่า sshd เสียหาย จะเข้าถึงได้ผ่านคอนโซลของผู้ให้บริการเท่านั้น และคอนโซลดังกล่าวจะขอชื่อผู้ใช้และรหัสผ่าน บัญชีที่มีรหัสผ่านที่รัดกุมและคุณจัดเก็บไว้ คือสิ่งที่ทำให้การแก้ไขปัญหาใช้เวลา 5 นาทีแทนการติดตั้งระบบใหม่

FAQ

ฉันจะเปลี่ยนรหัสผ่าน root บน VPS ได้อย่างไร หากไม่ทราบรหัสผ่านเดิม

เข้าสู่ระบบด้วยผู้ใช้ที่สามารถเรียกใช้ sudo ได้ แล้วเรียกใช้ sudo passwd root คำสั่งนี้จะตั้งรหัสผ่านใหม่โดยไม่ขอรหัสผ่านเดิม เนื่องจาก sudo ได้ยืนยันตัวตนของคุณแล้ว หากไม่มีบัญชีใดบนเครื่องที่สามารถเรียกใช้ sudo ได้ ให้เปิดคอนโซลของผู้ให้บริการ แล้วรีบูตเข้าสู่เมนูการกู้คืนของ GRUB เลือกรายการ shell root เรียกใช้ mount -o remount,rw / แล้วเรียกใช้ passwd หาก root มีรหัสผ่านอยู่แล้วและรหัสผ่านนั้นคือรหัสที่คุณสูญหาย shell สำหรับการกู้คืนจะขอรหัสผ่านดังกล่าว จากนั้นวิธีที่เหลือคือใช้อิมเมจกู้คืนของผู้ให้บริการ โดยเมานต์ดิสก์และใช้ chroot แล้ว

เหตุใด passwd จึงแสดงข้อความ "Authentication token manipulation error"

มี 2 สาเหตุที่ทำให้เกิดข้อความนี้ สาเหตุที่พบบ่อยคือป้อนคำตอบผิดที่พรอมต์ Current password: และบรรทัด passwd: password unchanged ใต้พรอมต์นั้นจะยืนยันว่าไม่มีการเขียนข้อมูล อีกสาเหตุคือระบบไฟล์ไม่สามารถเขียนได้ ซึ่งมักเกิดในโหมดการกู้คืน เนื่องจาก / ถูกเมานต์เป็นแบบอ่านอย่างเดียวในโหมดนี้ เรียกใช้ mount -o remount,rw / แล้วลองอีกครั้ง

การเปลี่ยนรหัสผ่าน Linux จะเปลี่ยนรหัสผ่าน sudo ด้วยหรือไม่

เปลี่ยน sudo ไม่มีรหัสผ่านของตนเอง แต่จะยืนยันตัวตนของคุณผ่าน PAM โดยตรวจสอบกับรายการ /etc/shadow เดียวกับที่ SSH และ su ใช้ ดังนั้นแต่ละบัญชีจึงมีรหัสผ่านเพียงรายการเดียว นี่จึงเป็นเหตุผลที่พรอมต์ sudo ครั้งแรกหลังเปลี่ยนรหัสผ่านเป็นการทดสอบจริง เรียกใช้ sudo -k && sudo -v เพื่อบังคับให้แสดงพรอมต์ดังกล่าวขณะที่เซสชันของคุณยังใช้งานได้

การเปลี่ยนรหัสผ่านจะทำให้ SSH keys หรือเซสชันที่เปิดอยู่ใช้งานไม่ได้หรือไม่

ไม่ การยืนยันตัวตนด้วย public key จะไม่อ่าน /etc/shadow ดังนั้น keys จะยังใช้งานได้หลังเปลี่ยนรหัสผ่าน หลัง passwd -l และหลัง chage -d 0 เซสชันที่เปิดอยู่แล้วจะยังคงเปิดอยู่ เนื่องจาก SSH ตรวจสอบข้อมูลรับรองเฉพาะขณะเข้าสู่ระบบเท่านั้น สิ่งเดียวที่เปลี่ยนแปลงภายในเซสชันที่ยังทำงานอยู่คือ sudo ซึ่งจะขอรหัสผ่านใหม่หนึ่งครั้งเมื่อเวลาประทับ 15 minute หมดอายุ

ฉันจะบังคับให้ผู้ใช้เปลี่ยนรหัสผ่านเมื่อเข้าสู่ระบบครั้งถัดไปได้อย่างไร

เรียกใช้ sudo chage -d 0 deploy หรือ sudo passwd -e deploy ซึ่งให้ผลเช่นเดียวกัน วันที่เปลี่ยนรหัสผ่านครั้งล่าสุดที่จัดเก็บไว้จะถูกเลื่อนไปเป็น epoch ทำให้ PAM ถือว่ารหัสผ่านหมดอายุ และการเข้าสู่ระบบแบบโต้ตอบครั้งถัดไปจะต้องตั้งรหัสผ่านใหม่ก่อนเริ่ม shell อย่าดำเนินการนี้กับบัญชีที่สคริปต์ใช้ผ่าน SSH เพราะคำสั่งแบบไม่โต้ตอบจะล้มเหลวด้วย Password change required but no TTY available. และจะไม่ทำงานเลย