วิธีเปลี่ยนรหัสผ่าน 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 ที่สองไว้ในขณะนี้และปล่อยให้เชื่อมต่อค้างไว้ ความผิดพลาดเกือบทุกอย่างในคู่มือนี้สามารถแก้ไขได้ภายใน 2 นาทีหากยังมีเชลล์ที่ผ่านการยืนยันตัวตนเปิดอยู่ แต่หากปิดเชลล์สุดท้ายไปแล้ว คุณอาจต้องเข้าถึงผ่านคอนโซลโดยตรง

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

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) ไปปรากฏอยู่ในประวัติการใช้งานเชลล์และใน log ของ CI (continuous integration) ของคุณ ดังนั้นควรทำการแฮชรหัสผ่านก่อนด้วยวิธีนี้:

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

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

Ubuntu 24.04 จะแฮชรหัสผ่านใหม่ด้วย yescrypt ($y$) เมื่อตั้งค่าผ่าน passwd ในขณะที่ openssl passwd -6 จะให้ผลลัพธ์เป็น SHA-512 ทั้งสองรูปแบบสามารถตรวจสอบความถูกต้องได้เมื่อเข้าสู่ระบบ เนื่องจาก libxcrypt สามารถอ่านได้ทั้งสองรูปแบบ การใช้งานร่วมกันจึงไม่มีปัญหา และ openssl passwd -6 จะทำงานในลักษณะเดียวกันบน Ubuntu LTS ทุกรุ่นตั้งแต่ 18.04 เป็นต้นไป ซึ่งต่างจาก chpasswd -c YESCRYPT ที่ไม่รองรับการทำงานนี้ เนื่องจากแพ็กเกจ shadow รุ่นเก่าบน 20.04 ไม่รู้จักชื่อเมธอดดังกล่าว สำหรับ Ubuntu 16.04 ถือเป็นข้อยกเว้นเนื่องจาก OpenSSL 1.0.2 ไม่มีตัวเลือก -6 ให้ใช้งาน ค่าแฮชเหล่านี้ยังคงใช้งานได้แม้จะมีการอัปเกรดเวอร์ชันของระบบปฏิบัติการ ดังนั้นการ ย้ายเซิร์ฟเวอร์จาก 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 แม้ว่าจะใช้ key ในการยืนยันตัวตนแล้วก็ตาม ดังนั้นการใช้ ssh deploy@203.0.113.10 'systemctl restart app' ผ่านสคริปต์จะล้มเหลวด้วยข้อผิดพลาดนี้ก่อนที่คำสั่งจะทำงาน:

Password change required but no TTY available.

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

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

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 ค่า Minimum days (chage -m) คือระยะเวลาที่ผู้ใช้ต้องรอก่อนที่จะเปลี่ยนรหัสผ่านได้อีกครั้ง ซึ่งช่วยป้องกันไม่ให้ผู้ใช้เปลี่ยนรหัสผ่านกลับไปเป็นรหัสผ่านเดิมทันทีหลังจากถูกบังคับให้เปลี่ยน ค่า Maximum days (chage -M) คือระยะเวลาที่รหัสผ่านยังคงใช้งานได้ ค่า Warning days (chage -W) คือระยะเวลาที่ระบบจะเริ่มแสดงคำเตือนเมื่อมีการล็อกอิน ค่า Inactive days (chage -I) คือระยะเวลาผ่อนผันหลังจากรหัสผ่านหมดอายุ ก่อนที่รหัสผ่านนั้นจะถูกปฏิเสธการใช้งานโดยสิ้นเชิง ส่วน Account expiry (chage -E) คือวันที่บัญชีจะหมดอายุอย่างถาวร ซึ่งเป็นค่าที่เป็นอิสระจากการกำหนดอายุรหัสผ่าน

sudo chage -M 90 -W 14 deploy

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

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

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

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

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

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

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

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

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

Permission denied (publickey). หมายความว่าเซิร์ฟเวอร์ไม่เคยเสนอการยืนยันตัวตนด้วยรหัสผ่าน ดังนั้นค่าที่มีผลจริงคือ PasswordAuthentication no ซึ่ง no นั้นอาจอยู่ในไฟล์หลักหรือไฟล์ drop-in ดังนั้นให้ตรวจสอบทั้งสองที่ sshd จะอ่านไฟล์ภายใต้ /etc/ssh/sshd_config.d/ ที่จุดเริ่มต้นของการตั้งค่า และจะยึดค่าแรกที่พบสำหรับแต่ละคีย์เวิร์ด ดังนั้นไฟล์ drop-in จึงมีลำดับความสำคัญเหนือกว่า /etc/ssh/sshd_config กฎเดียวกันนี้มักทำงานในทางกลับกันบนเซิร์ฟเวอร์ Ubuntu 24.04 ที่ติดตั้งจาก ISO โดยเปิดใช้งาน SSH ไว้: ตัวติดตั้งจะทิ้งไฟล์ drop-in ของ cloud-init ไว้ที่ 50-cloud-init.conf ซึ่งตั้งค่า PasswordAuthentication yes เอาไว้ ทำให้ no ที่เพิ่มเข้าไปในไฟล์หลักถูกละเลย ให้ตรวจสอบค่าที่มีผลจริงด้วยคำสั่ง:

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

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

บรรทัดเดียวกันนั้นคือสิ่งที่แสดงขึ้นมาเมื่อการล็อกอินด้วยคีย์ถูกปฏิเสธเช่นกัน ดังนั้นหากสิ่งที่คุณนำเสนอคือคีย์ไม่ใช่รหัสผ่าน การตั้งค่ารหัสผ่านของเซิร์ฟเวอร์ก็เป็นเพียงหนึ่งใน ข้อผิดพลาด 5 ประการที่อยู่เบื้องหลัง 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 ได้แบนที่อยู่ IP ของคุณหลังจากพยายามล็อกอินล้มเหลวหลายครั้ง กฎการแบนเริ่มต้นของมันจะปฏิเสธแพ็กเก็ตแทนที่จะทิ้งแพ็กเก็ตนั้นไป ซึ่งเป็นเหตุผลว่าทำไมการปฏิเสธจึงตอบกลับมาอย่างรวดเร็วแทนที่จะรอจนหมดเวลา (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 เลือกรายการ shell แบบ root รันคำสั่ง mount -o remount,rw / จากนั้นรัน passwd หาก root มีรหัสผ่านอยู่แล้วและคุณทำรหัสผ่านนั้นหาย shell การกู้คืนจะถามรหัสผ่านดังกล่าว ซึ่งในกรณีนี้ทางเลือกที่เหลือคือการใช้ rescue image ของผู้ให้บริการโดยทำการ mount ดิสก์และทำ chroot เข้าไป

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

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

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

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

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

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

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

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