ทำไมไม่ใช้ root ต่อไปเลยล่ะ?

ทุกอย่างที่รันด้วย root ทำให้ทั้งระบบพังได้ แม้แต่การพิมพ์ผิด บอตยังลองชื่อผู้ใช้ 'root' เป็นอันดับแรก การปิดล็อกอิน root จึงตัดเป้าหมายที่ถูกเดาบ่อยที่สุดออกไป ผู้ใช้ที่มีชื่อพร้อม sudo ให้จังหวะหยุดคิดก่อนทุกคำสั่งที่ใช้สิทธิ์สูง และมีบันทึกว่ารันอะไรไปบ้าง

ถ้าล็อกตัวเองอยู่ข้างนอกล่ะ?

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

ควรเปิด sudo แบบไม่ต้องใส่รหัสผ่านไหม?

สำหรับบัญชีส่วนตัว ให้คงการถามรหัสผ่านไว้ — มันคือแนวป้องกันสุดท้ายถ้า SSH key หลุด sudo แบบไม่ใช้รหัสผ่านเหมาะกับผู้ใช้ deploy แยกต่างหากที่ระบบอัตโนมัติใช้ โดยจำกัดแค่คำสั่งที่จำเป็นจริงๆ

เซิร์ฟเวอร์ Debian ของฉันไม่มีคำสั่ง sudo ทำไม?

image Debian แบบมินิมอลไม่ได้ติดมาทุกครั้ง ติดตั้งด้วย root ผ่าน 'apt install -y sudo' แล้วเพิ่มผู้ใช้ของคุณเข้ากลุ่ม sudo

ต้องใช้พอร์ต SSH ไหน?

พอร์ตที่แสดงในแดชบอร์ด แพ็กเกจ IP เฉพาะใช้พอร์ต 22 บน IP ของคุณเอง ส่วนแพ็กเกจ NAT ใช้พอร์ต SSH ส่วนตัวของคุณ

วิธีสร้างผู้ใช้ sudo บน VPS และเลิกใช้ root

สร้างผู้ใช้ sudo ที่ไม่ใช่ root บน Ubuntu หรือ Debian ให้ SSH key ทดสอบ แล้วค่อยปิดการล็อกอิน root — ตามลำดับที่ไม่ทำให้คุณถูกล็อกอยู่ข้างนอก

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

นี่คือลำดับที่ปลอดภัยสำหรับ Ubuntu 22.04/24.04 และ Debian 12

1. สร้างผู้ใช้

ในฐานะ root:

adduser deploy
usermod -aG sudo deploy

adduser จะถามรหัสผ่านและข้อมูลเสริมบางอย่าง (กด Enter ผ่านไปได้เลย) เลือกรหัสผ่านจริงจัง เพราะคุณจะต้องพิมพ์มันตอนใช้ sudo บน image Debian แบบมินิมอล ถ้าไม่มีคำสั่งนี้ให้รัน apt install -y sudo ก่อน

2. ให้ SSH key กับผู้ใช้

วิธีที่ง่ายที่สุดคือคัดลอก key ที่อนุญาตของ root โดยรักษาความเป็นเจ้าของให้ถูกต้อง:

rsync --archive --chown=deploy:deploy /root/.ssh /home/deploy

ถ้าอยากทำเอง:

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

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

3. ทดสอบก่อนเปลี่ยนอะไร

เปิดเซสชัน root ค้างไว้ ในเทอร์มินัล ใหม่:

ssh -p 22 deploy@203.0.113.10
sudo whoami

ใช้ IP และพอร์ตของคุณเอง — ถ้าเป็นแพ็กเกจ NAT คือพอร์ต SSH ส่วนตัวจากแดชบอร์ด ถ้า sudo whoami พิมพ์ root ออกมา แปลว่าเรียบร้อย ถ้าล็อกอินไม่ผ่าน คุณยังมีหน้าต่าง root ไว้แก้

4. ปิดการล็อกอิน root

ถึงเวลาปิดประตู สร้างไฟล์ drop-in เล็กๆ แทนการแก้ไฟล์ตั้งค่าหลัก:

cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
EOF
sshd -t && systemctl reload ssh

sshd -t ตรวจไวยากรณ์ก่อน การตั้งค่าที่พังบวกกับ reload คือเส้นทางที่ทำให้หลายคนต้องไปพึ่งคอนโซล PasswordAuthentication no จะมีความหมายก็ต่อเมื่อการล็อกอินด้วย key ใช้ได้กับผู้ใช้ใหม่แล้ว — ซึ่งคุณเพิ่งทดสอบไป

เปิดเทอร์มินัลอีกอันแล้วยืนยันว่า root ถูกปฏิเสธและ deploy ยังเข้าได้ จากนั้นค่อยปิดเซสชัน root เก่า

5. ทางเลือก: sudo ไม่ต้องใส่รหัสผ่านสำหรับระบบอัตโนมัติ

ถ้าสคริปต์ deploy ต้องใช้ sudo โดยไม่ถาม ให้สิทธิ์แค่นั้นพอดี ไม่ต้องกว้างกว่านั้น:

visudo -f /etc/sudoers.d/deploy

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

พูดตรงๆ NOPASSWD: ALL ดูน่าใช้ แต่มันหมายความว่า key ที่ถูกขโมยเท่ากับ root จำกัดไว้แค่คำสั่งที่ระบบอัตโนมัติรัน

ถ้ามีอะไรผิดพลาด

เว็บคอนโซลในแดชบอร์ดไม่ขึ้นกับ SSH หรือไฟร์วอลล์ เข้าจากตรงนั้น แก้ไฟล์ใน /etc/ssh/sshd_config.d/ แล้ว reload จบ ขั้นตอนกู้คืนทั้งหมดเราเขียนไว้ในวิธีกลับเข้า VPS ที่ถูกล็อก

ทำอะไรต่อ

เปลี่ยนไปใช้การล็อกอินด้วย key อย่างเดียวให้เรียบร้อย: การยืนยันตัวตนด้วย SSH key
ลดเสียงรบกวนจากการสุ่มรหัสผ่าน: fail2ban
ทำเรื่องพื้นฐานที่เหลือด้วยเช็กลิสต์ความปลอดภัยสำหรับ VPS ใหม่

ตัวเลือกการเข้าถึงของแต่ละแพ็กเกจอยู่ในเอกสารการเข้าถึง แม้แต่ Nano ราคา $3 ก็สมควรมีผู้ใช้ที่ไม่ใช่ root — นี่คือการอัปเกรดความปลอดภัยที่ถูกที่สุด