วิธีจัดการ SSH key และการตั้งค่าความปลอดภัย

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

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

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

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

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

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

ssh-keygen -t ed25519 -C "laptop"

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

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

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

ข้อมูลจะประกอบด้วยหนึ่งบรรทัด ได้แก่ ประเภทของ key, ข้อมูล key และ comment ของคุณ ข้อมูลบรรทัดนี้คือสิ่งที่จะถูกนำไปใช้บน server ของคุณ

หนึ่งคีย์ต่อหนึ่งอุปกรณ์ ไม่ใช่หนึ่งคีย์ต่อหนึ่งเซิร์ฟเวอร์

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

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

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

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

การติดตั้ง public key บน server

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

ssh-copy-id matt@10.0.0.10

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

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

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 ต่อหนึ่งบรรทัด ซึ่งเป็นฐานข้อมูลการเข้าถึงทั้งหมด การเพิ่มอุปกรณ์ใหม่ทำได้โดยการเพิ่มบรรทัดใหม่ และการยกเลิกการเข้าถึงอุปกรณ์เดิมทำได้โดยการลบบรรทัดนั้นทิ้ง สำหรับ server ที่ติดตั้งใหม่ ขั้นตอนนี้ควรทำใน 10 นาทีแรกบน VPS ใหม่ ก่อนที่คุณจะปิดการใช้งาน password login

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

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

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

ใน image แบบ 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

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

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

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 บนเครื่องของคุณจะช่วยกำหนดชื่อย่อให้แต่ละ server และจดจำค่า options ต่างๆ ที่คุณต้องพิมพ์ซ้ำๆ ให้สร้างไฟล์นี้ด้วย permissions แบบ 600 และเพิ่ม block ของ Host สำหรับแต่ละ server ดังนี้:

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 ช่วยให้ไม่ต้องพิมพ์ชื่อ account และ IdentityFile ใช้สำหรับระบุ key ที่ต้องการใช้งาน

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

Passphrases และ ssh-agent

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

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

ssh-add ~/.ssh/id_ed25519

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

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

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

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

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

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

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

สิ่งที่ไม่ควรทำ

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

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

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

• ห้ามคัดลอก private key ลงใน chat, email หรือ ticket ข้อมูลที่ควรแชร์มีเพียง public key หรือไฟล์ .pub เท่านั้น

เมื่อคุณสามารถเข้าสู่ระบบด้วย key ได้อย่างเสถียรแล้ว ให้ดำเนินการขั้นต่อไปด้วยการปิดการใช้งาน password authentication เพื่อป้องกันไม่ให้การสุ่มรหัสผ่าน (guessing) ต่อ server ของคุณประสบความสำเร็จ คุณสามารถดูวิธีการตั้งค่าแบบสำเร็จรูปได้ที่ SSH hardening on a VPS

FAQ

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

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

ฉันควรใช้ SSH key ชุดเดียวกันกับทุก server หรือไม่?

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

.ssh directory และ authorized_keys ควรมี permission อย่างไร?

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

ฉันจะลบ SSH key ออกจาก server ได้อย่างไร?

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

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

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