ใช้ Claude Code ช่วยดูแล Server ได้ไหม และควรระวังอะไรบ้าง

เวลามีปัญหาบน Server งานที่กินเวลามักเป็นการไล่อ่าน Logs ดู config แล้วค่อย ๆ ตัดสาเหตุที่ไม่เกี่ยวข้องออก ถ้ามี AI ช่วยอ่านข้อมูลพวกนี้และเสนอว่าควรตรวจอะไรต่อ ก็น่าจะช่วยเบาแรงได้พอสมควร

Claude Code ช่วยงานลักษณะนี้ได้ครับ โดยรันบนเครื่องของเราแล้วเรียกคำสั่งผ่าน SSH ไปยัง Server ที่เราดูแล แต่เมื่อคำสั่งไปรันบนเครื่องจริง การแก้ config, restart service หรือลบไฟล์ ก็มีผลกับระบบจริงตามไปด้วย

ผมจึงอยากให้เริ่มจากการกำหนดขอบเขตให้ชัดว่า AI จะใช้บัญชีไหน ตรวจอะไรได้บ้าง และต้องหยุดรอเราตรงไหน โดยเฉพาะก่อนเปลี่ยนแปลงระบบ

บทความนี้ใช้ตัวอย่างการเชื่อมต่อ Linux Server ผ่าน SSH และแบ่งสิ่งที่ควรเตรียมออกเป็นสี่เรื่องครับ

1. ใช้ SSH key แทนการส่ง Password ให้ Claude Code

ก่อนอื่น ผมไม่แนะนำให้พิมพ์ Password ของ Server ลงใน prompt หรือให้ Claude Code นำ Password ไปใส่ในคำสั่ง

เหตุผลคือ Claude Code มีการเก็บประวัติการสนทนาและผลลัพธ์จากเครื่องมือไว้ใน session transcript บนเครื่อง เอกสารระบุว่าข้อมูลเหล่านี้เก็บเป็น plaintext และถ้าคำสั่งแสดง credential ออกมา ค่านั้นก็ถูกเขียนลงใน transcript ได้ด้วย ดังนั้น Password ที่เราใส่ในแชตหรือปล่อยให้ปรากฏใน output อาจมีสำเนาค้างอยู่อีกจุดหนึ่ง

อีกอย่างคือ แม้เรารัน Claude Code บนเครื่องตัวเอง แต่ยังมีการส่งข้อมูลไปให้โมเดลประมวลผลผ่านเครือข่าย จึงควรระวังทั้ง Password, API key, token และข้อมูลผู้ใช้ที่อาจปนอยู่ใน Logs หรือ config ที่ให้ AI อ่าน

เตรียม SSH key ให้เรียบร้อยก่อนเริ่มงาน

SSH key pair ประกอบด้วยสองส่วน: public key ที่ติดตั้งไว้ฝั่ง Server และ private key ที่เก็บไว้ฝั่งเครื่องที่ใช้เชื่อมต่อ ตัว SSH client ใช้ key คู่นี้สำหรับยืนยันตัวตน เราจึงไม่จำเป็นต้องบอก Password หรือส่งเนื้อหา private key ให้ Claude Code

ถ้ายังไม่มี key แยกสำหรับงานนี้ สามารถสร้างเองใน Terminal ก่อนเริ่ม Claude Code ได้ เช่น

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_server_review

ตั้ง passphrase ให้ key แล้วเพิ่มเนื้อหาของไฟล์ id_ed25519_server_review.pub ต่อท้าย ~/.ssh/authorized_keys ของบัญชีปลายทาง โดยเก็บ key เดิมที่ยังใช้งานอยู่ไว้ ส่วนไฟล์ที่ไม่มี .pub คือ private key ให้เก็บไว้บนเครื่องของเรา

จากนั้นตั้งชื่อเครื่องไว้ใน ~/.ssh/config เพื่อให้คำสั่งอ่านง่ายขึ้น ตัวอย่างนี้สมมติว่ามีบัญชี server-review บนเครื่อง Staging อยู่แล้ว

Host staging-web
    HostName staging.example.com
    User server-review
    IdentityFile ~/.ssh/id_ed25519_server_review
    IdentitiesOnly yes

เปลี่ยน hostname และชื่อบัญชีให้ตรงกับเครื่องที่ใช้จริง โดย IdentityFile ระบุไฟล์ key และ IdentitiesOnly yes ให้ SSH ใช้ identity ที่ตั้งค่าไว้

เมื่อมี ssh-agent ทำงานอยู่แล้ว ให้โหลด key เข้า agent จาก Terminal ที่จะใช้เปิด Claude Code เช่น

ssh-add ~/.ssh/id_ed25519_server_review

กรอก passphrase ใน Terminal ด้วยตัวเอง คำสั่ง ssh-add จะเพิ่ม key เข้า agent ให้ SSH client ใช้ได้ โดย Claude Code ต้องทำงานใน environment ที่เข้าถึง agent ตัวเดียวกัน (SSH หา agent ผ่านตัวแปร SSH_AUTH_SOCK)

ผมชอบใส่ -t ให้ key หมดอายุใน agent เอง จะได้ไม่ค้างไว้ทั้งวันหลังทำงานเสร็จ

ssh-add -t 1h ~/.ssh/id_ed25519_server_review

เช็กว่าใน agent มี key อะไรอยู่บ้างด้วย ssh-add -l และถ้าเสร็จงานก่อนหมดเวลา ใช้ ssh-add -d ~/.ssh/id_ed25519_server_review เอาออกได้เลยครับ

อีกเรื่องที่ควรรู้คือ agent ไม่ส่ง private key ออกไปไหน แต่ process ไหนที่เข้าถึง SSH_AUTH_SOCK ได้ก็ขอให้ agent ใช้ key เซ็นยืนยันตัวตนได้ (รวมถึง Claude Code ด้วย) เพราะงั้นเรื่องสิทธิ์ของบัญชีปลายทางยังสำคัญอยู่

จากนั้นลองเชื่อมต่อด้วย ssh staging-web เอง ตรวจสอบ host key fingerprint กับข้อมูลที่เชื่อถือได้ และทดสอบคำสั่งด้านล่างให้ผ่านก่อนส่งงานให้ Claude Code

ssh -o BatchMode=yes staging-web 'hostname'

BatchMode=yes ปิดการถาม Password และการยืนยันแบบโต้ตอบ ถ้าเชื่อมต่อด้วยข้อมูลที่เตรียมไว้ไม่ได้ คำสั่งจะล้มเหลวให้เรากลับไปตรวจเอง ไม่ต้องให้ AI ขอ Password มาใส่แทน

อย่างไรก็ตาม SSH key ไม่ได้จำกัดสิทธิ์ของบัญชีปลายทาง ถ้าบัญชีนั้นแก้ไฟล์หรือลบข้อมูลได้ คำสั่งที่ Claude Code รันผ่านบัญชีนั้นก็ทำได้เหมือนกัน

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

2. ใช้หลัก Proof before modify ให้หาหลักฐานก่อนแก้

คำสั่งอย่าง “เว็บเข้าไม่ได้ ช่วยแก้ให้หน่อย” ขอบเขตกว้างมาก เราควรบอกเพิ่มว่าช่วงแรกต้องตรวจสอบอะไร และยังห้ามเปลี่ยนแปลงอะไรบ้าง

ผมใช้คำว่า Proof before modify เพื่อเรียกกติกานี้: ให้หาหลักฐาน อธิบายสาเหตุ และเสนอแผนก่อนแก้ไข คำนี้เป็นชื่อแนวทางที่ใช้ในบทความ ไม่ใช่ชื่อ permission mode ของ Claude Code

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

เตรียม Plan Mode ก่อนเริ่มตรวจ

Claude Code มี Plan Mode สำหรับสำรวจข้อมูลและเสนอแผนก่อนแก้ไข แต่โหมดนี้ไม่ได้เปลี่ยนบัญชี SSH ให้กลายเป็นบัญชีที่อ่านได้อย่างเดียว และ shell command ระหว่างวางแผนอาจผ่านการอนุมัติจากตัวตรวจอัตโนมัติได้ ถ้าใช้ Auto mode ได้และเปิด useAutoModeDuringPlan อยู่ (ค่าเริ่มต้นคือเปิดนะครับ)

ถ้าต้องการตรวจ shell command เองระหว่างวางแผน ให้ตั้งค่านี้เป็น false ใน .claude/settings.local.json ของโฟลเดอร์งาน โดยเพิ่มเข้าไปใน JSON เดิม ไม่เขียนทับการตั้งค่าอื่น

{
  "useAutoModeDuringPlan": false
}

สำหรับงานนี้ อย่าเปิดความสามารถ bypass ให้ session ทั้งผ่าน --dangerously-skip-permissions หรือ --allow-dangerously-skip-permissions เพราะแม้เพียงเปิดให้เลือกใช้ bypass ได้ ก็มีผลต่อการตรวจ shell command ใน Plan Mode

จากโฟลเดอร์งาน เปิด session ใน Plan Mode ได้ด้วยคำสั่ง

claude --permission-mode plan

ก่อนส่งงาน ให้เปิด /permissions ตรวจรายการที่เคยอนุญาตไว้ โดยเฉพาะกฎที่ครอบคลุมคำสั่งผ่าน SSH แบบกว้าง ๆ ซึ่งจะอธิบายต่อในหัวข้อ Manual mode การตั้งค่าฝั่ง Claude Code ยังต้องใช้ควบคู่กับสิทธิ์ของบัญชีบน Server ไม่ควรอาศัยข้อความ “read-only” ใน prompt อย่างเดียว

ตัวอย่าง prompt สำหรับตรวจหาสาเหตุ

จากนั้นกำหนดขอบเขตงานให้ชัด เช่น

ช่วยตรวจปัญหาเว็บตอบ 502 บน staging-web ผ่าน SSH

ช่วงนี้ให้ตรวจสอบแบบ read-only เท่านั้น
ก่อนรัน ให้บอกว่าจะตรวจอะไร ใช้คำสั่งไหน และข้อมูลนั้นช่วยตอบคำถามอะไร
ยืนยัน hostname และบัญชีที่เชื่อมต่อก่อนเริ่มตรวจ

ห้ามแก้ไฟล์ ติดตั้งหรืออัปเดต package ลบข้อมูล
restart/reload service เปลี่ยน firewall หรือแก้ข้อมูลในฐานข้อมูล

อ่านเฉพาะ Logs และ config ที่เกี่ยวข้อง
หลีกเลี่ยงการอ่านหรือแสดง Password, token, private key และข้อมูลผู้ใช้
ถ้าต้องอ่านไฟล์ที่อาจมีข้อมูลลับ ให้หยุดและเสนอวิธีเลือกข้อมูลก่อน

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

การอนุมัติให้อ่านข้อมูลไม่ถือเป็นการอนุมัติให้แก้ไข
หยุดรอผมตรวจแผนก่อน

ตัวอย่างเช่น ถ้าพบว่า Nginx ติดต่อ upstream ไม่ได้ นั่นเป็นข้อมูลให้ตรวจต่อว่าปลายทางคืออะไร มี process รับ connection อยู่หรือไม่ และมีการเปลี่ยน config มาก่อนหน้านั้นหรือเปล่า การเห็น error บรรทัดเดียวอาจยังไม่พอจะบอกได้ว่าควรแก้ตรงไหน

ผมอยากให้แยก “อาการที่พบ” ออกจาก “สาเหตุที่ยืนยันแล้ว” ให้ชัด เพราะการ restart แล้วเว็บกลับมาได้ ก็ยังไม่ได้อธิบายเสมอไปว่าปัญหาเกิดจากอะไร

ถ้าจะใช้กติกาเดิมบ่อย ๆ สามารถเก็บไว้ใน CLAUDE.md ของโฟลเดอร์งานได้ แต่ไฟล์นี้เป็นคำแนะนำที่โมเดลอ่าน ไม่ใช่กลไกบังคับสิทธิ์ของระบบ

3. ช่วงแก้ไข ใช้ Manual mode และตรวจคำสั่งก่อนอนุมัติ

เมื่ออ่านหลักฐานและเห็นด้วยกับแผนแล้ว ค่อยเปลี่ยนเข้าสู่ช่วงแก้ไข

สำหรับงาน Server ที่ต้องตรวจการเปลี่ยนแปลงเอง ผมแนะนำ Manual mode ถ้าออกจาก Plan Mode ให้เลือกตัวเลือกที่อนุมัติการแก้ไขด้วยตนเอง เช่น Yes, manually approve edits หรือใช้ Shift+Tab สลับโหมดแล้วตรวจชื่อโหมดบนหน้าจอก่อนดำเนินการ

ถ้าจะเปิด session ใหม่ใน Manual mode ตั้งแต่แรก ใช้คำสั่งนี้ได้ โดย default เป็นชื่อค่าการตั้งค่าของโหมด Manual

claude --permission-mode default

โหมดที่ชื่อคล้ายกันทำงานต่างกัน จึงควรตรวจให้แน่ใจว่าเลือกตรงกับที่ต้องการ

พฤติกรรมของแต่ละโหมดอ้างอิงจากเอกสาร Claude Code และอาจเปลี่ยนตามเวอร์ชัน

สำหรับขั้นตอนที่เราตั้งใจจะ review เอง จึงไม่ควรเลือก Auto, auto-accept edits หรือเปิดด้วย --dangerously-skip-permissions

ตรวจ permission ที่เคยอนุญาตไว้ด้วย

การเปลี่ยนเป็น Manual ไม่ได้แปลว่าจะถามใหม่ทุกคำสั่ง ให้เปิด

/permissions

แล้วดูว่ามี allow rule ที่กว้างเกินไปหรือไม่ เช่น Bash(ssh *) ซึ่งอาจครอบคลุมคำสั่งผ่าน SSH ได้หลายแบบ รวมถึงคำสั่งที่เปลี่ยนแปลงระบบด้วย เพราะ wildcard จับข้อความส่วนที่ตามมาได้

หลีกเลี่ยงการกดอนุญาตถาวรให้ ssh ทั้งชุด ถ้าเราต้องการตรวจคำสั่งปลายทางทีละครั้ง

ถ้าเปิด sandbox และใช้การอนุมัติ Bash อัตโนมัติอยู่ ให้เลือก Regular permissions ใน /sandbox หรือตั้ง sandbox.autoAllowBashIfSandboxed เป็น false เพื่อให้คำสั่งผ่านขั้นตอนขออนุญาตตามปกติ การตั้งค่านี้ยังคงใช้ร่วมกับ allow rules ที่มีอยู่ จึงต้องตรวจทั้งสองส่วน

Review ทั้ง Command และสิ่งที่จะเกิดขึ้น

เวลามีคำขออนุมัติ ผมจะดูมากกว่าแค่ว่าคำสั่งนั้น “ดูคุ้น ๆ” หรือไม่ อย่างน้อยควรตอบคำถามเหล่านี้ได้

• คำสั่งจะรันบนเครื่องไหน เป็น Staging หรือ Production และใช้บัญชีอะไร
• จะแก้ไฟล์ บริการ หรือข้อมูลส่วนไหน ตรงกับแผนที่อ่านไปหรือเปล่า
• มีการเขียนทับ ลบข้อมูล เปลี่ยน permission หรือหยุดบริการหรือไม่
• ถ้ามี script, pipe หรือคำสั่งหลายขั้นต่อกัน แต่ละขั้นทำอะไรบ้าง
• ถ้าไม่สำเร็จ จะตรวจอย่างไร และจะกลับไปใช้ค่าเดิมด้วยวิธีไหน

ตัวอย่างเช่น “แก้ config ให้ถูกต้อง” ยังไม่ละเอียดพอสำหรับอนุมัติ ควรเห็นว่าจะเปลี่ยนไฟล์ไหน ค่าเดิมเป็นอะไร ค่าใหม่เป็นอะไร และจะตรวจความถูกต้องก่อนนำไปใช้ได้อย่างไร

อนุมัติให้แก้ไฟล์ก็ไม่ได้แปลว่าอนุมัติให้ restart service หรือ deploy ต่อทันทีด้วย ถ้าสิ่งเหล่านั้นยังไม่ได้อยู่ในขอบเขตที่เราอ่านและตกลงไว้

ถ้ายังไม่เข้าใจ ให้หยุดก่อน

ไม่จำเป็นต้องกด Yes เพียงเพราะ Claude Code อธิบายมาดูมั่นใจครับ ถ้ายังไม่เข้าใจ ให้ปฏิเสธคำสั่งนั้นแล้วถามต่อ เช่น

หยุดก่อน ยังไม่อนุมัติคำสั่งนี้

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

ถ้ามี script ที่จะนำไปรัน ให้แสดงเนื้อหาเพื่อ review ก่อน
ยังไม่ต้องแก้ไขหรือรันคำสั่งเพิ่มเติม

ใน CLI กด Esc เพื่อขัดจังหวะการทำงานปัจจุบันได้ และถ้าอยู่หน้าขออนุมัติ Esc จะปฏิเสธ action นั้น ส่วน Ctrl+C ใช้ interrupt งานที่กำลังรันได้

แต่การกดหยุดไม่ได้ย้อนสิ่งที่ทำสำเร็จไปแล้ว และงานที่เริ่มบน Server ไปแล้วอาจยังทำงานต่อ จึงควรตรวจสถานะจริงก่อนสั่งซ้ำ

4. Claude Code ยังมีโอกาสผิดพลาดได้

ต่อให้เตรียม SSH key ใช้ Plan Mode และตรวจคำสั่งใน Manual แล้ว ก็ยังต้องเผื่อกรณีที่ AI เข้าใจระบบผิดครับ

สิ่งที่ผมจะระวังคือการตีความ Logs จากข้อมูลไม่ครบ เสนอ config ที่ไม่ตรงกับเวอร์ชันที่ติดตั้ง หรือแก้จน service กลับมาทำงานได้ แต่เผลอลดข้อจำกัดด้านความปลอดภัยลงไปด้วย เช่น เสนอให้ขยาย permission เพื่อให้อาการหาย โดยยังไม่ได้อธิบายว่าทำไมสิทธิ์เดิมจึงไม่พอ

อย่าใช้ความมั่นใจในคำอธิบายเป็นหลักฐานว่าคำสั่งถูกต้อง เอกสารด้านความปลอดภัยของ Claude Code เองก็ระบุให้ผู้ใช้ตรวจ code และคำสั่งก่อนอนุมัติ

เตรียมวิธีย้อนกลับก่อนเริ่มแก้

ก่อนเปลี่ยน config ควรมีสำเนาค่าเดิมและรู้ว่าจะนำกลับมาใช้อย่างไร ถ้าเกี่ยวกับฐานข้อมูล ต้องเตรียม backup และวิธีกู้คืนให้เหมาะกับฐานข้อมูลนั้น ส่วนการแก้ SSH, firewall หรือ network ควรมีช่องทางเข้าเครื่องสำรอง เผื่อการเปลี่ยนแปลงทำให้ connection หลุด

อย่าคิดว่ามี /rewind แล้วจะย้อน Server กลับได้ทั้งหมด ความสามารถ checkpoint ของ Claude Code มีขอบเขตอยู่ที่ไฟล์ที่ติดตามไว้ ไม่ใช่การย้อนสถานะของ service, database หรือคำสั่งที่รันผ่าน SSH ทั้งเครื่อง

สำหรับ Production ผมจะเพิ่มการทดสอบบน Staging และกำหนดช่วงเวลาที่รับผลกระทบได้ก่อนลงมือ โดยเฉพาะงานที่เกี่ยวกับข้อมูลหรือการเชื่อมต่อเข้าเครื่อง

ตรวจหลังแก้จากระบบจริง

หลังจบงาน ให้ตรวจทั้งอาการเดิมและผลกระทบข้างเคียง เช่น service ยังทำงานอยู่หรือไม่ request ที่เคยมีปัญหากลับมาใช้งานได้จริงไหม และมี error ใหม่ใน Logs หรือเปล่า

จากนั้นให้ Claude Code สรุปสิ่งที่ทำไปว่าเปลี่ยนไฟล์ไหน รันคำสั่งอะไร ผลการตรวจเป็นอย่างไร และยังมีอะไรที่ไม่ได้ยืนยัน เก็บข้อมูลนี้ไว้ใช้ตรวจย้อนหลังได้ โดยไม่ใส่ credential ลงในบันทึก

ถ้าเพิ่งเริ่มใช้ ผมแนะนำให้ลองกับ VM หรือ Server ใน Homelab ที่กู้คืนได้ก่อน เลือกงานเล็ก ๆ อย่างอ่าน Logs และอธิบาย config แล้วค่อยให้มันลงมือแก้เมื่อเราเข้าใจวิธีตรวจงานของมันมากขึ้น

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

แหล่งอ้างอิง

ตรวจสอบเอกสารเมื่อ 27 ตุลาคม 2026

1. Claude Code — Explore the .claude directory: Plaintext storage
2. Claude Code — Data usage
3. Ubuntu Server — OpenSSH server: SSH keys
4. OpenSSH — ssh_config, ssh-add และ ssh-agent
5. Claude Code — Choose a permission mode
6. Claude Code — Settings files and precedence
7. Claude Code — How Claude remembers your project
8. Claude Code — Configure permissions
9. Claude Code — Interactive mode
10. Claude Code — Security
11. Claude Code — Checkpointing
12. Claude Code — Configure the sandboxed Bash tool