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

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

การตั้งรหัสผ่านจากสคริปต์ด้วย 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 จะล้างการประทับเวลาที่แคชไว้ และ sudo -v จะบังคับให้แสดงพรอมต์รหัสผ่านใหม่ หากรหัสผ่านใหม่ได้รับการยอมรับ แสดงว่า 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 ดังนั้นการตั้งค่า sshd และกฎของ 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 จากหน้านี้ root partition คือ partition ขนาดใหญ่ ในอิมเมจแบบ UEFI มันจะอยู่ข้างๆ EFI partition ขนาดเล็กซึ่งไม่มีไดเรกทอรี /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 เดียวกัน การปิดวิธีหนึ่งแต่เปิดอีกวิธีหนึ่งไว้คือสาเหตุที่ทำให้เซิร์ฟเวอร์ที่ดูเหมือนรองรับเฉพาะคีย์ยังคงยอมรับการพิมพ์รหัสผ่านอยู่

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

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

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

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

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

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

ไม่ การยืนยันตัวตนด้วย public key ไม่เคยอ่านค่าจาก /etc/shadow ดังนั้น keys จะยังคงใช้งานได้ตามปกติหลังจากเปลี่ยนรหัสผ่าน หลังจาก passwd -l และหลังจาก chage -d 0 ส่วน 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. และไม่ทำงาน