felix-0815
Goto Top

GPG-Fehler bei apt-cacher-ng Nutzung

Guten Tag,

ich benötige Hilfe beim korrekten Einrichten von apt-cacher-ng.
Zunächst mein Setup: Ich habe in meinen Proberäumen einen ProxmoxServer aufgebaut. Dieser soll verschiedene Dienste (nas, Steuerung IOT) abdecken. Mithilfe von zita-njbridge möchte ich eine Audioverbindung zwischen den Räumen aufbauen. Das funktioniert so weit auch ganz ok.
Da ich vor Ort nur eine 2Mbit/s Leitung habe (ein Upgrade ist technisch/baulich nicht möglich) habe ich mir auf einem lxc Container unter Proxmox einen apt-cacher-ng eingerichtet.
Hier fangen leider die Schwierigkeiten an: Am ersten Tag funktioniert hier alles wie erwartet. Keinerlei Probleme. Spätestens nach einer Woche bekomme ich allerdings Fehler bezüglich ungültiger GPG-Signaturen. Allerdings nicht bei allen Paketquellen. Entferne ich den Weg über apt-cacher-ng verschwindet der Fehler. Dies betrifft nicht alle Repositories. Gerne davon betroffen ist "http://security.debian.org/debian-security bullseye-security"

Als Beispiel:
W: GPG-Fehler: http://security.debian.org/debian-security bullseye-security InRelease: Die folgende Signaturen waren ungültig: BADSIG 112695A0E562B32A Debian Security Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org>
E: Das Depot>>http://security.debian.org/debian-security bullseye-security InRelease<< ist nicht signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden sie in der Handbuchseite apt-secure(8)

Den apt-cacher-ng grundsätzlich zu deaktivieren ist keine Option. In anderen Foren wurde vorgeschlagen den Cache zu löschen, was ja auch nicht in meinem Sinne ist.
Die Aktualisierung standardmäßig zu aktivieren halte ich auch nicht für sinnvoll/sicher.

Unter Mx-Linux habe ich bereits die entsprechenden Signatur Dateien gelöscht und die MX-Werkzeuge neu erstellen lassen. Hier wird der exakt gleiche Signatur wieder geladen, die dann auch nicht funktioniert.

Mir scheint ich habe einen ganz wesentlich Punkt vergessen, da ich bei meiner Recherche entweder falsch gesucht oder sonst keiner das Problem hat/hatte. Auch in meinem Ausbildungsbetrieb konnte der "Fachmann" für Linux mir leider auch nicht helfen, da er sich bisher nicht mit apt-cacher-ng beschäftigt hat.

Im Vorfeld möchte ich mich für eventuell fehlende Angaben entschuldigen und reiche diese gerne nach.

Mit freundlichen Grüßen
Felix-0815

Content-ID: 6808600014

Url: https://administrator.de/contentid/6808600014

Ausgedruckt am: 21.11.2024 um 12:11 Uhr

6247018886
6247018886 18.04.2023 um 08:56:06 Uhr
Goto Top
Ist hier schön beschrieben, aufmerksam lesen und verstehen ...
https://wiki.debian.org/SecureApt

Cheers Briggs
Felix-0815
Felix-0815 18.04.2023 um 12:43:30 Uhr
Goto Top
Hi, danke für den Link, damit konnte ich mein Wissen auf jeden Fall vertiefen.
Ich bin mir aber unsicher ob dies meinen Anwendungsfall betrifft. Soweit ich es verstanden habe und auch überprüft habe sind die Signaturen mehrere Jahre gültig. Ich frage mich daher wo die Änderung der Signatur stattfindet. Mir fehlen die Signaturen ja nicht, sondern diese werden als ungültig eingestuft. Das aber nur wenn sie über den apt-cacher-ng kommen.
Da ich ja bereits die Signaturen erneuert habe und somit sicher sein kann das diese aktuell sind und auch funktionieren wenn ich den apt-cacher-ng umgehe, vermute ich mein Problem beim apt-cacher-ng.
Ich vermute jetzt mal das dieser die TrustChain unterbricht. Habe ich die Möglichkeit diesen in eine "private" TrustChain einzubauen? Kann das Remapping des apt-cacher-ng zu Problemen führen? Dies ist ja dafür zu vermeiden das gleiche Pakete aus unterschiedlichen Quellen vorgehalten werden müssen. Hier könnte es ja zu falschen Signaturen kommen?
Die einzig andere Möglichkeit mein Problem zu umschiffen wäre dann apt Befehle immer mit "--allow-unauthenticated" auszuführen? Das kommt mir nicht richtig vor.

Falls ich voll auf dem Schlauch stehe bitte ich das zu entschuldigen.

Grüße
Felix
Felix-0815
Felix-0815 18.04.2023 um 14:55:44 Uhr
Goto Top
Ich konnte noch ein bißchen testen und bin verwirrter als vorher:
Probleme macht ja das Repository http://security.debian.org/debian-security bullseye-security
Ich teste dies mit MX-Linux. Hierzu habe ich mir ein template unter Proxmox erstellt und eine Kopie davon erstellt. Die Kopie die eine Woche(mxOld) alt ist, hat den oben beschriebenen Fehler, allerdings jetzt auch ohne apt-cacher-ng.
In der Annahme das die Signatur Dateien unter /etc/apt/trusted.gpg.d/ gespeicher sind, habe ich einen weiteren Klon(mxNew) erstellt und diesen zunächst getestet. Hier läuft alles wie erwartet. Nun habe ich habe ich den gesamten apt Ordner von mxNew nach mxOld kopiert in der Erwartung das dies dann funktioniert. Dies ist nicht der Fall, ich bekomme den gleichen Fehler.
Jetzt bin ich endgültig überfragt, da ich ja funktionierende Signaturen kopiert habe.
kidu54
kidu54 28.12.2023 um 17:30:38 Uhr
Goto Top
Hallo Felix, hast Du inzwischen eine Lösung gefunden?
Ich habe auch apt-cacher-ng instlliert um Internet-Volumen zu sparen.
Hatte lange Zeit die Fehlermeldung bezüglich ungültiger Registrierungs-Schlüssel.
Per Zufall hab ich herausgefunden dass die Fehlermeldungen wegbleiben wenn ich
auf den Clients die selben Paketquellen verwende wie im Server-PC.
Habe dann darauf geachtet dass ich überall die selbe Distro drauf habe.
Denke dass diese Variante nur ein Work-Arround ist. Aber für meine priv. Zwecke
reicht es gut aus und ich spare etliche GB Internet-Volumen pro Monat.
Grüße aus Süddeutschland