การอัปเดต apt ล้มเหลวด้วย NO_PUBKEY หลังจากเพิ่มที่เก็บ VPN

NO_PUBKEY และไฟล์ Release ที่หายไปคือความล้มเหลวของความเชื่อถือ ไม่ใช่ความผิดปกติของเครือข่าย ตัดสินใจว่าจะปักหมุดคีย์ของผู้ให้บริการด้วย signed-by หรือนำแหล่งที่มาออก

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

ขั้นแรก วางความล้มเหลวให้ถูกประเภท

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

เรียกใช้ sudo apt update เพียงลำดับเดียว แล้วอ่านส่วนท้าย โดยไม่สนใจผลลัพธ์ที่แคชไว้ด้านบน บรรทัดที่สำคัญระบุ /etc/apt/sources.list.d/ และบอกว่าต้องเปิดไฟล์ใด

หากความล้มเหลวเกิดหลังจากอุโมงค์ขึ้น ให้ทดสอบโดยปิดอุโมงค์ และให้ DNS แก้ผ่านตัวแก้ของระบบ แหล่งที่มาที่ทำงานได้โดยไม่มี VPN เป็นเรื่องของการกำหนดเส้นทางหรือการดักจับ และการจัดการคีย์ใด ๆ ก็ไม่สามารถแก้ได้

สามคำถามที่เลือกเส้นทาง

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

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

การตอบว่าไม่ในคำถามแรกจะจบการวิเคราะห์ การตอบว่าใช่ทั้งสามข้อนำไปสู่การซ่อมด้วย signed-by ซึ่งเป็นรูปแบบเดียวที่ทั้งทำงานได้และยังตรวจสอบได้ การผสมสองเส้นทางเข้าด้วยกัน คือเก็บแหล่งไว้แล้วฝืนให้ผ่าน เป็นตัวเลือกเดียวที่ควรตัดออกอย่างชัดเจน

ทำไม trusted=yes ดูเหมือนการซ่อมแต่ไม่ใช่

หน้าคู่มือ sources.list กล่าวตรง ๆ เกี่ยวกับเรื่องนี้ การตั้งค่าตัวเลือก Trusted เป็น yes บอกให้ apt ยอมรับแหล่งนั้นแม้จะล้มเหลวในการพิสูจน์ตัวตน ซึ่งปิด apt-secure สำหรับที่เก็บนั้น หน้าเอกสารสงวนไว้สำหรับบริบทภายในเครื่อง หากมีการใช้เลย

นี่ไม่ใช่เวอร์ชันที่แคบกว่าของการเชื่อถือผู้ให้บริการ มันลบคำถามที่ว่าใครลงนามในดัชนี ดังนั้นใครก็ตามที่ตอบแทนชื่อโฮสต์นั้นได้ก็สามารถส่งแพ็กเกจที่ติดตั้งในสิทธิ์ root ให้เครื่องของคุณได้

เส้นทางการซ่อม รับคีย์มา แล้วปักหมุดไว้

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

  1. อ่านบรรทัดที่ล้มเหลวเพื่อดู ID ของคีย์และชื่อไฟล์แหล่งที่มา
  2. ดาวน์โหลดคีย์แบบหุ้มเกราะ ASCII ของผู้ให้บริการ แล้วเรียกใช้ gpg --dearmor ไปยัง /etc/apt/keyrings/vendor-name.gpg.
  3. [signed-by=/etc/apt/keyrings/vendor-name.gpg] ลงในรายการในไฟล์ .list ของผู้ให้บริการรายนั้น
  4. เรียกใช้ sudo apt update และยืนยันว่าแหล่งนั้นดึงดัชนีได้ แทนที่จะพิมพ์คำเตือนลายเซ็นซ้ำ

ให้ความสำคัญกับ /usr/share/keyrings สำหรับคีย์ที่มาพร้อมแพ็กเกจ และ /etc/apt/keyrings สำหรับคีย์ที่คุณวางเอง การแบ่งนี้ไม่ใช่เรื่องเครื่องประดับ เพราะบอกผู้ดูแลคนต่อไปว่าคีย์ใดจะรอดจากการอัปเกรดแพ็กเกจ และคีย์ใดต้องใช้คน

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

เส้นทางการนำออก และทำไมข้อผิดพลาดอาจกลับมา

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

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt อ่านเฉพาะไฟล์ .list และ .sources จากไดเรกทอรีนั้น ดังนั้นสำเนา .save หรือ .distUpgrade จะถูกเพิกเฉยอยู่แล้ว แต่การลบมันทิ้งก็ยังกันไม่ให้ผู้อ่านในภายหลังกู้คืนกลับมาโดยไม่ตั้งใจ การนำแหล่งออกไม่ได้ถอนการติดตั้งใด ๆ และ apt อาจอธิบายแพ็กเกจ VPN ที่ติดตั้งไว้ว่าติดตั้งในเครื่องหรือไม่มีให้ใช้แล้ว ซึ่งเป็นข้อความสถานะของแพ็กเกจ ไม่ใช่การกลับมาของข้อผิดพลาดความเชื่อถือ

กรณีที่เกิดซ้ำคือคำแนะนำเก่าที่ติดตั้งคีย์ด้วย apt-key ลงในวงแหวนความเชื่อถือส่วนกลาง เส้นทางนั้นล้าสมัย และการอัปเกรดรุ่นอาจทำให้คีย์ถูกทิ้งหรือไม่ถูกสอบถามเลย ซึ่งเป็นเหตุผลที่ข้อผิดพลาดที่เงียบมาหนึ่งปีปรากฏในสัปดาห์ที่คุณอัปเกรด ตรวจสอบ /etc/apt/trusted.gpg.d/ แล้วย้ายการตัดสินใจเรื่องความเชื่อถือไปยังบรรทัดที่เก็บซึ่งเป็นที่ของมัน หากผู้ให้บริการยังพิมพ์คำแนะนำ apt-key อยู่ ก็ให้ใช้ signed-by ต่อไป เพราะเป็นรูปแบบที่คู่มือบันทึกไว้ และเป็นสิ่งที่รอดจากการอัปเกรด

บทความที่เกี่ยวข้อง