วิธีจำกัดสิทธิ์เข้าถึง Server ด้วย SSH Key แทนการใช้รหัสผ่านธรรมดา

การล็อกอินเข้าเซิร์ฟเวอร์ด้วยรหัสผ่านธรรมดาเพียงอย่างเดียว เริ่มกลายเป็นจุดเสี่ยงด้านความปลอดภัยที่ถูกโจมตีได้ง่ายขึ้นเรื่อยๆ ทั้งจากการเดารหัสผ่าน (Brute Force) และการรั่วไหลของข้อมูลผู้ใช้ การเปลี่ยนมาใช้การยืนยันตัวตนด้วย SSH Key จึงเป็นแนวทางที่ผู้ดูแลระบบและเจ้าของธุรกิจควรให้ความสำคัญ บทความนี้จะอธิบายแนวคิด วิธีปฏิบัติ และแนวทาง **ตั้งค่า SSH Key Linux** เพื่อจำกัดสิทธิ์เข้าถึงเซิร์ฟเวอร์ให้ปลอดภัยและเป็นระบบมากขึ้น

ทำความเข้าใจ SSH และ SSH Key ในภาพรวม

ก่อนลงมือ ตั้งค่า SSH Key Linux ควรเข้าใจหลักการพื้นฐานของ SSH และ SSH Key เพื่อสามารถออกแบบการควบคุมสิทธิ์เข้าถึงได้อย่างมั่นใจ

SSH คืออะไร

SSH (Secure Shell) คือโปรโตคอลสำหรับเชื่อมต่อเข้าไปยังเซิร์ฟเวอร์หรืออุปกรณ์ปลายทางอย่างปลอดภัย โดยเข้ารหัสข้อมูลตั้งแต่ต้นทางถึงปลายทาง ช่วยป้องกันการดักฟังข้อมูลระหว่างทาง เหมาะสำหรับการบริหารจัดการเซิร์ฟเวอร์ Linux / Unix และอุปกรณ์ Network ต่างๆ

SSH Key คืออะไร และปลอดภัยกว่ารหัสผ่านอย่างไร

SSH Key คือคู่กุญแจดิจิทัลที่ใช้ยืนยันตัวตนระหว่าง Client และ Server ประกอบด้วยสองส่วนหลัก:

• Private Key – เก็บไว้ที่เครื่องผู้ใช้ ห้ามส่งให้ผู้อื่นอย่างเด็ดขาด
• Public Key – นำไปใส่บนเซิร์ฟเวอร์เพื่ออนุญาตให้ผู้ที่ถือ Private Key เข้าถึงได้

ความปลอดภัยของ SSH Key เกิดจากการเข้ารหัสแบบอสมมาตร (Public Key Cryptography) ที่ยากต่อการเดาหรือถอดรหัสด้วยการ Brute Force เมื่อเทียบกับรหัสผ่านที่มักสั้นและซ้ำกันหลายระบบ

การเปลี่ยนจากรหัสผ่านธรรมดา มาใช้ SSH Key ไม่ได้แค่ “สะดวกขึ้น” แต่เป็นการยกระดับมาตรการควบคุมสิทธิ์เข้าถึงระบบให้ใกล้มาตรฐานสากรมากขึ้น เหมาะกับทั้งองค์กรและผู้ดูแลเซิร์ฟเวอร์ส่วนตัว

ข้อดีของการใช้ SSH Key แทนรหัสผ่าน

การวางแผน ตั้งค่า SSH Key Linux ให้ถูกต้อง ช่วยลดความเสี่ยงและเพิ่มความคล่องตัวในการบริหารจัดการเซิร์ฟเวอร์อย่างมีนัยสำคัญ

ลดความเสี่ยงจากการเดารหัสผ่านและการรั่วไหล

• ลดโอกาสการโจมตีแบบ Brute Force เนื่องจาก SSH Key มีความยาวและความซับซ้อนสูงมาก
• หลีกเลี่ยงปัญหารหัสผ่านซ้ำกันระหว่างหลายระบบ หากระบบหนึ่งหลุด ก็ไม่กระทบอีกระบบ
• เหมาะกับการใช้งานร่วมกับระบบจัดการรหัสผ่านหรือระบบ CI/CD ที่ต้องเชื่อมต่อเซิร์ฟเวอร์อัตโนมัติ

ควบคุมสิทธิ์ผู้ใช้งานได้ละเอียดมากขึ้น

• สามารถกำหนดได้ว่าบัญชีใดใช้ Public Key ใดล็อกอินได้บ้าง
• รองรับการเพิ่ม/ยกเลิก Key เป็นรายบุคคลได้ทันทีโดยไม่ต้องเปลี่ยนรหัสผ่านรวมทั้งระบบ
• ผูกกระบวนการอนุมัติ Key กับนโยบายภายในองค์กรได้ง่ายขึ้น เช่น Onboarding / Offboarding พนักงาน

รองรับการทำงานอัตโนมัติ (Automation)

• ระบบ Deployment / Backup / Monitoring สามารถใช้ SSH Key ในการเข้าถึงเซิร์ฟเวอร์แบบอัตโนมัติ
• ลดการเปิดเผยรหัสผ่านในสคริปต์หรือไฟล์คอนฟิก

โครงสร้างการทำงานของ SSH Key เมื่อใช้กับ Linux

สำหรับระบบปฏิบัติการ Linux โฟลเดอร์และไฟล์ที่เกี่ยวข้องกับการ ตั้งค่า SSH Key Linux ที่มักต้องใช้งาน ได้แก่:

• ~/.ssh/ – โฟลเดอร์หลักเก็บไฟล์ที่เกี่ยวข้องกับ SSH ของผู้ใช้แต่ละคน
• ~/.ssh/id_rsa หรือ ~/.ssh/id_ed25519 – ไฟล์ Private Key
• ~/.ssh/id_rsa.pub หรือ ~/.ssh/id_ed25519.pub – ไฟล์ Public Key
• ~/.ssh/authorized_keys – ไฟล์ที่เก็บ Public Key ซึ่งได้รับอนุญาตให้ล็อกอินเข้าสู่ Account นั้นบนเซิร์ฟเวอร์
• /etc/ssh/sshd_config – ไฟล์คอนฟิกของ SSH Server ใช้สำหรับกำหนดนโยบาย เช่น ปิดการล็อกอินด้วยรหัสผ่าน

ขั้นตอนตั้งค่า SSH Key บน Linux: จากศูนย์จนใช้งานได้จริง

ด้านล่างนี้คือขั้นตอนแบบ Step-by-step สำหรับการ ตั้งค่า SSH Key Linux เริ่มตั้งแต่สร้าง Key ที่เครื่องผู้ใช้จนถึงการปิดการล็อกอินด้วยรหัสผ่าน

1) สร้างคู่กุญแจ SSH Key ที่เครื่อง Client

ในเครื่อง Linux, macOS หรือ Windows (ผ่าน WSL หรือ Git Bash) สามารถสร้าง Key ได้ด้วยคำสั่ง:

• สำหรับ RSA (นิยมและรองรับแพร่หลาย):
  
  ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
• สำหรับ ED25519 (ทันสมัยและสั้นกว่า แต่ต้องรองรับทั้งสองฝั่ง):
  
  ssh-keygen -t ed25519 -C "your_email@example.com"

จากนั้นระบบจะถามตำแหน่งจัดเก็บไฟล์ (กด Enter เพื่อใช้ค่าเริ่มต้น) และถาม Passphrase เพื่อเพิ่มชั้นความปลอดภัยให้ Private Key การตั้ง Passphrase จะช่วยลดความเสี่ยงกรณีเครื่องผู้ใช้ถูกขโมยไฟล์ Key

2) ส่ง Public Key ไปยังเซิร์ฟเวอร์

เมื่อสร้าง Key แล้ว ไฟล์ Public Key มักอยู่ที่ ~/.ssh/id_rsa.pub หรือ ~/.ssh/id_ed25519.pub สามารถคัดลอกขึ้นเซิร์ฟเวอร์ได้หลายวิธี เช่น:

• ใช้คำสั่ง ssh-copy-id (แนะนำสำหรับ Linux/Unix)
  
  ssh-copy-id user@your-server-ip
• คัดลอกด้วยตนเอง
  • เปิดไฟล์ Public Key แล้วคัดลอกเนื้อหา
  • ล็อกอินเข้าเซิร์ฟเวอร์ด้วยรหัสผ่าน (ครั้งสุดท้ายก่อนเปลี่ยนระบบเป็น SSH Key)
  • สร้างไฟล์ ~/.ssh/authorized_keys (ถ้ายังไม่มี) แล้ววาง Public Key ลงไปหนึ่งบรรทัดต่อหนึ่ง Key
  • กำหนดสิทธิ์ไฟล์และโฟลเดอร์:
    
    chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

3) ทดสอบล็อกอินเข้าเซิร์ฟเวอร์ด้วย SSH Key

เมื่ออัปโหลด Public Key เสร็จ ลองล็อกอินด้วยคำสั่ง:

ssh user@your-server-ip

หากตั้ง Passphrase ไว้ ระบบจะถาม Passphrase ของ Key แทนรหัสผ่านของบัญชีบนเซิร์ฟเวอร์ หากเชื่อมต่อสำเร็จ แสดงว่า SSH Key พร้อมใช้งาน

4) ปรับแต่ง sshd_config เพื่อเพิ่มความปลอดภัย

เพื่อจำกัดสิทธิ์เข้าถึงให้ปลอดภัยมากขึ้น ควรปรับไฟล์ /etc/ssh/sshd_config โดยแนวทางพื้นฐานที่มักใช้งานมีดังนี้

• ปิดการล็อกอินด้วยรหัสผ่าน (หลังยืนยันว่า SSH Key ใช้งานได้จริง)
  
  แก้ไขหรือเพิ่มบรรทัด:
  
  PasswordAuthentication no
• บังคับใช้การยืนยันตัวตนด้วย Public Key
  
  ตรวจสอบให้แน่ใจว่ามีบรรทัด:
  
  PubkeyAuthentication yes
• จำกัด User ที่อนุญาตให้ SSH เข้าได้
  
  เพิ่มบรรทัด:
  
  AllowUsers user1 user2
  
  หรือใช้ AllowGroups กำหนดตามกลุ่มผู้ใช้

หลังปรับค่าแล้ว ให้รีสตาร์ทบริการ SSH:

sudo systemctl restart sshd หรือ sudo service ssh restart (ขึ้นกับดิสทริบิวชัน)

แนวทางปฏิบัติที่ดีในการบริหาร SSH Key บนเซิร์ฟเวอร์ Linux

การ ตั้งค่า SSH Key Linux ให้ปลอดภัยไม่ได้จบแค่การสร้าง Key และปิดรหัสผ่าน ยังควรมีแนวทางการดูแลระยะยาวเพื่อจำกัดสิทธิ์อย่างมีระบบ

การจัดการ Key ตามผู้ใช้ (Per-User Key Management)

• ให้แต่ละบุคคลสร้าง SSH Key ของตนเอง ไม่แชร์ Key ร่วมกัน
• ตั้งชื่อ Comment ใน Key ให้ระบุเจ้าของชัดเจน เช่น -C "name.surname@company"
• เก็บประวัติว่า Public Key ใดเป็นของใคร และเกี่ยวข้องกับ Account ไหนบนเซิร์ฟเวอร์

การเพิกถอนสิทธิ์เมื่อผู้ใช้เปลี่ยนหน้าที่หรือออกจากระบบ

• เมื่อต้องยกเลิกสิทธิ์ ให้ลบ Public Key นั้นออกจากไฟล์ authorized_keys ของบัญชีที่เกี่ยวข้อง
• กรณีองค์กร ควรกำหนดขั้นตอนมาตรฐานในกระบวนการ Offboarding พนักงาน
• พิจารณาเปลี่ยน Key สำหรับบริการอัตโนมัติเป็นระยะ (Key Rotation) เพื่อลดความเสี่ยงจากการรั่วไหลระยะยาว

การรักษาความปลอดภัยของ Private Key

• เก็บ Private Key ในเครื่องที่เชื่อถือได้ ไม่คัดลอกผ่านช่องทางที่ไม่ปลอดภัย
• ตั้ง Passphrase ให้กับ Private Key เพื่อเพิ่มชั้นป้องกัน
• สำรอง Key อย่างระมัดระวัง เช่น เก็บในที่เก็บเข้ารหัส หรือ Password Manager ที่น่าเชื่อถือ

ตัวอย่างสถานการณ์ใช้งานจริง: จากเซิร์ฟเวอร์ส่วนตัวถึงระบบ Production

การนำแนวคิด ตั้งค่า SSH Key Linux ไปใช้ สามารถปรับให้เหมาะกับหลายบริบท ไม่ว่าจะเป็นเว็บส่วนตัวหรือระบบสำคัญขององค์กร

กรณีเซิร์ฟเวอร์ส่วนตัวหรือ VPS ขนาดเล็ก

• สร้าง SSH Key หนึ่งคู่สำหรับเจ้าของเครื่อง
• เพิ่ม Public Key ลงในผู้ใช้หลักบนเซิร์ฟเวอร์ เช่น root หรือ deploy
• ปิด root login โดยตรง และใช้บัญชีปกติ + sudo แทน
• ปิดการล็อกอินด้วยรหัสผ่านหลังทดสอบการเชื่อมต่อผ่าน SSH Key เรียบร้อย

กรณีเซิร์ฟเวอร์องค์กรหรือระบบ Production

• กำหนดนโยบายมาตรฐานการสร้าง SSH Key (ชนิด ความยาว และการตั้ง Passphrase)
• ใช้โครงสร้างผู้ใช้และกลุ่ม (User/Group) เพื่อจำกัดเซิร์ฟเวอร์และบริการที่แต่ละคนเข้าถึงได้
• เชื่อมกระบวนการเพิ่ม/ลบ Key เข้ากับระบบจัดการบุคลากร (เช่น เมื่อเข้าทำงาน/ลาออก)
• พิจารณาใช้เครื่องมือจัดการ Configuration หรือระบบจัดการ Key ส่วนกลาง เพื่อลดข้อผิดพลาดจากการแก้ไขไฟล์แบบ Manual

ยิ่งระบบมีผู้เข้าถึงมากเท่าไร การจัดการ SSH Key อย่างเป็นระบบก็ยิ่งสำคัญ ไม่เพียงเพื่อความปลอดภัย แต่เพื่อให้ตรวจสอบย้อนหลังและบริหารสิทธิ์ได้ง่ายเมื่อเวลาผ่านไป

สรุปประเด็นสำคัญและแนวทางนำไปใช้จริง

การจำกัดสิทธิ์เข้าถึงเซิร์ฟเวอร์ด้วย SSH Key เป็นหนึ่งในขั้นตอนที่มีผลต่อความปลอดภัยโดยรวมอย่างชัดเจน เมื่อเข้าใจหลักการและขั้นตอน ตั้งค่า SSH Key Linux แล้ว สามารถนำไปปรับใช้ได้กับทั้งเซิร์ฟเวอร์ส่วนตัวและระบบขนาดใหญ่

📌 ประเด็นนำไปใช้ได้ทันที:

• เปลี่ยนจากการใช้รหัสผ่าน มาใช้ SSH Key เป็นมาตรฐานหลักในการล็อกอินเซิร์ฟเวอร์
• สร้าง SSH Key แยกตามผู้ใช้ทุกคน และผูกกับไฟล์ authorized_keys ตามบัญชีที่ได้รับสิทธิ์
• ทดสอบการเชื่อมต่อด้วย SSH Key ให้เรียบร้อย ก่อนปิดการล็อกอินด้วยรหัสผ่านในไฟล์ sshd_config
• กำหนดขั้นตอนเพิ่ม-ลบ Key ให้สอดคล้องกับการบริหารบุคลากรหรือลูกทีม เพื่อให้ควบคุมสิทธิ์ได้ตลอดอายุการใช้งาน
• ดูแลความปลอดภัยของ Private Key อย่างจริงจัง ตั้ง Passphrase และจัดเก็บในที่ที่น่าเชื่อถือ

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