ยัง login SSH ด้วย "รหัสผ่าน" อยู่หรือเปล่า? บอตเดารหัสทั้งวัน — เปลี่ยนมาใช้ SSH key แล้วปิด password ซะ บอตหมดทาง 🛡️

"พี่อ๊อด ผมเห็น log มีคนพยายาม login ssh เดารหัสเป็นพันครั้งต่อวันเลย น่ากลัวมาก ผมควรทำยังไงดี"

มีน้องคนทำเว็บคนหนึ่งทักมาในไลน์ตอนใกล้เที่ยงคืน ส่งภาพหน้าจอ log มาให้ดูด้วย แล้วถามผมแบบนี้เลย

"พี่อ๊อด ผมเพิ่งลองเปิดดู log ของ VPS ตัวเอง แล้วผมขนลุกเลยครับ มันมีรายการ Failed password เต็มไปหมด ไล่เดา root บ้าง admin บ้าง user มั่วๆ บ้าง วันๆ นึงเป็นพันครั้ง ทั้งวันทั้งคืนไม่มีหยุดเลย IP ก็คนละที่กันทั่วโลก ผมตั้งรหัสไว้แล้วนะ คิดว่าน่าจะรอด แต่เห็นแบบนี้แล้วผมนอนไม่หลับเลยครับ ผมควรทำยังไงดี"

ผมอ่านแล้วยิ้มเลย เพราะคำถามนี้คือคำถามที่ผมอยากให้คนทำเว็บทุกคนถามตัวเองตั้งแต่วันแรกที่เช่า VPS — น้องคนนี้แค่ "บังเอิญไปเปิด log เจอ" ก็เลยเพิ่งตกใจ แต่ความจริงคือ เรื่องแบบนี้เกิดกับ VPS ทุกตัวบนโลกที่เปิดพอร์ต SSH ไว้ ไม่ใช่เพราะมีใครเจาะจงเล่นงานน้อง แต่เพราะมีบอตจำนวนมหาศาลวิ่งสแกนทั้งอินเทอร์เน็ตอยู่ตลอดเวลา เจอเครื่องไหนเปิดพอร์ต 22 ก็จะลองไล่เดารหัสใส่ไปเรื่อยๆ เป็นงานประจำของมัน

ผมเขียนโค้ด ทำเว็บมา 20 ปี ทำโฮสติ้งมา 11 ปี ดูแล VPS ให้ลูกค้าอยู่ราวๆ 600 เครื่อง — เรื่องบอตเดารหัส SSH นี่ผมเห็นมันยิงเข้ามาทุกวินาทีจริงๆ และจุดที่ผมอยากบอกน้องคนนั้น (และคุณที่กำลังอ่านอยู่) คือ — คุณไม่ต้องไปนั่งสู้กับบอตทีละตัว เพราะมีวิธีที่ทำให้บอตเดารหัส "หมดทาง" ไปเลย นั่นคือเลิกใช้รหัสผ่านในการ login SSH แล้วเปลี่ยนมาใช้สิ่งที่เรียกว่า SSH key แทน — แล้วพอใช้ key ได้แล้ว ก็ปิดการ login ด้วยรหัสผ่านไปเสียเลย

บทความนี้ผมจะอธิบายให้ครบว่า รหัสผ่านมันอ่อนตรงไหน · SSH key ทำงานยังไงถึงดีกว่า · ตั้ง key ทีละขั้นด้วยคำสั่งจริง · และปิด password auth ยังไงให้ปลอดภัยโดยไม่เผลอล็อกตัวเองหลุดจากเครื่อง (ข้อสุดท้ายนี่สำคัญมาก พลาดกันเยอะ)

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

ส่วนที่ 1 — รหัสผ่าน login SSH มันอ่อนตรงไหน (ทำไมบอตถึงชอบ)

ก่อนอื่นต้องเข้าใจว่า "การ login SSH ด้วยรหัสผ่าน" มันคือการที่ใครก็ตามที่รู้ username (เช่น root) แล้วลองพิมพ์รหัสเข้ามาเรื่อยๆ ถ้าพิมพ์ถูกก็เข้าได้เลย — ปัญหาคือคำว่า "ลองพิมพ์เรื่อยๆ" นี่แหละ

1) มันถูก brute-force ได้ (ไล่เดาทีละตัวจนเจอ) — บอตไม่ได้นั่งเดารหัสด้วยมือเหมือนคน มันยิงรหัสเข้ามาได้เป็นร้อยเป็นพันชุดต่อนาที ลองจากรหัสยอดฮิตก่อน (123456, admin, password, ชื่อบริษัท ฯลฯ) แล้วไล่ไปเรื่อยๆ ตามพจนานุกรมรหัสที่หลุดมาจากเว็บอื่น — นี่คือที่มาของ log "Failed password เป็นพันครั้ง" ที่น้องเห็น มันคือเสียงของบอตกำลังไล่เดาอยู่นั่นเอง ถ้าวันใดมันเดาถูก (หรือคุณตั้งรหัสง่ายเกินไป) มันก็เข้าได้ทันที

2) รหัสรั่ว/ใช้ซ้ำได้ — คนเราชอบใช้รหัสเดียวกันหลายที่ ถ้ารหัสที่คุณใช้กับ VPS ดันไปตรงกับรหัสที่เคยใช้สมัครเว็บอื่นที่ข้อมูลหลุด บอตก็เอารหัสนั้นมาลองกับเครื่องคุณได้เลย (เขาเรียกว่า credential stuffing) — แปลว่าต่อให้ log ดูเงียบ คุณก็ยังเสี่ยงถ้ารหัสคุณเคยรั่วจากที่อื่น

3) มันเป็น "ความลับที่ต้องส่งผ่าน" — ทุกครั้งที่ login รหัสคุณต้องเดินทางและถูกตรวจสอบ ยิ่งมีจุดให้พลาดมาก (พิมพ์ในที่ไม่ปลอดภัย, จดไว้, แชร์ให้ทีม) โอกาสรั่วก็มากตาม

หัวใจที่ผมอยากให้เห็นคือ — ตราบใดที่เครื่องคุณยังยอมรับ "การ login ด้วยรหัส" บอตก็มีช่องให้ลองเดาเสมอ คุณตั้งรหัสยากแค่ไหนก็เป็นแค่การ "ทำให้มันเดายากขึ้น" ไม่ใช่ "ปิดประตูมัน" — และนั่นคือเหตุผลที่เราจะเปลี่ยนเกมไปเลย ด้วย SSH key

ส่วนที่ 2 — SSH key ทำงานยังไง ทำไมถึงดีกว่ารหัสผ่านคนละเรื่อง

SSH key คือการ login โดยไม่ใช้รหัสผ่าน แต่ใช้สิ่งที่เรียกว่า "กุญแจคู่" (key pair) ซึ่งมี 2 ส่วนที่ทำงานด้วยกัน:

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

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

ทีนี้มาดูว่าทำไมมันถึงเหนือกว่ารหัสผ่านคนละเรื่อง:

• brute-force แทบเป็นไปไม่ได้ — รหัสผ่านที่คนตั้งมักยาวไม่กี่ตัว เดาได้ แต่ SSH key มันยาวและซับซ้อนระดับที่ ต่อให้บอตทั้งโลกช่วยกันเดาไปจนสิ้นจักรวาลก็ยังไม่เจอ — บอตที่ไล่ยิงพอร์ต 22 อยู่ทุกวัน เจอเครื่องที่ใช้ key มันก็ทำอะไรไม่ได้
• ไม่มี "รหัส" ให้รั่ว/ใช้ซ้ำ — คุณไม่ได้ตั้งรหัสที่อาจไปซ้ำกับเว็บอื่น เพราะตัวที่ใช้ยืนยันคือ private key ในเครื่องคุณ ไม่ใช่คำที่จำได้
• สะดวกกว่าด้วย — ข้อนี้คนไม่ค่อยรู้ พอตั้ง key เสร็จ คุณ ไม่ต้องพิมพ์รหัสทุกครั้ง ที่ login อีกต่อไป (ยิ่งถ้าใช้ ssh-agent จะยิ่งลื่น) ปลอดภัยขึ้นและสบายขึ้นพร้อมกัน — อันนี้คือเหตุผลที่ผมบอกว่ามัน "ทั้งปลอดภัยกว่าและสะดวกกว่า" ไม่ใช่ต้องแลกอย่างใดอย่างหนึ่ง

แล้วถ้ากลัวว่า "ถ้ามีคนขโมยเครื่องผมไป เขาก็ได้ private key ไปสิ" — ใช่ครับ เพราะงั้นเราจะ ตั้ง passphrase ครอบ private key อีกชั้น (เดี๋ยวอยู่ในขั้นตอน) แปลว่าต่อให้ไฟล์ private key หลุดไป เปิดใช้ไม่ได้ถ้าไม่รู้ passphrase — เป็นการล็อก 2 ชั้น (มีไฟล์กุญแจ + รู้รหัสปลดกุญแจ)

💡 หมายเหตุ: SSH key ที่เราพูดถึงนี้คือ "login เข้า server" — คนละเรื่องกับ SEC-41 เลิก FTP → SFTP ที่เป็นความปลอดภัยตอน "โอนไฟล์ขึ้นเว็บ" (ถึงแม้ SFTP จะวิ่งผ่าน SSH เหมือนกัน และใช้ SSH key ได้เหมือนกันก็ตาม) — ชิ้นนี้โฟกัสที่การเข้าไปคุมตัวเครื่อง

ส่วนที่ 3 — ตั้ง SSH key ทีละขั้น (คำสั่งจริง ทำตามได้เลย)

มาภาคปฏิบัติ ผมจะไล่ทีละขั้นแบบที่ลูกค้าทำตามได้จริง สมมติคุณใช้ Mac/Linux (หรือ Windows ที่มี PowerShell/WSL ก็คล้ายกัน):

ขั้น 1 — สร้างกุญแจคู่ในเครื่องคุณ

เปิด Terminal ในเครื่องของคุณ (ย้ำ: เครื่องคุณ ไม่ใช่บน server) แล้วพิมพ์:

ssh-keygen -t ed25519

(ถ้าระบบเก่ามากไม่รองรับ ed25519 ให้ใช้ ssh-keygen -t rsa -b 4096 แทน — ทั้งคู่ใช้ได้ดี แต่ ed25519 ทันสมัยและกระชับกว่า)

มันจะถามว่าจะเก็บไฟล์ที่ไหน — กด Enter ใช้ค่าเริ่มต้น (~/.ssh/id_ed25519) ได้เลย จากนั้นมันจะถาม passphrase — ตรงนี้ใส่ไปเถอะครับ อย่าเว้นว่าง นี่คือรหัสปลดกุญแจที่ผมพูดถึงในส่วนที่แล้ว ทำให้ private key ของคุณปลอดภัยขึ้นอีกชั้นถ้าไฟล์หลุด

เสร็จแล้วคุณจะได้ 2 ไฟล์ใน ~/.ssh/ คือ id_ed25519 (private — ห้ามให้ใครเด็ดขาด) กับ id_ed25519.pub (public — ตัวนี้แหละที่จะเอาขึ้น server)

ขั้น 2 — ส่ง public key ขึ้นไปวางบน server

วิธีที่ง่ายที่สุดคือใช้คำสั่ง ssh-copy-id (มันจะจัดการวาง key + ตั้ง permission ให้เรียบร้อย):

ssh-copy-id user@your-server-ip

มันจะให้ใส่รหัสผ่าน SSH ครั้งสุดท้าย (เพราะยังเปิด password อยู่) เพื่อยืนยันว่าคุณมีสิทธิ์ จากนั้นมันจะเอา public key ไปต่อท้ายไฟล์ ~/.ssh/authorized_keys บน server ให้อัตโนมัติ

ถ้าเครื่องไหนไม่มี ssh-copy-id ก็ทำมือได้ — login เข้า server ตามปกติ แล้วเอาเนื้อหาในไฟล์ id_ed25519.pub (ฝั่งเครื่องคุณ) ไปวางต่อท้ายไฟล์ ~/.ssh/authorized_keys บน server (1 key ต่อ 1 บรรทัด) — ถ้ายังไม่มีโฟลเดอร์/ไฟล์นี้ก็สร้างขึ้นมา

ขั้น 3 — ตั้ง permission ให้ถูก (ข้อนี้พลาดแล้ว key จะไม่ทำงาน)

SSH มันเข้มเรื่อง permission มาก ถ้าโฟลเดอร์/ไฟล์ key สิทธิ์เปิดกว้างเกินไป มันจะปฏิเสธไม่ยอมใช้ key เลย (เพื่อความปลอดภัย) — บน server ให้ตั้งแบบนี้:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

700 คือโฟลเดอร์ .ssh ให้เจ้าของเข้าได้คนเดียว · 600 คือไฟล์ authorized_keys ให้เจ้าของอ่าน/เขียนได้คนเดียว — ถ้าตั้ง key แล้ว login ด้วย key ไม่ผ่าน 80% ของเคสคือ permission ผิดตรงนี้แหละ (เรื่องสิทธิ์ไฟล์เป็นหัวข้อใหญ่ของหมวด access-permissions เลย)

ขั้น 4 — ทดสอบ login ด้วย key (อย่าเพิ่งปิดอะไรทั้งนั้น)

เปิด Terminal ใหม่ในเครื่องคุณ แล้วลอง login:

ssh user@your-server-ip

ถ้าตั้งทุกอย่างถูก มันจะ ไม่ถามรหัสผ่านของ server แล้ว (แต่จะถาม passphrase ของ key คุณแทน ซึ่งเป็นรหัสฝั่งคุณเอง) — ถ้าเข้าได้ด้วย key สำเร็จ แปลว่าพร้อมเข้าขั้นต่อไป ย้ำว่าต้องเข้าด้วย key ได้จริงก่อน ห้ามข้าม

ขั้น 5 (เสริมความสบาย) — ใช้ ssh-agent จะได้ไม่ต้องพิมพ์ passphrase ทุกครั้ง

พอตั้ง passphrase แล้วคุณอาจรำคาญว่าต้องพิมพ์ทุกครั้ง — ใช้ ssh-agent ช่วยจำ passphrase ไว้ในรอบการใช้งานได้ (เพิ่ม key เข้า agent ด้วย ssh-add) แล้วทั้ง session คุณจะ login ลื่นไม่ต้องพิมพ์ซ้ำ ได้ทั้งความปลอดภัยและความสบาย

ส่วนที่ 4 — ปิด password auth อย่างปลอดภัย (ไม่ล็อกตัวเอง!)

มาถึงขั้นที่ทรงพลังที่สุด และก็เป็นขั้นที่คนพลาดเยอะที่สุดด้วย — การปิดการ login ด้วยรหัสผ่าน พอปิดแล้ว เครื่องคุณจะยอมรับเฉพาะคนที่ถือ SSH key ที่ถูกต้องเท่านั้น = บอตที่ไล่เดารหัสอยู่ทุกวัน หมดทางทันที มันจะยิงรหัสเข้ามาเท่าไหร่ server ก็ไม่รับ เพราะมันไม่มี key (อันนี้ช่วยลด load จากบอตที่ยิง SSH รัวๆ ด้วย — โยงกับเรื่อง SRV-007 SSH เข้าไม่ได้ / โหลดจากบอท)

แต่ก่อนจะปิด ผมขอเตือนด้วยตัวหนาเลย เพราะนี่คือจุดที่คนทำเว็บล็อกตัวเองหลุดจากเครื่องตัวเองกันมานักต่อนัก:

⚠️ เปิด session SSH ที่ login อยู่ค้างไว้ และทดสอบ login ด้วย key ให้สำเร็จจริงก่อน "ปิด password auth" เสมอ — ถ้าคุณรีบปิด password แล้ว key ดันตั้งไม่สมบูรณ์ (เช่น permission ผิด, วาง public key ผิดไฟล์) คุณจะ login กลับเข้าเครื่องไม่ได้เลยทั้งสองทาง = ล็อกตัวเองหลุด ต้องพึ่ง console กู้กันวุ่นวาย (เคสนี้โผล่บ่อยใน SRV-007 SSH เข้าไม่ได้)

วิธีที่ปลอดภัยคือทำตามลำดับนี้:

1. เปิด Terminal หน้าต่างที่ 1 ค้างไว้ โดยที่ยัง login เข้า server อยู่ (เผื่อพลาดจะได้มีทางแก้กลับ)
2. ในหน้าต่างที่ 1 นั้น แก้ไฟล์ตั้งค่า SSH ของ server คือ /etc/ssh/sshd_config แล้วหาบรรทัด PasswordAuthentication เปลี่ยนเป็น:

PasswordAuthentication no

3. รีโหลด/รีสตาร์ตบริการ SSH ให้ค่าใหม่มีผล (เช่น systemctl restart sshd หรือ service ssh restart แล้วแต่ระบบ)
4. อย่าเพิ่งปิดหน้าต่างที่ 1 — เปิด Terminal หน้าต่างที่ 2 ใหม่ แล้วลอง login ด้วย key อีกครั้ง ถ้ายังเข้าได้ด้วย key = สำเร็จ ปลอดภัยแล้ว ค่อยปิดหน้าต่างที่ 1 ได้
5. ถ้าหน้าต่างที่ 2 เข้าไม่ได้ — ดีแล้วที่ยังมีหน้าต่างที่ 1 ค้างอยู่ ให้กลับไปแก้ค่าเป็น yes ชั่วคราว แล้วไปไล่ดูว่า key ตั้งตรงไหนพลาด

ขั้นการปิด password + จัดระเบียบ SSH ทั้งหมดนี้ (เปลี่ยนพอร์ต, ปิด root login, ฯลฯ) ผมจะลงรายละเอียดในชิ้นเรื่อง hardening SSH รวม (ปิด password ครบขั้น = SRV-016) และเรื่อง fail2ban ที่ช่วยแบนบอตที่ยิงรัว (SRV-017) แยกต่างหาก เพราะมันต่อยอดกันเป็นชุดความปลอดภัยพื้นฐานของ VPS — และคู่กับการ SRV-013 เลิกใช้ root ที่เป็นชุดความปลอดภัยพื้นฐานเดียวกัน

เรื่องที่ต้องดูแลต่อหลังใช้ key:

• แยก key ต่ออุปกรณ์ — อย่าก๊อปปี้ private key ตัวเดียวไปทุกเครื่อง ให้สร้าง key แยกของแต่ละเครื่อง (โน้ตบุ๊ก/พีซี/เครื่องที่ทำงาน) แล้ววาง public key ของทุกเครื่องไว้บน server — ข้อดีคือถ้าเครื่องไหนหาย คุณถอนเฉพาะ key ของเครื่องนั้นได้โดยไม่กระทบเครื่องอื่น
• ถอน key เมื่ออุปกรณ์หาย/ลูกทีมออก — แค่ลบบรรทัด public key ของเครื่อง/คนนั้นออกจากไฟล์ ~/.ssh/authorized_keys บน server เครื่องนั้นก็เข้าไม่ได้อีก ไม่ต้องไปไล่เปลี่ยนรหัสทั้งระบบเหมือนสมัยใช้รหัสผ่าน

(สิ่งที่ขาด) ที่อันตรายที่สุด: "เครื่องผมยังเปิด password ทิ้งไว้ — บอตเลยมีช่องเดารหัสตลอด"

ผมขอแยกออกมาย้ำเป็นหัวข้อ เพราะ 3M ของเรื่องนี้คือ (สิ่งที่ขาด) — ไม่ใช่ว่าคุณทำอะไรผิด แต่คือ "สิ่งที่ยังไม่มี" ทำให้เสี่ยงโดยไม่รู้ตัว

ความขาด ((สิ่งที่ขาด)) ของเรื่องนี้คือ "ยังไม่มี SSH key ใช้ และยังเปิดให้ login ด้วยรหัสผ่านอยู่" — ตราบใดที่ประตูยังรับรหัส บอตก็มีช่องไล่เดาได้ตลอด 24 ชั่วโมง คุณตั้งรหัสยากแค่ไหนก็เป็นแค่การ "ซื้อเวลา" ไม่ใช่ปิดประตู และที่อันตรายคือมันเงียบ — log อาจเต็มไปด้วย Failed password แต่ตราบใดที่ยังไม่มีตัวไหนเดาถูก คุณก็ยังเข้าใจว่า "ก็เข้าได้ปกติ ไม่เห็นเป็นไร" จนกระทั่งวันที่มันเดาถูก (หรือรหัสคุณรั่วจากที่อื่น) แล้วมันเข้ามาคุมเครื่องคุณ ซึ่งวันนั้นมักจะสายไปแล้ว

มาตรงนี้ผมขอรวบ 3M ของเรื่อง SSH key ให้เห็นเป็นภาพเดียว เอาไปเช็กเครื่องตัวเองได้ทันที:

🧭 3M ของเรื่องนี้

🔵 (ความเข้าใจผิด)

"ตั้งรหัสยากๆ ก็พอแล้ว" — ความจริงคือตราบใดที่ยังรับรหัส บอตก็ยังไล่เดาได้ รหัสยากแค่ซื้อเวลา · "log มี Failed เยอะ = กำลังโดนแฮก" — ความจริงคือเป็นบอตยิงมั่วทั่วโลกตามปกติ ยังไม่ได้เข้า แต่เป็นสัญญาณว่าควรปิด password ได้แล้ว · "SSH key ยุ่งยาก ไม่สะดวก" — ความจริงคือตั้งครั้งเดียว แล้วสะดวกกว่าเดิม (ไม่ต้องพิมพ์รหัสทุกครั้ง) และปลอดภัยกว่ามาก

🟠 (สิ่งที่ขาด)

ยังไม่มี SSH key ใช้ (พึ่งรหัสผ่านอย่างเดียว) · ยังไม่ได้ตั้ง PasswordAuthentication no (เครื่องยังรับรหัส บอตจึงมีช่องเดาตลอด) · ไม่มี passphrase ครอบ private key · ไม่มีการแยก key ต่ออุปกรณ์/ถอน key เมื่อเครื่องหาย · ไม่มีคนช่วยตั้งให้ถูก เลยปล่อยรหัสผ่านไว้แบบเดิม

🔴 (สิ่งที่พลาด)

ใช้รหัสผ่านง่าย/รหัสซ้ำกับเว็บอื่น (โดน brute-force / credential stuffing) · เผลอ ปิด password ก่อนทดสอบ login ด้วย key → ล็อกตัวเองหลุด · วาง public key ผิดไฟล์ หรือตั้ง permission ~/.ssh/authorized_keys ผิด → key ไม่ทำงาน · ก๊อป private key ตัวเดียวไปทุกเครื่อง (เครื่องหายแล้วถอนยาก)

สรุปเป็นตาราง: รหัสผ่าน vs SSH key (เซฟไว้เทียบได้เลย)

ถ้าจำได้บรรทัดเดียว ขอให้จำว่า "ตราบใดที่เครื่องยังรับรหัสผ่าน บอตก็มีช่องเดาตลอด — ใช้ key แล้วปิด password ซะ บอตถึงจะหมดทาง"

เล่าให้ฟังหนึ่งเคส (เพื่อให้เห็นว่า "เปิด password ทิ้งไว้" มันเสี่ยงยังไง)

ผมขอเล่าแบบรวมๆ จากเคสที่เจอ ไม่เจาะจงใคร

มีเอเจนซีเล็กๆ เจ้าหนึ่ง เช่า VPS ไว้วางเว็บลูกค้าหลายเว็บบนเครื่องเดียว ตั้ง root password ไว้ตอนเปิดเครื่องแล้วก็ใช้แบบนั้นมาตลอด เพราะ "มันก็เข้าได้ปกติ ไม่เคยมีปัญหา" — วันหนึ่งเว็บลูกค้าหลายเว็บบนเครื่องเดียวกันมีอาการแปลกๆ พร้อมกัน บางเว็บถูกฝังของแปลกปลอม บางเว็บโดนเอาไปทำเรื่องไม่ดี เขางงมากว่าเกิดอะไรขึ้น

พอไล่ดู log กันจริงๆ ปรากฏว่ามีบอตไล่เดารหัส root อยู่นานแล้ว และในที่สุดมันก็เดาถูก (รหัสที่ตั้งไว้ดันไปตรงกับชุดรหัสที่หลุดมาจากที่อื่น) พอเข้ามาได้มันก็คุมเครื่องได้ทั้งเครื่อง = ทุกเว็บบนนั้นโดนหมดในคราวเดียว เพราะมันเข้ามาที่ "ตัวเครื่อง" ไม่ใช่แค่เว็บใดเว็บหนึ่ง

ทางออกที่เราทำหลังจากนั้นคือ — กู้เครื่องให้สะอาด แล้ว ตั้ง SSH key ให้ทุกเครื่องของทีม → ทดสอบ login ด้วย key ให้ผ่าน → แล้วปิด PasswordAuthentication no หลังจากนั้นบอตที่เคยยิงรหัสรัวๆ ก็ทำอะไรไม่ได้อีก log ยังมีบอตมายิงเหมือนเดิม (มันยิงทั้งโลกอยู่แล้ว) แต่ประตูปิดสนิท มันเข้าไม่ได้

บทเรียนของเคสนี้คือสิ่งที่ผมย้ำมาตลอด: "เข้าได้ปกติ" ไม่ได้แปลว่า "ปลอดภัย" — และการปิดประตูบอตด้วย SSH key + ปิด password ไม่ใช่เรื่องของคนขี้กังวล แต่เป็นพื้นฐานที่คนเช่า VPS ทุกคนควรทำตั้งแต่วันแรก

แล้ว PhalconHost ช่วยเรื่องนี้ยังไง?

ผมเปิด PhalconHost เพราะตอนเป็นคนทำเว็บ ผมเจ็บกับการที่อยากตั้งค่าอะไรให้เครื่องปลอดภัยขึ้น แต่โทรหาโฮสต์แล้วได้ฝ่ายขายที่ตอบได้แค่ "ลองดูในคู่มือนะครับ" ทั้งที่เรื่องอย่างการตั้ง SSH key แล้วปิด password นี่ ถ้าทำพลาดลำดับนิดเดียวก็ล็อกตัวเองหลุดจากเครื่องได้ ผมเลยตั้งใจทำในสิ่งที่ผมเองอยากได้ตอนนั้น:

• คุณอ๊อดช่วยตั้ง SSH key + ปิด password ให้ถูกขั้นตอน — โดยไม่ล็อกตัวเอง — นี่คือจุดที่ผมอยากให้เห็นภาพ เวลาคุณอยากเลิกใช้รหัสผ่านแต่กลัวพลาดแล้วเข้าเครื่องไม่ได้ — คุณไม่ได้คุยกับบอท คุณทักมาคุยกับผม (dev 20 ปี) ผมช่วยไล่ให้ทีละขั้น: สร้าง key → วาง public key → ตั้ง permission ให้ถูก → ทดสอบ login ด้วย key ให้ได้ก่อน → แล้วค่อยปิด password (โดยเปิด session ค้างไว้กันล็อกตัวเอง) จนใช้ได้จริง ไม่ใช่ส่งลิงก์คู่มือภาษาอังกฤษให้ไปงมเอง
• เข้าใจเรื่อง log บอตยิง SSH — ถ้าคุณเปิด log มาเจอ Failed password เป็นพันแล้วใจไม่ดี ทักมาถามได้เลย ผมช่วยดูให้ว่าอันไหนคือบอตยิงปกติ (ที่ปิด password แล้วหมดทาง) อันไหนต้องระวังจริง และวางแผนปิดประตูให้เป็นชุด (SSH key → ปิด password → fail2ban กันบอตยิงรัว)
• เน้นว่าข้อมูลต้องไม่หาย — ผมใช้ server คุณภาพสูง (Dell + RAID-10) และมี QNAP NAS เก็บ backup แยก off-site
• auto backup ฟรีเป็นตาข่ายกันตก — ถึงจะปิดประตูเต็มที่แล้ว แต่ถ้าวันใดเครื่องมีปัญหา (ไม่ว่าจากสาเหตุไหน) เรามี auto backup รายวันให้กู้กลับ ทำให้คุณไม่เคว้ง — ผมไม่เชื่อในการขาย backup แยกแล้วเวลามีปัญหาค่อยบอกลูกค้าว่า "คุณไม่ได้ซื้อไว้" สำหรับผมมันคือความรับผิดชอบและความอุ่นใจที่ลูกค้าทุกคนควรได้

11 ปีที่ผ่านมา ลูกค้าที่ย้ายมาหาผมเกือบทุกคนพูดประโยคเดียวกันว่า "ทำไมไม่ได้เจอคุณตั้งนานแล้ว" — เพราะที่นี่ Dev ดูแล Dev เรื่องเทคนิคน่าปวดหัวอย่างการตั้ง SSH key แล้วปิด password ให้ถูกโดยไม่ล็อกตัวเอง ให้เราช่วยดูแล คุณเอาเวลาไปโฟกัสกับงานลูกค้าของคุณ

ปิดท้าย

log ที่เต็มไปด้วย "Failed password เป็นพันครั้งต่อวัน" ที่ทำให้คุณนอนไม่หลับ จริงๆ แล้วคือเสียงของบอตที่ไล่เดารหัส SSH ทั้งโลก — มันยิงเข้าทุกเครื่องที่เปิดพอร์ต 22 ไว้ ไม่ได้เจาะจงคุณ แต่ตราบใดที่เครื่องคุณยังรับ "การ login ด้วยรหัสผ่าน" มันก็มีช่องไล่เดาได้ตลอด

ทางแก้ที่ทำให้บอตหมดทางจริงๆ คือ: เปลี่ยนมาใช้ SSH key (ssh-keygen -t ed25519 + ตั้ง passphrase) → วาง public key บน server ด้วย ssh-copy-id → ตั้ง permission ให้ถูก (chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys) → ทดสอบ login ด้วย key ให้ได้ก่อน → แล้วค่อยปิด PasswordAuthentication no — และที่สำคัญที่สุด เปิด session ค้างไว้ + ทดสอบด้วย key ให้ผ่านก่อนปิด password เสมอ ไม่งั้นล็อกตัวเอง

ย้ำอีกครั้งว่าทั้งหมดนี้คือการ ปิดประตูเครื่องของคุณเองให้แน่น — ไม่ใช่การไปเดารหัสหรือยุ่งกับเครื่องใคร

ถ้าตอนนี้คุณเปิด log มาแล้วใจไม่ดีกับบอตที่ไล่เดารหัส หรืออยากเลิกใช้รหัสผ่านมาใช้ SSH key แต่กลัวพลาดแล้วล็อกตัวเองเข้าเครื่องไม่ได้ — ทักมาทางไลน์ บอกผมว่าใช้ VPS อะไรอยู่ได้เลยครับ เดี๋ยวผมช่วยไล่ตั้ง SSH key + ปิด password ให้ทีละขั้นจนใช้ได้จริง คุยกับ Dev ตัวจริง ไม่ใช่บอท 🙂