วิธีจัดการ SSH keys อย่างปลอดภัยและถูกต้องตามมาตรฐาน

การทำงานของ SSH keys

SSH key คือชุดไฟล์คู่หนึ่ง ประกอบด้วย private key ซึ่งเก็บไว้ในอุปกรณ์ของคุณ และ public key ซึ่งคุณต้องคัดลอกไปยังเซิร์ฟเวอร์ทุกเครื่องที่ต้องการเข้าใช้งาน เมื่อคุณเชื่อมต่อ เซิร์ฟเวอร์จะใช้ public key ส่งโจทย์ท้าทาย (challenge) ที่มีเพียง private key ที่ตรงกันเท่านั้นจึงจะตอบได้ ตัว private key จะไม่ถูกส่งออกจากอุปกรณ์ของคุณ ดังนั้นจึงไม่มีข้อมูลลับเดินทางผ่านเครือข่าย และหากเซิร์ฟเวอร์ถูกบุกรุก ผู้โจมตีก็จะไม่ได้รับข้อมูลที่เป็นประโยชน์ไป นี่คือเหตุผลที่การใช้ key ปลอดภัยกว่ารหัสผ่าน การจัดการ SSH keys ให้ดีมีหัวใจสำคัญ 4 ประการ ได้แก่ การใช้ key หนึ่งชุดต่อหนึ่งอุปกรณ์, การตั้งค่าสิทธิ์ของไฟล์ให้ถูกต้องตามที่ sshd ต้องการ, การใช้ไฟล์ ~/.ssh/config เพื่อลดการพิมพ์ตัวเลือกซ้ำซาก และการรู้วิธีลบ key ออกทันทีเมื่อแล็ปท็อปสูญหาย

คู่มือนี้ครอบคลุมแนวทางปฏิบัติแต่ละข้อบน Ubuntu 24.04 แม้ว่าเนื้อหาส่วนใหญ่จะสามารถนำไปประยุกต์ใช้กับ Linux server อื่นๆ และ OpenSSH เวอร์ชันปัจจุบันได้ทั้งหมด

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

สร้างคีย์: ed25519 คือค่าเริ่มต้นที่เหมาะสม

บนคอมพิวเตอร์ของคุณเอง ไม่ใช่บนเซิร์ฟเวอร์ ให้รันคำสั่ง:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 ใช้สำหรับเลือกประเภทของคีย์ Ed25519 เป็นค่าเริ่มต้นที่ทันสมัย: คีย์มีขนาดสั้น ทำงานได้รวดเร็ว และรองรับโดย OpenSSH ทุกเวอร์ชันตั้งแต่ปี 2014 เป็นต้นมา ให้ใช้ ssh-keygen -t rsa -b 4096 เฉพาะในกรณีที่คุณจำเป็นต้องเชื่อมต่อกับอุปกรณ์รุ่นเก่าที่ไม่รองรับ ed25519 เท่านั้น -C "laptop" ใช้สำหรับกำหนดคำอธิบาย (comment) คำอธิบายนี้ไม่มีผลในเชิงรหัสลับ แต่จะช่วยให้คุณระบุคีย์นี้ได้เมื่อตรวจสอบไฟล์ authorized_keys บนเซิร์ฟเวอร์ในอีกสองปีข้างหน้า ดังนั้นควรตั้งชื่อตามอุปกรณ์ที่เก็บคีย์นี้ไว้

ssh-keygen จะถามตำแหน่งที่ต้องการบันทึกคีย์ ให้ยอมรับค่าเริ่มต้นคือ ~/.ssh/id_ed25519 จากนั้นระบบจะถามรหัสผ่าน (passphrase) ให้ตั้งรหัสผ่านไว้ โดยในส่วนของรหัสผ่านด้านล่างจะอธิบายว่าเหตุใดการตั้งรหัสผ่านจึงไม่สร้างความยุ่งยากในการใช้งานประจำวัน คุณจะได้ไฟล์สองไฟล์: ~/.ssh/id_ed25519 คือคีย์ส่วนตัว (private key) และ ~/.ssh/id_ed25519.pub คือคีย์สาธารณะ (public key) ให้ตรวจสอบคีย์สาธารณะด้วยคำสั่ง:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

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

หนึ่งกุญแจต่อหนึ่งอุปกรณ์ ไม่ใช่หนึ่งกุญแจต่อหนึ่งเซิร์ฟเวอร์

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

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

ด้วยรูปแบบหนึ่งกุญแจต่อหนึ่งอุปกรณ์ เมื่อแล็ปท็อปสูญหาย คุณเพียงแค่ลบข้อมูลออกหนึ่งบรรทัดต่อหนึ่งเซิร์ฟเวอร์ โดยการลบบรรทัดของแล็ปท็อปออกจากไฟล์ authorized_keys แล้วอุปกรณ์อื่นๆ ทั้งหมดก็จะยังคงใช้งานได้ตามปกติ ส่วน comment ที่คุณตั้งค่าไว้ด้วย -C คือสิ่งที่ช่วยให้คุณค้นหาบรรทัดนั้นได้อย่างง่ายดาย

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

การติดตั้ง public key บนเซิร์ฟเวอร์

วิธีที่ง่ายที่สุดคือการใช้ ssh-copy-id ซึ่งมาพร้อมกับ OpenSSH:

ssh-copy-id matt@10.0.0.10

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

ในกรณีที่การล็อกอินด้วยรหัสผ่านถูกปิดใช้งานไปแล้ว ssh-copy-id จะไม่สามารถเข้าถึงเซิร์ฟเวอร์ได้ คุณจึงต้องเพิ่มบรรทัดดังกล่าวด้วยตนเอง ให้ล็อกอินผ่าน session ที่ยังใช้งานได้อยู่ หรือผ่าน web console ของผู้ให้บริการ แล้วรันคำสั่งต่อไปนี้บนเซิร์ฟเวอร์:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

ให้วาง public key จริงของคุณลงในเครื่องหมายคำพูด โดยต้องเป็นบรรทัดเดียวที่สมบูรณ์จากไฟล์ id_ed25519.pub ไฟล์ authorized_keys จะเก็บ public key ไว้บรรทัดละหนึ่ง key และถือเป็นฐานข้อมูลการเข้าถึงทั้งหมด: การเพิ่มอุปกรณ์ใหม่คือการเพิ่มบรรทัดเข้าไป และการเพิกถอนสิทธิ์อุปกรณ์คือการลบบรรทัดนั้นออก สำหรับเซิร์ฟเวอร์ที่เพิ่งติดตั้งใหม่ ขั้นตอนนี้ควรทำใน 10 นาทีแรกบน VPS ใหม่ ก่อนที่คุณจะปิดการล็อกอินด้วยรหัสผ่าน

สิทธิ์การเข้าถึงที่ทำให้การล็อกอินด้วยคีย์ใช้งานไม่ได้

นี่เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การล็อกอินด้วยคีย์ล้มเหลว โดยฝั่งไคลเอนต์จะไม่แสดงข้อความแจ้งเตือนใดๆ sshd ทำงานโดยใช้ StrictModes yes เป็นค่าเริ่มต้นบน Ubuntu 24.04 ซึ่งหมายความว่ามันจะปฏิเสธการใช้ไฟล์ authorized_keys หากผู้ใช้อื่นสามารถแก้ไขไฟล์นั้นได้ หากไฟล์, ไดเรกทอรี ~/.ssh หรือโฮมไดเรกทอรีของคุณสามารถเขียนได้โดยบุคคลอื่นที่ไม่ใช่คุณ sshd จะเพิกเฉยต่อคีย์ของคุณและเปลี่ยนไปถามรหัสผ่านแทนโดยไม่มีคำอธิบายใดๆ ในฝั่งไคลเอนต์ (OpenSSH ของ Ubuntu ยอมรับกรณีพิเศษเพียงกรณีเดียวคือ ไฟล์ที่กลุ่มของผู้ใช้เองสามารถเขียนได้ โดยที่ไม่มีผู้อื่นอยู่ในกลุ่มนั้น อย่าพึ่งพาวิธีนี้ ให้ใช้โหมดสิทธิ์ตามด้านล่างนี้) สาเหตุจะปรากฏอยู่ใน log ของเซิร์ฟเวอร์เท่านั้น:

sudo grep 'Authentication refused' /var/log/auth.log

บนอิมเมจแบบ minimal ที่ไม่มี rsyslog จะไม่มีไฟล์ auth.log ข้อความเดียวกันนี้จะอยู่ใน journal แทน: sudo journalctl -u ssh | grep 'Authentication refused'

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

กฎที่ต้องจำคือ: 700 สำหรับไดเรกทอรี .ssh และ 600 สำหรับทุกสิ่งที่อยู่ภายใน ไดเรกทอรีเดียวกันนี้ใช้ตัวเลขเดียวกันบนคอมพิวเตอร์ของคุณด้วย เพราะฝั่งไคลเอนต์ก็มีการตรวจสอบเช่นกัน หาก private key สามารถอ่านได้โดยผู้ใช้อื่น ssh จะปฏิเสธคีย์นั้นทันที และในครั้งนี้จะมีข้อความแจ้งเตือนที่ชัดเจน:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 จะช่วยแก้ไขปัญหานี้ได้

~/.ssh/config: เลิกพิมพ์ออปชันซ้ำซ้อน

ไฟล์ ~/.ssh/config บนคอมพิวเตอร์ของคุณช่วยให้คุณตั้งชื่อย่อให้เซิร์ฟเวอร์แต่ละเครื่องและบันทึกออปชันที่คุณต้องพิมพ์บ่อยๆ ไว้ได้ สร้างไฟล์นี้ด้วยสิทธิ์ 600 และเพิ่มบล็อก Host สำหรับแต่ละเซิร์ฟเวอร์:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

ตอนนี้ ssh web1 จะมาแทนที่ ssh -p 22 matt@10.0.0.10 และชื่อย่อเดียวกันนี้ยังใช้งานได้ใน scp, rsync และ git เนื่องจากโปรแกรมทั้งหมดอ่านค่าจากไฟล์นี้ HostName คือที่อยู่จริงของเซิร์ฟเวอร์ User ช่วยให้คุณไม่ต้องพิมพ์ชื่อบัญชีผู้ใช้ และ IdentityFile เป็นการระบุว่าต้องใช้คีย์ใดในการเชื่อมต่อ

IdentitiesOnly yes มีความสำคัญและควรกล่าวถึงเป็นพิเศษ เพราะช่วยแก้ไขปัญหาที่สร้างความสับสนได้ เมื่อ SSH agent ของคุณเก็บคีย์ไว้หลายตัว ไคลเอนต์จะทยอยส่งคีย์เหล่านั้นไปให้เซิร์ฟเวอร์ทีละตัว และเซิร์ฟเวอร์จะนับการส่งคีย์แต่ละครั้งว่าเป็นความพยายามที่ล้มเหลว หากคุณโหลดคีย์ไว้จำนวนมาก คุณอาจเจอข้อผิดพลาด Received disconnect: Too many authentication failures ก่อนที่คีย์ที่ถูกต้องจะถูกนำไปใช้งานจริง IdentitiesOnly yes จะบังคับให้ไคลเอนต์ส่งเฉพาะคีย์ที่ระบุไว้ใน IdentityFile เท่านั้น จึงช่วยป้องกันไม่ให้เกิดความล้มเหลวดังกล่าวได้

Passphrases และ ssh-agent

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

เหตุผลที่การใช้ passphrase ไม่สร้างความยุ่งยากในทางปฏิบัติคือ ssh-agent โดย agent จะเก็บคีย์ที่ถอดรหัสแล้วไว้ในหน่วยความจำ ทำให้คุณพิมพ์ passphrase เพียงครั้งเดียวต่อหนึ่ง session การล็อกอิน และการเชื่อมต่อในครั้งถัดไปทั้งหมดจะเกิดขึ้นทันที Linux distribution บนเดสก์ท็อปส่วนใหญ่และ macOS ได้รัน agent ไว้ให้คุณแล้ว คุณสามารถโหลดคีย์เข้าสู่ agent ได้ด้วยคำสั่ง:

ssh-add ~/.ssh/id_ed25519

ssh-add -l ใช้สำหรับแสดงรายการคีย์ที่ agent ถือครองอยู่ในปัจจุบัน ข้อควรระวังคือ agent forwarding (ssh -A) จะอนุญาตให้เซิร์ฟเวอร์ปลายทางใช้ agent ของคุณเพื่อยืนยันตัวตนต่อไปยังที่อื่นในขณะที่คุณเชื่อมต่ออยู่ ดังนั้นควรเปิดใช้งานเฉพาะกับเซิร์ฟเวอร์ที่คุณเชื่อถือได้อย่างเต็มที่เท่านั้น และควรปิดไว้เป็นค่าเริ่มต้นเสมอ

การหมุนเวียนและการเพิกถอนกุญแจ: ขั้นตอนปฏิบัติเมื่อแล็ปท็อปสูญหาย

การเพิกถอน SSH key แบบปกติทำได้ง่ายเพียงแค่ลบบรรทัดที่เกี่ยวข้องออกจาก authorized_keys บนทุกเซิร์ฟเวอร์ที่มีกุญแจนั้นอยู่ ไม่จำเป็นต้องแจ้งหน่วยงานออกใบรับรอง (Certificate Authority) หรือรอวันหมดอายุ ทันทีที่ลบบรรทัดดังกล่าวออก การล็อกอินด้วยกุญแจนั้นจะล้มเหลวทันที

ให้ทดลองซ้อมขั้นตอนเหล่านี้ในขณะที่ยังไม่มีเหตุฉุกเฉิน เลือกเซิร์ฟเวอร์ขึ้นมาหนึ่งเครื่อง เปิดไฟล์ ~/.ssh/authorized_keys แล้วค้นหากุญแจดังกล่าวจากคอมเมนต์ท้ายบรรทัด จากนั้นลบบรรทัดนั้นออกด้วยโปรแกรมแก้ไขข้อความ หรือกรองออกด้วยคอมเมนต์:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

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

การหมุนเวียนกุญแจ (Rotation) คือการดำเนินการเดียวกันแต่สลับลำดับขั้นตอน: สร้างกุญแจใหม่บนอุปกรณ์ ติดตั้งด้วย ssh-copy-id ตรวจสอบว่ากุญแจใหม่ล็อกอินได้จริง แล้วจึงลบบรรทัดกุญแจเก่าออก ควรทำเช่นนี้เมื่อมีการเปลี่ยนมืออุปกรณ์ เมื่อกุญแจอาจถูกเปิดเผย หรือเมื่อมีคนออกจากทีม การทำด้วยตนเองบนเซิร์ฟเวอร์สองเครื่องนั้นไม่มีปัญหา แต่หากมีจำนวนยี่สิบเครื่องขึ้นไป งานนี้ควรใช้ระบบอัตโนมัติเข้ามาช่วย ซึ่งเนื้อหาใน การจัดการ Linux server หลายเครื่อง จะแสดงวิธีผลักดันสถานะ authorized_keys เดียวกันไปยังเซิร์ฟเวอร์ทั้งกลุ่ม

สิ่งที่ควรหลีกเลี่ยง

• ห้ามใช้ private key ชุดเดียวกันในทุกอุปกรณ์ เพราะจะทำให้ไม่สามารถเพิกถอนสิทธิ์ของอุปกรณ์ที่ถูกขโมยไปได้โดยไม่จำเป็นต้องเปลี่ยน key ใหม่ทั้งหมด

• ห้ามนำ private key ไป commit ลงใน git repository แม้จะเป็น repository ส่วนตัวก็ตาม เนื่องจากมีระบบสแกนอัตโนมัติที่คอยตรวจสอบ repository สาธารณะและพยายามนำ key ที่หลุดออกมาไปใช้งานภายในไม่กี่นาทีหลังจาก push และหากมีการเปลี่ยน repository ให้เป็นสาธารณะในภายหลัง ประวัติทั้งหมดจะถูกเปิดเผยทันที

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

• ห้ามคัดลอก private key ไปวางในแชท อีเมล หรือระบบจัดการตั๋ว (ticket) โดยเด็ดขาด มีเพียง public key หรือไฟล์ .pub เท่านั้นที่เป็นส่วนที่สามารถแบ่งปันได้

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

FAQ

SSH keys ทำงานอย่างไรโดยไม่ต้องส่งรหัสผ่าน

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

ฉันควรใช้ SSH key เดียวกันสำหรับทุกเซิร์ฟเวอร์หรือไม่

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

ไดเรกทอรี .ssh และไฟล์ authorized_keys ควรมี permission อย่างไร

ตั้งค่า 700 ให้กับ ~/.ssh และตั้งค่า 600 ให้กับ authorized_keys รวมถึงไฟล์ private key ทุกไฟล์ โดยต้องเป็นเจ้าของโดยบัญชีผู้ใช้งานนั้นๆ sshd จะทำงานด้วย StrictModes yes เป็นค่าเริ่มต้น ดังนั้นหากไฟล์หรือโฮมไดเรกทอรีอนุญาตให้ผู้อื่นเขียนได้ sshd จะเพิกเฉยต่อ key ของคุณโดยไม่แจ้งเตือน และร่องรอยเดียวที่พบคือ Authentication refused: bad ownership or modes ใน auth log หรือ journal ของเซิร์ฟเวอร์

ฉันจะลบ SSH key ออกจากเซิร์ฟเวอร์ได้อย่างไร

ให้ลบบรรทัดของ key นั้นออกจาก ~/.ssh/authorized_keys ในบัญชีที่ได้รับอนุญาตไว้ คุณสามารถค้นหาบรรทัดที่ถูกต้องได้จาก comment ซึ่งเป็นป้ายกำกับที่อยู่หลังข้อมูล key การล็อกอินใหม่ด้วย key นั้นจะล้มเหลวทันที แต่เซสชันที่เปิดอยู่แล้วจะยังคงใช้งานได้ ดังนั้นหากอุปกรณ์ถูกขโมย ให้ยุติเซสชันที่ยังเปิดอยู่ด้วย และทำซ้ำขั้นตอนเดิมบนทุกเซิร์ฟเวอร์ที่เคยคัดลอก key นี้ไปไว้

ฉันจำเป็นต้องตั้ง passphrase สำหรับ SSH key หรือไม่

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