คุม Linux server ด้วย AI ผ่าน SSH ให้ปลอดภัย ไม่เผลอพังระบบ

พอดีมีสมาชิกในกลุ่ม Claude Thailand ถามมาว่า เอา AI มาช่วย audit กับแก้ security ของ Linux server อย่างไร แล้วทำอย่างไรให้มันปลอดภัย ไม่เผลอพังระบบ ผมเลยขอนั่งเขียนวิธีที่ผมใช้จริงแบบเต็มทีเดียว ยาวหน่อยแต่ครบทุก flow

วิธีนี้แหละที่ผมใช้มาตั้งแต่ย้าย server จาก CentOS 7 มา Debian จนยกโดเมนเกือบร้อยโดเมนข้ามมาเสร็จภายในวันเดียว downtime น้อยที่สุดเท่าที่จะทำได้ ของจริงที่ทำด้วยวิธีนี้ผมเขียนเป็นซีรีส์ไว้แล้ว ลองดูได้ท้ายบทความ

ก่อนเข้าเรื่อง ขอเตือนเรื่องหนึ่งก่อนเลยเพราะสำคัญมาก

แล้วเข้าเรื่องกันเลย

1. เข้าใจก่อน — Claude มองเห็นเครื่องเรายังไง

สิ่งสำคัญที่สุดที่ต้องเข้าใจก่อนคือ Claude ไม่ได้ "เข้า" server ของเราตรง ๆ มันสั่งงานอยู่บนเครื่องเรา (Windows/Mac) เท่านั้น แล้วเครื่องเราต่างหากที่ยิงคำสั่งข้ามไป Linux server ผ่าน SSH อีกที เพราะงั้นเครื่องมือทั้งหมดต้องอยู่ "ฝั่งเรา"

ภาพรวมเส้นทางการทำงาน เหมือนกันทั้งฝั่ง Windows และ Mac/Linux ต่างแค่ "มือที่ยิง SSH":

โครงเดียวกันทั้งคู่ ต่างแค่ "มือที่ยิง SSH" — Windows ใช้ plink/pscp ของ PuTTY (เพราะ ssh ของ Windows ติด interactive ง่าย), Mac/Linux ใช้ ssh/scp native ได้เลย ความเสี่ยงกับหลักการทำงานหลังจากนั้นเหมือนกันหมด

จุดที่ต้องจำคือ Claude ทำได้แค่เท่าที่เครื่องเราทำได้ ถ้าเครื่องไม่มี plink มันก็ SSH ไม่ได้ ถ้า python เป็นตัวปลอม มันก็รัน script พลาด เพราะงั้น "การเตรียมเครื่อง" ก็คือการกำหนดขอบเขตความสามารถกับความปลอดภัยทั้งหมดนั่นเอง

บน Windows Claude มี 2 มือหลักคือ PowerShell (จัดการ Windows, git, npm) กับ Bash tool (Git Bash แบบ POSIX — คำสั่ง unix, plink, heredoc) สองตัวคนละไวยากรณ์ Bash ใช้ $VAR กับ forward slash, PowerShell ใช้ $env:VAR กับ backtick ที่ต้องระวังคือ Bash tool บน Windows มักกิน backslash ในพาธ C:\... เลยต้องใช้ forward slash C:/... หรือ prefix MSYS_NO_PATHCONV=1

2. สำหรับคนใช้ Mac/Linux — ข้ามอะไรได้บ้าง

ข่าวดีคือปัญหา tooling ส่วนใหญ่ในนี้เป็น "ปัญหาของ Windows" Mac/Linux ไม่เจอ ถ้าใช้ macOS หรือ Linux จะมี ssh/scp/python3/bash native อยู่แล้ว ไม่ต้องลง PuTTY ไม่มีปัญหา path backslash ไม่มีกับดัก Python ของ Store

ของที่ต่างกัน:

• SSH/SCP ใช้ ssh/scp native, host key อยู่ใน ~/.ssh/known_hosts, ใช้ ~/.ssh/config ตั้ง alias/port/key ได้สวยกว่า
• ส่ง password อัตโนมัติ ใช้ sshpass แต่ทางที่ดีกว่าคือ SSH key (ssh-copy-id)
• กัน interactive ค้าง ใช้ ssh -o BatchMode=yes -o StrictHostKeyChecking=accept-new
• Python ใช้ python3 ได้เลย

แต่ของที่ Mac/Linux ก็ยังต้องระวังเหมือนกันคือ หลักการความปลอดภัยทั้งหมด (ตั้งแต่ข้อ 6 ลงไป) ไม่มียกเว้นตาม OS และ secret บน macOS ระวัง iCloud/Time Machine sync โฟลเดอร์ที่มี secret ขึ้น cloud โดยไม่ตั้งใจ ตัว Claude ก็ยังรันบนเครื่องเรายิง SSH ข้ามไป server เหมือนกัน อันตรายจาก destructive script เท่ากัน

3. เครื่องมือที่ต้องเตรียม (เน้น Windows)

ชุดที่ผมใช้จริง แนะนำให้เตรียมตามนี้

• Anaconda (Python) — รัน script วิเคราะห์/parse JSON/สร้าง tool ที่ reuse ได้ เรียก python เต็มพาธเสมอ
• Node.js + npm — เครื่องมือ JS, Playwright (screenshot/บอท)
• PuTTY (plink + pscp) — SSH/SCP ที่เสถียรสำหรับ automation รับ password ผ่าน flag, pin hostkey ได้, ไม่ติด interactive prompt
• Git + Git Bash — เป็น runtime ของ Bash tool, version control, heredoc
• sshpass — ส่ง password ให้ ssh/scp กรณี host บางตัว reject key-auth

หลักการเลือกเครื่องมือ: เลือกตัวที่ "ไม่ถาม" เพราะ automation ห้ามมี interactive prompt (จะค้าง) นี่คือเหตุผลที่ใช้ plink ไม่ใช่ ssh ของ Windows · งาน API/integration ทำเป็น python tool อ่าน secret จากไฟล์แล้วเรียกซ้ำได้ ไม่ต้อง curl ใหม่ทุกครั้ง · pre-scan เครื่องเก็บไว้ครั้งเดียว เซสชันหลัง reuse ไม่ต้องไล่หา/ลงซ้ำ

4. ทำไม plink ดีกว่า ssh ของ Windows

จุดที่มือใหม่พลาดบ่อยที่สุดคือเลือกใช้ ssh ของ Windows แล้วงาน automation ค้างเอาดื้อ ๆ ผมเทียบให้เห็นชัด ๆ

รูปแบบคำสั่งจริงที่ใช้ (ค่าจริงผม mask ไว้):

MSYS_NO_PATHCONV=1 plink -ssh -batch -P <port> -pw '<pass>' \
  -hostkey 'SHA256:...' root@<server-ip> "bash -s" <<'EOF'
  echo "อยู่บน server แล้ว"
  nginx -t
EOF

-batch คือห้าม interactive (ค้างไม่ได้) · MSYS_NO_PATHCONV=1 กัน Git Bash แปลง /home/... เป็น C:/Program Files/Git/home/...

5. กับดัก Python ของ Windows

กับดักคลาสสิกคือ python เปล่า ๆ บน PATH อาจเป็น "Microsoft Store stub" พิมพ์ python แล้วเงียบหรือเด้ง Store แล้ว script จะรันพลาดแบบงง ๆ วิธีกันคือเรียก python ของ Anaconda เต็มพาธเสมอ

C:/Users/<user>/anaconda3/python.exe script.py
C:/Users/<user>/anaconda3/envs/<env>/python.exe ...

และในพาธ Bash ใช้ forward slash ถ้าใช้ C:\Users\... ใน Bash tool มันจะกิน backslash กลายเป็น command not found · ข้อดี conda คือแยก env ตามงานได้ไม่ตีกัน แต่ระวังเลือก env ผิดจะไม่มี lib ที่ต้องการ และ conda activate ใน script บางทีไม่ติด เรียกพาธ python ของ env ตรง ๆ ชัวร์กว่า

6. การเก็บความลับ

กฎทอง: Claude ไม่ควรถามรหัสผ่าน ให้อ่านจากไฟล์ และรหัสทั้งหมดอยู่ที่เดียว

• ไฟล์ secret เดียว เก็บ password/hostkey/port ต้อง gitignore ไม่หลุดขึ้น repo
• tool ที่อ่าน secret อ่าน token จากไฟล์แล้วห้าม print token ออกมา
• secret รายโดเมน/บริการ แยกไฟล์เก็บ

7. กฎเหล็กก่อนสั่งงานจริง

อันนี้คือหัวใจ ก่อนอื่นมีข้อ 0 ที่สำคัญที่สุด

ข้อ 0 — Research ข้อมูลปัจจุบัน เช็ค link ทุกอัน ทำ/แก้ skill ก่อนเริ่ม ห้ามทำงานจากความจำเก่าของ AI โดยเฉพาะเรื่องที่เปลี่ยนตามเวลา (IP range ของบอท/Cloudflare, CVE, syntax config, API endpoint, เวอร์ชัน tool) ก่อนลงมือต้อง

1. WebSearch ข้อมูลปัจจุบัน
2. กดเปิดอ่าน link ทุกอันด้วยตาตัวเองว่าเป็นแหล่งทางการ ทันสมัย ถูกต้องจริง ไม่ใช่ mirror เก่า อย่าอ้าง link โดยไม่กดเข้าไปดู
3. เก็บความรู้ที่ verify แล้วเป็น skill
4. ถ้า skill เดิมผิด/เก่า แก้ skill ก่อนแล้วค่อยลงมือ

แล้วไล่ตามนี้

• Read-only ก่อนเสมอ รอบแรกดูอย่างเดียว ห้ามแก้ระหว่างสำรวจ เก็บสถานะให้ครบก่อนตัดสินใจ (audit แล้วค่อย fix เป็นขั้นแยก)
• สร้าง .sh หรือ python tool ก่อนรัน อย่ายิง one-liner มั่ว ๆ ที่ review ยาก script ที่อ่านได้คือตรวจได้ + รันซ้ำได้ + rollback ได้
• Backup ก่อนแตะทุกครั้ง copy ไฟล์ที่จะแก้ไปโฟลเดอร์ลงวันที่ + เขียน RESTORE.md
• มี validation gate แก้ config ต้องเทสต์ก่อน reload — nginx -t, bash -n, php -l, visudo -c ถ้า fail ให้ auto-revert จาก backup
• Verify หลังแก้ เทสต์พฤติกรรมจริง (curl ดู status, csf -g, systemctl is-active) + เช็คว่าไซต์/ลูกค้ารายอื่นไม่กระทบ
• Destructive ทีละบรรทัด rm -rf, DROP, restart, csf -ra ส่งทีละคำสั่ง ดูผลก่อนค่อยบรรทัดถัดไป งานลบ apt ตัด -y ออกเพื่อ review รายการก่อน
• "ขอคำสั่ง" คือผมรันเอง ถ้าผมบอกว่า "ขอคำสั่ง" Claude ต้องพ่นคำสั่งเป็นข้อความให้ผมรันเอง ไม่ใช่ SSH รันให้ มันรันให้เองเฉพาะงาน read-only หรือผมสั่งชัดว่า "ทำเลย"

หลักคิดสรุปเป็นสายเดียว:

ทุกการแก้ที่กระทบ production เดินตามนี้ ยกเว้นงานเล็ก ๆ ที่ย้อนกลับง่ายและไม่มีผลข้างเคียง

8. หัวใจ: .sh ก่อน + Backup เสมอ

กฎที่ลดหายนะได้มากที่สุดคือ Backup ก่อนแตะ พร้อม RESTORE.md แพทเทิร์นที่ใช้จริงคือโฟลเดอร์ลงวันที่ + เก็บ "สถานะ" ไม่ใช่แค่ไฟล์

B=/root/<งาน>-backup-$(date +%F)
mkdir -p "$B" && chmod 700 "$B"
cp -a /etc/csf/csf.conf /etc/nginx/nginx-includes.conf "$B"/
iptables-save > "$B"/iptables.txt
ipset list -t > "$B"/ipset.txt
nginx -T > "$B"/nginx-full.txt
cat > "$B"/RESTORE.md <<'EOF'
ย้อนข้อ 1: csf -dr <ip>
ย้อนทั้งหมด: cp csf.conf /etc/csf/ ; csf -ra ; systemctl restart lfd
EOF

ทำไมต้องเก็บ "สถานะ" ด้วย เพราะ firewall/ipset/iptables เป็น state ที่ไม่ได้อยู่ในไฟล์ตรง ๆ ถ้าไม่ snapshot ไว้จะ rollback ไม่ครบ

Script + Validation Gate + Auto-revert:

F=/etc/nginx/nginx-includes.conf
cp "$F" "$F.bak-$(date +%F-%H%M)"
cat >> "$F" <<'EOF'
... config ใหม่ ...
EOF
if nginx -t 2>&1 | grep -q successful; then
    nginx -s reload && echo reloaded
else
    echo FAIL revert; cp "$F.bak-"* "$F"
fi

งานซ้ำ ๆ ทำเป็น python tool เก็บ source ใน workspace deploy ตัวจริงไป /usr/local/sbin/ tool ที่ดีคือ idempotent (รันซ้ำไม่พัง) + fail-safe (ดึงข้อมูลไม่ได้ใช้ cache เก่า) + เขียน log เช่นตัวที่ผมทำดึง IP ของ Googlebot/Bingbot จากแหล่งทางการมา auto-unban กันบอทโดน firewall แบนเอง SEO หลุด

9. วาง TODO ยังไงให้คุมงานได้

งานหลายขั้น โดยเฉพาะแก้ production ให้ Claude วาง TODO list ก่อน แล้วเดินทีละข้อ มี in_progress ทีละอันเท่านั้น จะได้เห็น plan + ความคืบหน้าตลอด ไม่หลงทาง เทมเพลตที่ใช้

• Backup config ทั้งหมดที่จะแตะ + RESTORE.md
• แก้จุด A มี validation gate
• แก้จุด B
• Verify รวม ทุกชั้น + เช็คไซต์อื่นไม่กระทบ
• งานเสี่ยง/ตัดสินใจยาก ทำขั้นสุดท้าย (เช่นเปิด/ปิด country-block)
• Persist (self-heal กัน DA/CustomBuild ลบ) + log
• Update memory + รายงานสรุป

เคล็ดคือสั่งว่า "วาง TODO แก้ทั้งหมด แล้ว backup เผื่อ restore เรียงเป็นขั้น ๆ" แล้วระบุข้อที่อยากให้ทำท้ายสุด Claude จะจัดลำดับให้

10. อันตราย & กับดักที่เจอจริง

• Bash กิน backslash — C:\... กลายเป็น command not found แก้โดยใช้ forward slash หรือ MSYS_NO_PATHCONV=1
• python เปล่า = Store stub — รันเงียบ/พลาด แก้โดยเรียก anaconda เต็มพาธ
• Test-NetConnection false-negative — บอกพอร์ตปิดทั้งที่เปิด ใช้ ping.exe/ssh.exe ตรง
• เทสต์ผิดปลายทาง — แก้ config แล้ว curl เข้า loopback เห็น error นึกว่าพัง ทั้งที่ vhost จริง listen ที่ public IP ต้องเทสต์ผ่าน IP จริง
• เปลี่ยน config แล้วยังเห็นของเก่า — opcache/cache ค้าง ต้องเข้าใจ revalidate / reload / clear cache
• secret หลุดใน log — ไม่ echo secret, mask, เขียนลงไฟล์ secret
• ไฟล์ขยะค้างบน server — mktemp + trap EXIT ลบทิ้ง อย่าฝัง Windows path ใน server-side script
• แก้แล้วโดน DA/CustomBuild ลบ — self-heal script + guard
• เหมารวมเกินไป — block bot ดันโดน Googlebot จด SEO หลุด scope แคบ host+path เฉพาะ, whitelist crawler, verify ทุก UA

11. เคสจริง: ไล่แก้ทั้งงานแบบปลอดภัย

ตัวอย่างจริง แก้ปัญหา "Googlebot โดน firewall แบน จด SEO หลุด" บน shared host

• Read-only audit ไล่ดู csf/lfd/BFM, modsec log 5 วัน, access log ทุกโดเมน, robots.txt, ipset เขียนรายงานไม่แก้อะไร
• Backup โฟลเดอร์ลงวันที่ (csf.*, nginx, iptables/ipset state) + RESTORE.md chmod 700
• วาง TODO 8 ขั้น ปลดแบน -> whitelist -> real_ip -> verify -> (ท้ายสุด) เอา country-block ออก -> memory
• แก้ทีละขั้น มี gate (nginx -t) + verify (csf -g, curl) ทุกขั้น
• ทำเป็น tool cron รายวัน ดึง IP บอททางการ + auto-unban + log แทน static list
• Persist + memory + รายงานผล verify ทุกชั้น

ผลคือทุกขั้นย้อนกลับได้ ตรวจสอบได้ และ Googlebot/Bing ไม่โดนแบนซ้ำอีกแบบอัตโนมัติ

12. Checklist สรุป

เตรียมเครื่อง (ครั้งเดียว): Anaconda เรียก python เต็มพาธ · Node+npm · PuTTY (plink/pscp) + รู้ port/hostkey · Git Bash, sshpass · ไฟล์ secret เดียว gitignore · pre-scan เครื่อง

ก่อนสั่งแก้ทุกครั้ง: ใช้ model context 1M เสมอ · Research + เปิดเช็ค link ทุกอัน · ทำ/แก้ skill ให้ถูกก่อน · Read-only audit ก่อน · สร้าง .sh/tool ไม่ยิงมั่ว · Backup + RESTORE.md · Validation gate (-t / -l / -n) · Verify หลังแก้ + เช็คไซต์อื่น · Destructive ทีละบรรทัด · "ขอคำสั่ง" คือผมรันเอง

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

ของจริงที่ผมใช้วิธีนี้ทำทั้งหมด ไล่ตั้งแต่เตรียม VM ยันย้ายโดเมนเสร็จ ผมเขียนเป็นซีรีส์ไว้แล้ว ลองดูได้

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