วิธีตั้งค่า SSH Hardening บน VPS ให้ปลอดภัยสูงสุด

เหตุผลที่ต้องทำ Hardening ให้ SSH เป็นอันดับแรก

SSH คือช่องทางที่คุณใช้ควบคุมเซิร์ฟเวอร์ ซึ่งทำให้มันกลายเป็นแม่กุญแจที่ผู้โจมตีทุกคนพยายามปลดล็อกเป็นอันดับแรก ทันทีที่ VPS ออนไลน์ สแกนเนอร์จะเริ่มสุ่มชื่อผู้ใช้และรหัสผ่านที่พอร์ต 22 คุณสามารถสังเกตเห็นเหตุการณ์นี้ได้ใน log ภายในเวลาไม่กี่นาที การทำ Hardening ให้ SSH คือการกำจัดสิ่งที่ผู้โจมตีสามารถคาดเดาได้ออกไป เช่น ปิดการล็อกอินด้วยรหัสผ่านทั้งหมด ปิดการล็อกอินด้วย root และอนุญาตให้เข้าถึงได้เฉพาะผ่าน cryptographic keys เท่านั้น เมื่อคุณทำเช่นนี้ การสุ่มเดาอย่างต่อเนื่องจะไม่มีทางสำเร็จ เพราะไม่มีรหัสผ่านให้ค้นหา

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

ขั้นตอนที่ 1: ตรวจสอบให้แน่ใจว่าการยืนยันตัวตนด้วยคีย์ใช้งานได้ก่อน

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

ที่เครื่องคอมพิวเตอร์ของคุณ ให้สร้างคีย์ขึ้นมาหากคุณยังไม่มี:

ssh-keygen -t ed25519

คัดลอกส่วนที่เป็น public key ไปยังเซิร์ฟเวอร์:

ssh-copy-id user@your-server

จากนั้นให้เปิด SSH session ใหม่ หากระบบอนุญาตให้คุณเข้าใช้งานได้โดยไม่ถามรหัสผ่าน แสดงว่าคีย์ของคุณใช้งานได้และคุณสามารถปิดการใช้งานรหัสผ่านได้อย่างปลอดภัย หากระบบปฏิเสธการเข้าถึงด้วย Permission denied (publickey) แสดงว่า ข้อผิดพลาดนั้นอาจเกิดจากสาเหตุที่แตกต่างกัน 5 ประการ และผลลัพธ์จาก ssh -v จะบอกคุณว่าคุณกำลังเจอกับปัญหาใดก่อนที่คุณจะทำการเปลี่ยนแปลงอื่นใด หากคุณเพิ่งเคยใช้งานคีย์ หรือใช้งานคอมพิวเตอร์มากกว่าหนึ่งเครื่อง พื้นฐานการจัดการ SSH key จะอธิบายรูปแบบการทำงานทั้งหมดไว้ ได้แก่ การใช้หนึ่งคีย์ต่อหนึ่งอุปกรณ์, สิทธิ์ที่ sshd ต้องการ และวิธีการเพิกถอนคีย์เมื่อแล็ปท็อปสูญหาย

ขั้นตอนที่ 2: การเพิ่มความปลอดภัยให้ sshd ด้วยไฟล์ drop-in

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

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

ใส่เนื้อหาต่อไปนี้ลงไป:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

แต่ละบรรทัดเป็นการปิดช่องโหว่ PasswordAuthentication no คือส่วนที่สำคัญที่สุด เมื่อปิดการใช้งานรหัสผ่าน การโจมตีแบบ brute-force จะไม่มีช่องทางให้เจาะระบบได้อีก KbdInteractiveAuthentication no เป็นการปิดช่องทางเข้าถึงในรูปแบบรหัสผ่านอีกทางหนึ่ง PermitRootLogin no หมายความว่าผู้โจมตีจะต้องทราบชื่อผู้ใช้ของคุณและต้องมีกุญแจส่วนตัว (key) ไม่ใช่เพียงแค่พุ่งเป้าไปที่บัญชี root ซึ่งมีอยู่บนทุกเครื่องเพียงอย่างเดียว

ขั้นตอนที่ 3: ทดสอบการตั้งค่าแล้วโหลดใหม่

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

sudo sshd -t

หากไม่มีข้อความแสดงขึ้นมา แสดงว่าการตั้งค่าถูกต้อง จากนั้นให้โหลด SSH ใหม่:

sudo systemctl reload ssh

จากนั้นตรวจสอบการตั้งค่าที่ sshd ใช้งานจริง เพื่อดูว่ามีการตั้งค่าจากไฟล์อื่นมาทับซ้อนหรือไม่:

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

ทั้งสองคำสั่งควรแสดงผลเป็น no ตอนนี้ให้เปิด terminal ใหม่ขึ้นมาอีกหน้าต่างหนึ่งโดยไม่ต้องปิด session ปัจจุบัน หากคุณสามารถล็อกอินด้วย key ได้สำเร็จ ถือว่าเสร็จสิ้น หากมีสิ่งใดผิดพลาด session แรกของคุณยังคงเปิดอยู่เพื่อใช้แก้ไข ปัญหานี้เป็นตาข่ายรองรับความปลอดภัย ดังนั้นห้ามข้ามขั้นตอนนี้เด็ดขาด

ขั้นตอนที่ 4: พอร์ตที่ไม่ใช่มาตรฐาน (ทางเลือก)

การย้าย SSH ออกจากพอร์ต 22 ไปยังพอร์ตอื่น เช่น 2222 ไม่ได้ช่วยเพิ่มความปลอดภัยในทางปฏิบัติ เพราะผู้โจมตีที่มุ่งมั่นจะสแกนทุกพอร์ตอยู่แล้ว สิ่งที่ทำได้คือการลดปริมาณ log ที่ไม่จำเป็น เนื่องจากสแกนเนอร์อัตโนมัติส่วนใหญ่จะลองเฉพาะพอร์ต 22 เท่านั้น หากคุณต้องการทำ ให้เพิ่ม Port 2222 ลงในไฟล์ drop-in ของคุณ อนุญาตพอร์ตใหม่ใน firewall ก่อน จากนั้นรัน sudo systemctl daemon-reload && sudo systemctl restart ssh.socket และเชื่อมต่อด้วย ssh -p 2222 บน Ubuntu 24.04 นั้น ssh.socket เป็นผู้ควบคุมพอร์ตที่เปิดรับการเชื่อมต่อ ดังนั้นการใช้ reload ssh เพียงอย่างเดียวจะทำให้ sshd ยังคงทำงานบนพอร์ต 22 การรีสตาร์ท socket จึงเป็นวิธีที่ทำให้พอร์ตใหม่มีผล ให้มองว่านี่คือการจัดระเบียบ ไม่ใช่การป้องกัน

ขั้นตอนที่ 5: การเพิ่มชั้นการป้องกัน

การใช้ SSH keys ที่มีความปลอดภัยสูงเป็นรากฐานสำคัญ และยังมีอีกสองชั้นที่ควรนำมาปรับใช้เพิ่มเติม

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

วิธีที่แข็งแกร่งยิ่งกว่าคือการไม่เปิดให้ SSH เข้าถึงได้จากอินเทอร์เน็ตสาธารณะโดยตรง หากคุณ นำ SSH ไปไว้หลัง WireGuard VPN และตั้งค่า firewall ให้เปิดพอร์ต 22 เฉพาะสำหรับ tunnel เท่านั้น จะไม่มีใครที่อยู่นอก VPN สามารถเข้าถึง SSH ได้เลย ทำให้การสุ่มรหัสผ่านแบบ brute-force กลายเป็นเรื่องที่เป็นไปไม่ได้ แทนที่จะเป็นเพียงแค่เรื่องยาก ทั้งหมดนี้ตั้งอยู่บนสมมติฐานว่ามีการใช้ firewall แบบ default-deny เป็นพื้นฐาน ซึ่งอธิบายไว้ใน การตั้งค่า UFW บน VPS

SSH เป็นเพียงหัวข้อหนึ่งในรายการตรวจสอบที่ใหญ่กว่า: 10 นาทีแรกบน VPS ใหม่ จะเรียงลำดับขั้นตอนต่างๆ ไว้ให้ และ การอัปเดตความปลอดภัยอัตโนมัติบน Ubuntu จะช่วยให้เซิร์ฟเวอร์ของคุณได้รับการแพตช์อย่างต่อเนื่องหลังจากนั้น การล็อกประตูหน้าบ้านไม่ได้ช่วยป้องกันบริการที่อยู่ด้านหลัง ดังนั้นหาก VPS เครื่องเดียวกันนี้รัน password vault อยู่ การตรวจสอบความปลอดภัยของ Vaultwarden จะครอบคลุมสองสิ่งที่การยืนยันตัวตนด้วย key เข้าไม่ถึง นั่นคือ admin token และไฟล์สำรองข้อมูลของระบบ

FAQ

ฉันจะปิดการล็อกอินด้วยรหัสผ่านสำหรับ SSH บน Ubuntu 24.04 ได้อย่างไร?

สร้างไฟล์ drop-in ที่ /etc/ssh/sshd_config.d/00-hardening.conf (การใช้ prefix 00 ช่วยให้ไฟล์ถูกเรียงลำดับก่อน 50-cloud-init.conf ซึ่งมี PasswordAuthentication yes ที่อาจทับซ้อนกันได้ เนื่องจาก sshd จะยึดค่าแรกที่อ่านพบ) โดยใส่เนื้อหา PasswordAuthentication no และ KbdInteractiveAuthentication no ลงไป จากนั้นรัน sudo sshd -t เพื่อตรวจสอบความถูกต้อง และตามด้วย sudo systemctl reload ssh ตรวจสอบให้แน่ใจว่าการล็อกอินด้วย key ใช้งานได้ใน session ใหม่ก่อนที่จะปิดการล็อกอินด้วยรหัสผ่าน การแก้ไขไฟล์ drop-in แทนการแก้ไข sshd_config โดยตรงจะช่วยให้การตั้งค่าคงอยู่แม้มีการอัปเกรดแพ็กเกจและสามารถย้อนกลับได้ง่าย

ฉันควรปิดการล็อกอินด้วย root ผ่าน SSH หรือไม่?

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

การเปลี่ยนพอร์ต SSH ช่วยให้เซิร์ฟเวอร์ปลอดภัยขึ้นหรือไม่?

ไม่ช่วยอย่างมีนัยสำคัญ การย้ายออกจากพอร์ต 22 ช่วยหลบเลี่ยงการสแกนแบบสุ่มที่ตรวจสอบเฉพาะพอร์ต 22 ซึ่งช่วยลดปริมาณ log ที่ไม่จำเป็น แต่ผู้โจมตีที่มุ่งเป้าจริงจะสแกนทุกพอร์ตและพบพอร์ตของคุณอยู่ดี การใช้การยืนยันตัวตนด้วย key เท่านั้นคือสิ่งที่ป้องกันการบุกรุกได้อย่างแท้จริง หากคุณเปลี่ยนพอร์ต ให้เปิดพอร์ตใหม่ใน firewall ก่อน แล้วจึงรัน sudo systemctl daemon-reload && sudo systemctl restart ssh.socket เนื่องจากบน Ubuntu 24.04 ตัว socket เป็นผู้ถือครอง listener การสั่ง reload ปกติจะทำให้ sshd ยังคงทำงานบนพอร์ต 22 เดิม

ฉันจำเป็นต้องใช้ Fail2ban หากใช้ SSH keys หรือไม่?

เป็นทางเลือกแต่ยังมีประโยชน์ ในกรณีที่ใช้การยืนยันตัวตนด้วย key เท่านั้น การเดารหัสผ่านจะไม่สำเร็จ ดังนั้น Fail2ban จึงไม่ใช่สิ่งที่ป้องกันผู้โจมตี แต่ Fail2ban จะช่วยจำกัดอัตราการพยายามล็อกอินที่ล้มเหลวซ้ำๆ จากที่อยู่เดียว ซึ่งช่วยลดสัญญาณรบกวนจาก scanner ใน log และขับไล่ผู้ที่พยายามบุกรุกซ้ำๆ ออกไปได้เร็วขึ้น อย่างไรก็ตาม การโจมตีแบบช้าๆ และกระจายแหล่งที่มามักจะอยู่ต่ำกว่าเกณฑ์การแบนของโปรแกรม ควรใช้งานร่วมกับการยืนยันตัวตนด้วย key และหากเป็นไปได้ควรเก็บ SSH ไว้หลัง VPN

ฉันจะกู้คืนระบบได้อย่างไรหากล็อกอิน SSH ไม่ได้?

ให้ใช้ web console ของผู้ให้บริการเซิร์ฟเวอร์ของคุณ ซึ่งเชื่อมต่อผ่าน serial หรือ VNC โดยไม่ต้องผ่าน SSH จากนั้นคุณสามารถล็อกอินเข้าไปแก้ไขไฟล์ drop-in ที่ sshd และ reload service ได้ นี่คือเหตุผลว่าทำไมคุณควรทดสอบการตั้งค่า SSH ใหม่ใน terminal ที่สองก่อนปิด session แรก และทำไมการยืนยันตัวตนด้วย key ควรใช้งานได้จริงก่อนที่คุณจะปิดการล็อกอินด้วยรหัสผ่าน