apt-ის განახლება NO_PUBKEY-ით ვარდება VPN-ის საცავის დამატების შემდეგ

NO_PUBKEY და არქმედი Release ფაილი ნდობის, და არა ქსელის ხარვეზია. გადაწყვიტეთ, დაამაგროთ მომწოდებლის გასაღები signed-by-ით თუ წაშალოთ წყარო.

თქვენი VPN მომწოდებლის apt წყარომ პაკეტების მმართველი გატეხა, და გამოსწორება გადაწყვეტილებაა, არა ბრძანება. 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; ეს არის წყობა, რომელსაც სახელმძღვანელო ადასტურებს, და ის, რომელიც განახლებას გადაურჩება.

დაკავშირებული სტატიები