KeyHelp Community

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum)


Server-Betriebssystem + Version
Debian 11.3 (64-bit)


Eingesetzte Server-Virtualisierung-Technologie
KVM


KeyHelp-Version + Build-Nummer
22.0 (Build 2393)


Problembeschreibung / Fehlermeldungen
Guten Tag,
wir haben gestern unseren ProxMox Server auf Version 7.1 geupdatet und sind im selben Zuge auf Debian 11 Gewechselt. Alles an sich kein Problem gewesen. Wir haben von der alten Keyhelp Installation das Backup Repository gesichert. Natürlich war auf diesem Repository ein Passwort, das von einem ehemaligen Kollegen unserer seit gesetzt wurde. Auf Grund von privaten Umständen ist es uns nicht mehr möglich, diesen zu Kontaktieren und das von ihm hinterlegte Passwort in unserem Passwort Manager scheint nicht korrekt zu sein. Gibt es eine Möglichkeit, dieses Passwort zu bekommen, damit wir an unser ~30GB Backup kommen? Natürlich ist uns jetzt auch bewusst, dass ein Backup eine schlechte Idee ist. Wird in Zukunft definitiv geändert (Jeder fängt mal klein an).

Über jede Hilfe bin ich wie immer sehr dankbar

Mit freundlichen Grüßen
Gimli

Erwartetes Ergebnis
Einspielen des Backups ohne Probleme

Tatsächliches Ergebnis
Verschlüsselte Dateien, die uns leider nix bringen

Schritte zur Reproduktion
Brute-Force des Passwortes (Ohne Erfolg)

Zusätzliche Informationen

Würde sagen , Lehrgeld gezahlt.
Datenverschlüsselung hat halt schon seinen Sinn, eben diesen das nicht jeder mal kurz um die Ecke kommen kann und wie er fröhlich ist die Daten wieder entschlüsselt.

Ohne PW wars das dann.

Davon ab bleibt der Aspekt, sollte es möglich sein das PW zu recovern, wer versichert das du auch berechtigt bist auf die Daten zuzugreifen ?!

Ist nicht böse gemeint, ich will dir nichts unterstellen.

Sehe das ganze nur von der Seite des Sicherheitsaspektes.

Habe ich mir schon irgendwie gedacht. Ein versuch war es aber wehrt mal hier nachzufragen.

Davon ab bleibt der Aspekt, sollte es möglich sein das PW zu recovern, wer versichert das du auch berechtigt bist auf die Daten zuzugreifen ?!

Das kann ich total verstehen . Hatte nur die Hoffnung, dass es da eventuell ein Workaround gibt. Wäre dann aber auch fragwürdig, wofür man dann verschlüsselt .

Wir versuchen es mal weiter und wenn es nix wird, dann hat man für die Zukunft gelernt.
Danke für deine schnelle Rückmeldung @OlliTheDarkness

Wäre dann aber auch fragwürdig, wofür man dann verschlüsselt .

Sinnlose Freizeitbeschäftig wäre nen Grund

Für verregnete Wochenenden

Prinzipiell ist es möglich, das Passwort für das Repo zu entschlüsseln (KeyHelp tut dies auch, immer wenn es darauf zugreifen muss).

Die zur Entschlüsselung notwendigen Daten hängen an einer Reihe von Server-Parametern des Host-Systems (sprich mit geklauten verschlüsseltem Password, kann man somit trotzdem nichts anfangen).

Mit root-Zugang zum alten System, auf dem das Passwort angelegt ist, könnte ich das PW entschlüsseln. Bei Interesse PM.

OlliTheDarkness wrote: ↑Fri 22. Apr 2022, 10:45 Davon ab bleibt der Aspekt, sollte es möglich sein das PW zu recovern, wer versichert das du auch berechtigt bist auf die Daten zuzugreifen ?!

Das ist natürlich ein Punkt. Ich würde jetzt als Legitimation den root-Zugriff auf das System als solches anerkennen.

Alexander wrote: ↑Fri 22. Apr 2022, 11:00 Das ist natürlich ein Punkt. Ich würde jetzt als Legitimation den root-Zugriff auf das System als solches anerkennen.

Aber das pw liegt doch im Klartext unter /backup-keyhelp ?
Ist das nicht gewollt?

Zum einen kommt es erstmal drauf an, neues Backup-System oder altes Backup-System

[Neues System] Dann sollte KeyHelp normalerweise alles was es während eines Backup-Laufs unter /backup-keyhelp/ an flüchtigen Daten anlegt wieder löschen (Ausser bei einem Debug-Lauf). Wenn man schnell ist, kann man es da natürlich auch einsehen, entsprechende Zugriffsrechte vorausgesetzt.

24unix wrote: ↑Fri 22. Apr 2022, 11:20

Alexander wrote: ↑Fri 22. Apr 2022, 11:00 Das ist natürlich ein Punkt. Ich würde jetzt als Legitimation den root-Zugriff auf das System als solches anerkennen.

Aber das pw liegt doch im Klartext unter /backup-keyhelp ?
Ist das nicht gewollt?

Verstehe den Zusammenhang mit der von dir zitierten Aussage gerade nicht . Wenn er mich per PM nach einem entschlüsseln des Passworts fragen sollte, dann würde ich die root-Zugangsdaten, die er mir ohnehin für so etwas schicken müsste als Legitimation ansehen, dass er berechtigt ist auf den Inhalt des Backups zuzugreifen.

Alexander wrote: ↑Fri 22. Apr 2022, 11:00 Prinzipiell ist es möglich, das Passwort für das Repo zu entschlüsseln (KeyHelp tut dies auch, immer wenn es darauf zugreifen muss).

Die zur Entschlüsselung notwendigen Daten hängen an einer Reihe von Server-Parametern des Host-Systems (sprich mit geklauten verschlüsseltem Password, kann man somit trotzdem nichts anfangen).

Mit root-Zugang zum alten System, auf dem das Passwort angelegt ist, könnte ich das PW entschlüsseln. Bei Interesse PM.

OlliTheDarkness wrote: ↑Fri 22. Apr 2022, 10:45 Davon ab bleibt der Aspekt, sollte es möglich sein das PW zu recovern, wer versichert das du auch berechtigt bist auf die Daten zuzugreifen ?!

Das ist natürlich ein Punkt. Ich würde jetzt als Legitimation den root-Zugriff auf das System als solches anerkennen.

Wenn das Alte System dafür benötigt wird, wird das sowieso etwas schwer. Wir haben leider nur diesen einen Server und haben ihn bezüglich des Proxmox Updates und dem Update auf Debian 11 einmal komplett platt gemacht und neu aufgesetzt. Die Zugriffe auf das Keyhelp und den Server sind komplett gleich geblieben.

Alexander wrote: ↑Fri 22. Apr 2022, 11:35 Zum einen kommt es erstmal drauf an, neues Backup-System oder altes Backup-System

[Neues System] Dann sollte KeyHelp normalerweise alles was es während eines Backup-Laufs unter /backup-keyhelp/ an flüchtigen Daten anlegt wieder löschen (Ausser bei einem Debug-Lauf). Wenn man schnell ist, kann man es da natürlich auch einsehen, entsprechende Zugriffsrechte vorausgesetzt.

Das liegt bei mir immer da.

Sind das Überreste von den Abstürzen?

Kann ich das Verzeichnisch löschen?

Okay, wenn nicht mal das verschlüsselte Passwort noch vorhanden ist, wirds dann in der Tat unmöglich .

@24unix, ja, du kannst komplett /backup-keyhelp/ löschen. Es wird dann wieder angelegt, wenn es gebraucht wird.

Unabhäng von der Frage der Passwörter: Ich finde gerade die Stelle nicht mehr wieder, aber hatten wir das nicht kürzlich erst, dass man ein Backup von Debian 10 nicht auf Debian 11 restoren sollte (oder war es andersrum?) Anders ausgedrückt: ist das Backup nicht so oder so nicht / nur schwer brauchbar.

mhagge wrote: ↑Fri 22. Apr 2022, 11:50 Unabhäng von der Frage der Passwörter: Ich finde gerade die Stelle nicht mehr wieder, aber hatten wir das nicht kürzlich erst, dass man ein Backup von Debian 10 nicht auf Debian 11 restoren sollte (oder war es andersrum?) Anders ausgedrückt: ist das Backup nicht so oder so nicht / nur schwer brauchbar.

Restic sagt doch, alle Backups mit der selben Major-Version bleiben kompatibel.

Die Inkompatibilität bezog sich auf die Datenbank-Tabelle "mysql". Hier nochmal ausführlicher erklärt. Alles andere kann man problemlos restoren.

viewtopic.php?p=34390#p34390

Ah, ok - mir schwirrte doch irgendsowas im Kopf herum. Ist hier im Prinzip aber ja auch egal, sollte ggf. höchstens ein Trost sein, dass es nicht nur an dem Passwort hängt