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

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

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

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

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

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

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

เชลล์ที่เปิดอยู่จะยังคงทำงานได้ตามปกติแม้ว่าคุณจะเปลี่ยน ล็อก หรือกำหนดวันหมดอายุของบัญชีผู้ใช้นั้นไปแล้ว เนื่องจาก SSH จะตรวจสอบข้อมูลประจำตัวเฉพาะในขั้นตอนการล็อกอินเท่านั้นและจะไม่ตรวจสอบซ้ำอีก ยกเว้นกรณีของ sudo ซึ่งจะตรวจสอบรหัสผ่านของคุณผ่าน PAM (pluggable authentication modules) อีกครั้งเมื่อ 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 ถูกแทนที่แล้ว ผลลัพธ์อื่นใดแสดงว่ารหัสผ่านเดิมยังคงอยู่

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

ใน VPS image ส่วนใหญ่ บัญชีเริ่มต้น (ubuntu หรือชื่อใดก็ตามที่ผู้ให้บริการของคุณกำหนดมา) จะไม่มีรหัสผ่าน มีเพียง SSH key เท่านั้น passwd จึงไม่มีรหัสผ่านปัจจุบันให้ตรวจสอบ ทำให้ไม่สามารถผ่านขั้นตอนแรกไปได้ ให้ใช้ sudo passwd $USER แทน ซึ่งสามารถทำงานได้เนื่องจากไฟล์ sudoers drop-in ของ image อนุญาตให้บัญชีนั้นเรียกใช้ 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 ของผู้ใช้ยังคงใช้งานได้ตามปกติ เนื่องจากการตรวจสอบสิทธิ์ด้วย public key ไม่ได้อ่านค่าจาก /etc/shadow หากต้องการระงับบัญชีโดยสมบูรณ์ ให้กำหนดวันหมดอายุของบัญชีแทน:

sudo usermod --expiredate 1 deploy

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

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

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

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

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

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

sudo sshd -T | grep -i permitrootlogin

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

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

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

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

วิธีนี้ใช้งานได้จริง แต่จะทำให้รหัสผ่านที่เป็นข้อความธรรมดา (plaintext) ไปปรากฏอยู่ในประวัติการใช้งานเชลล์และในบันทึกของ CI (continuous integration) ของคุณ ให้ใช้วิธีแฮชรหัสผ่านก่อนแทนดังนี้:

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

openssl passwd -6 จะถามรหัสผ่านสองครั้งโดยไม่แสดงอักขระบนหน้าจอ จากนั้นจะแสดงผลเป็นแฮชแบบ SHA-512 crypt ซึ่งขึ้นต้นด้วย $6$ ส่วน -e จะแจ้งให้ chpasswd ทราบว่าฟิลด์ที่สองนั้นถูกแฮชมาเรียบร้อยแล้ว จึงคัดลอกค่าดังกล่าวลงใน /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 รุ่นเก่าบน 20.04 ไม่รู้จักชื่อวิธีการแฮชดังกล่าว แฮชเหล่านี้ยังคงใช้งานได้แม้จะมีการอัปเกรดเวอร์ชันของระบบปฏิบัติการ ดังนั้นการ ย้ายเซิร์ฟเวอร์จาก 24.04 ไปยัง 26.04 จึงไม่บังคับให้คุณต้องรีเซ็ตรหัสผ่านของผู้ใช้งานแต่อย่างใด

คุณจะตรวจสอบได้อย่างไรว่ารหัสผ่านถูกเปลี่ยนจริง?

ให้เริ่มจากการตรวจสอบข้อมูล metadata จากนั้นจึงพิสูจน์ด้วยการล็อกอิน

sudo passwd -S deploy

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

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

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

sudo -k && sudo -v

หากต้องการทดสอบบัญชีอื่น ให้รันคำสั่ง su - deploy จากเชลล์ที่ไม่มีสิทธิ์พิเศษ ห้ามรัน 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.

หลังจากบรรทัดดังกล่าวจะไม่มีคำสั่งใดทำงานต่อ และงานนั้นจะรายงานเพียง exit code ที่ไม่ใช่ศูนย์เท่านั้น

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

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 ว่าไม่ควรบังคับให้เปลี่ยนรหัสผ่านตามรอบเวลาปกติ เนื่องจากจะผลักดันให้ผู้ใช้เลือกตั้งรหัสผ่านที่คาดเดาง่ายโดยปรับเปลี่ยนเพียงเล็กน้อยจากรหัสเดิม โดยแนะนำให้บังคับเปลี่ยนรหัสผ่านเฉพาะเมื่อมีหลักฐานว่าบัญชีถูกบุกรุกเท่านั้น การใช้รหัสผ่านที่ยาวและไม่ซ้ำใครซึ่งเก็บไว้ในโปรแกรมจัดการรหัสผ่าน ควบคู่ไปกับการใช้ SSH แบบใช้คีย์ (key based SSH) มีประสิทธิภาพดีกว่าการบังคับเปลี่ยนรหัสผ่านทุก 90 วัน

สิ่งที่ต้องทำเมื่อลืมรหัสผ่าน root

หากมีบัญชีใดบนเซิร์ฟเวอร์ที่สามารถเรียกใช้ sudo ได้ ก็ไม่มีอะไรต้องกู้คืน เพราะ sudo passwd root สามารถตั้งรหัสผ่านใหม่ได้ทันที กรณีที่ยากคือการที่ไม่สามารถล็อกอินเข้าสู่ระบบได้เลย

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

1. รีบูตเซิร์ฟเวอร์จากแผงควบคุมและเฝ้าดูผ่านคอนโซล
2. เข้าสู่เมนู GRUB โดยปกติแล้วอิมเมจบนคลาวด์จะตั้งค่า GRUB_TIMEOUT=0 ไว้ ดังนั้นให้กด Shift ค้างไว้หากเป็นการบูตแบบ BIOS หรือกด Esc ซ้ำๆ หากเป็นการบูตแบบ UEFI ทันทีที่เริ่มการรีบูต
3. เลือก Advanced options for Ubuntu จากนั้นเลือกรายการที่ลงท้ายด้วย (recovery mode) แล้วเลือก root ในเมนูกู้คืน
4. เรียกใช้ mount -o remount,rw / ก่อนเป็นอันดับแรก โหมดกู้คืนจะ mount root filesystem แบบอ่านได้อย่างเดียว (read-only) หากไม่ทำขั้นตอนนี้ 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

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

สิ่งที่ต้องทำเมื่อ SSH ไม่ยอมรับรหัสผ่านของคุณ

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

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

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

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

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

บรรทัดเดียวกันนั้นคือสิ่งที่แสดงขึ้นมาเมื่อการล็อกอินด้วยคีย์ถูกปฏิเสธด้วย ดังนั้นหากคุณกำลังใช้คีย์แทนรหัสผ่าน การตั้งค่ารหัสผ่านของเซิร์ฟเวอร์เป็นเพียงหนึ่งใน ห้าสาเหตุเบื้องหลัง Permission denied (publickey) และผลลัพธ์จาก ssh -v จะบอกคุณว่าคุณกำลังเจอกับสาเหตุใด

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

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

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

รหัสผ่านเป็นเพียงจุดเริ่มต้น แต่กุญแจคือเป้าหมายสุดท้าย

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

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

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

FAQ

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

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

ทำไมคำสั่ง passwd ถึงแสดงข้อความ "Authentication token manipulation error"?

ข้อความนี้เกิดจากสองสาเหตุ สาเหตุที่พบบ่อยคือการตอบคำถามที่ Current password: ผิดพลาด และบรรทัด passwd: password unchanged ด้านล่างจะยืนยันว่าไม่มีการเขียนข้อมูลใดลงไป อีกสาเหตุหนึ่งคือระบบไฟล์ไม่สามารถเขียนข้อมูลได้ ซึ่งเป็นสิ่งที่คุณจะพบในโหมด recovery เนื่องจาก / ถูก mount แบบอ่านได้อย่างเดียว (read-only) ในโหมดนั้น ให้รันคำสั่ง 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 นาที

ฉันจะบังคับให้ผู้ใช้เปลี่ยนรหัสผ่านในการล็อกอินครั้งถัดไปได้อย่างไร?

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