Hyper Backup Hyper Backup & Hetzner Storage Box mit SSH Key Authentication

[Adama]

Dieser Post in "Erfahrung Hetzner mit Hyper Backup" hat bei mir mal wieder das Bedauern hervorgerufen, dass Hyper Backup nur mit Passwort geht. Ich hab auch hier im Forum nie was drüber gelesen.

Wobei, ist das wirklich so? Ein wenig das Internet befragt und gleich der erste Fund sagt, doch, das geht auch mit SSH Key Authentication. Wobei der Fund nur die Funktion für 6.2.4 und 7.1.1 verspricht, bei 7.2 geht es nicht. Doch auch dafür hab ich eine Lösung gefunden.

Ich hab das hier mal zusammengeschrieben...

Anmelden an der Syno per SSH und root-Zugriff erlangen (sudo su -)

Dann ein Schlüsselpaar generieren, ohne Passwort:

ssh-keygen -t ed25519

Der Public Key muss dann an eure Storage Box übertragen für den User, den ihr zum Sichern nehmt:

root@GalacticaNAS091:~# cat ~/.ssh/id_ed25519.pub | ssh -p23 uXXXXXX-sub1@uXXXXXX-sub1.your-storagebox.de install-ssh-key

(Ich hab einen Sub-Account fürs Sichern angelegt)

Das Ergebnis sollte in etwa so aussehen:

Key No. 1 (ssh-ed25519 root@GalacticaNAS091) was installed in RFC4716 format
Key No. 1 (ssh-ed25519 root@GalacticaNAS091) was installed in OpenSSH format

Dann die SSH Key Authentication testen:

ssh -p23 uXXXXXX-sub1@uXXXXXX-sub1.your-storagebox.de

Es sollte kein Passwort verlangt werden.

Für DSM 7.2 muss der Schlüssel auch in /var/packages/HyperBackup/home/.ssh liegen.

Das Verzeichnis .ssh anlegen:

cd /var/packages/HyperBackup/home
mkdir .ssh

Dann den Key dorthin kopieren:

cp /root/.ssh/id_ed25519 /var/packages/HyperBackup/home/.ssh/

Danach muss noch der User HyperBackup zum Owner gemacht werden:

chown -R HyperBackup: /volume1/@apphome/HyperBackup

Damit ist alles vorbereitet.

Ihr könnt dann einen Sicherungs-Job gemäss der Anleitung von Hetzner einrichten. Das Passwort für den User lasst ihr einfach leer. Damit meldet sich Hyper Backup mit der SSH Key Authentication an.



Bei bestehenden Jobs könnt ihr einfach das Passwort raus löschen. Um zu sehen, ob das wirklich geklappt hat, hab ich das Passwort des Sub-Accounts geändert, so dass der Weg nicht funktionieren kann. Die Verbindung steht weiterhin, ein Test-Backup lief einwandfrei.

Hinweis: Hyper Backup erwartet einen Standard-Key-Namen wie id_ed25519 oder id_rsa. Ihr könnt auch eigene Key-Namen verwenden, dann muss aber in den beiden Home-Verzeichnissen eine config-Datei für SSH angelegt werden. Allerdings dürfen in dieser nur die Identity-Files angegeben werden, Unterteilung in Host-Statements geht nicht.

Quellen:
https://community.synology.com/enu/forum/1/post/140590
https://www.reddit.com/r/synology/c..._over_ssh_with_public_key_in_hyper_backup_is/
https://docs.hetzner.com/storage/storage-box/backup-space-ssh-keys/

 

[luddi]

Oh das ist ja echt super!
Das werde ich auch bei meinen bestehenden Hyper Backups umstellen die via rsync auf Remotes sichern.

 

[luddi]

Also bei mir scheint das wohl nicht zu funktionieren.



Ich bekomme permanent folgedne Fehlermeldung.



Der Zugang via CLI funktioniert tadellos. Daran hatte ich kein Zweifel. Aber weshalb HyperBackup die Verbindung nicht aufbauen kann ist mir nicht klar.

 

[Adama]

@luddi Du hast die Keys an beiden Stellen? /root/.ssh und /var/packages/HyperBackup/home/.ssh/?

Und bei den Rechten für HyperBackup sollte das so aussehen:

root@GalacticaNAS091:/var/packages/HyperBackup/home# ls -la
total 0
drwx------ 1 HyperBackup HyperBackup   8 Sep  5 13:12 .
drwxr-xr-x 1 root        root        208 Sep  4 19:51 ..
drwx------ 1 HyperBackup HyperBackup  20 Sep  5 17:49 .ssh
root@GalacticaNAS091:/var/packages/HyperBackup/home# cd .ssh/
root@GalacticaNAS091:/var/packages/HyperBackup/home/.ssh# ls -la
total 4
drwx------ 1 HyperBackup HyperBackup  20 Sep  5 17:49 .
drwx------ 1 HyperBackup HyperBackup   8 Sep  5 13:12 ..
-rw------- 1 HyperBackup HyperBackup 411 Sep  5 17:48 id_ed25519

 

[luddi]

Hi @Adama ich habe deine Beschreibung befolgt. Jedoch habe ich intuitiverweise der Schlüsseldatei einen individuellen Namen vergeben wie ich es üblicherweise handhabe um die einzelnen Schlüssel im .ssh Verzeichnis von ihrer Zugehörigkeit auseinanderhalten zu können.

Den privaten Schlüssel legte ich wie von dir beschrieben unter /var/packages/HyperBackup/home/.ssh ab und passte den Eigentümer auf HyperBackup entsprechend an.
Nun bin ich davon ausgegangen, dass HyperBackup die Verbindung versucht mit den dort liegenden Schlüsseln herzustellen.
Jedoch wie bereits erwähnt konnte ich keine Verbindung zum Ziel aufbauen.
Somit überlegte ich mir einen entsprechenden Eintrag in der ssh config /root/.ssh/config anzulegen damit ein individueller Schlüssel für einen bestimmten Host anhand seiner domain gewählt wird.
Auch eine ssh config innerhalb /var/packages/HyperBackup/home/.ssh brachte nicht den erwünschten Erfolg eine Verbindung über HyperBackup aufbauen zu können.

Aber dann versuchte ich schlussendlich die Schlüsseldatei in ihren Standardnamen umzubenennen, bzw. eine Kopie unter dem Namen id_ed25519 anzulegen. Und schon klappte es auch mit der Verbindung zum entfernten Server über HyperBackup.

Die Beobachtung die ich weiterhin machen konnte ist, dass es zumindest auf meinem System nicht erforderlich ist den Schlüssel unter /var/packages/HyperBackup/home/.ssh abzulegen. Es reicht vollkommen aus den Schlüssel lediglich unter /root/.ssh verfügbar zu haben.

Wie in dem Screnshot zu sehen ist, dass zunächst die Schlüsseldatei unter dem individuellen Namen unter /root/.ssh abgelegt und das HyperBackup home Verezichnis leer ist.
Erst nach umbenennen (bzw. erstellen einer Kopie) in den Namen id_ed25519 brachte den Erfolg eine Verbindung aufbauen zu können.



Dann habe ich auch noch den Chatbot hierzu befragt:

Why is Synology hyperbackup searching for private key with the exact name "id_ed25519"?
How to configure that hyperbackup uses a specific private key file for authentication?

Die Antwort hierzu:



So schön wie sich das auch anfangs angehört hat, ist es in der Anwendung leider für mich nicht praktikabel.
Denn es ist mir in meinem Fall somit nicht möglich 3 Verschiedene Server via HyperBackup zu bedienen wenn alle einen individuellen Schlüssel verwenden sollen.
Ich habe nicht vor für alle Backupziele den gleichen Schlüssel zu verwenden.

 

[Adama]

@luddi Ok, das erklärt das. Ich benutze den Schlüssel nur für das externe Backup auf die Storage Box.

Für die Anmeldung an meine Backup-Syno nutze ich weiter die Anmeldung über mein AD. Das ist ja netz-intern.

Und zum Schlüsselort: Dann scheint das wieder so zu sein, wie bei DSM 6.2 (siehe ersten Link). Teste ich mal bei mir.

Können nicht mehrere Schlüssel in einer Schlüsseldatei liegen? Ich meine mich so erinnern zu können.

Edit: Der Key unter /root/.ssh scheint wirklich zu reichen.

Noch'n Edit: Ich hab grad mal die id_ed25519 in id_ed25519hetzner umbenannt. Wie zu erwarten war, Verbindung geht nicht. Dann hab ich unter ~/.shh eine config angelegt. Inhalt:

IdentityFile ~/.ssh/id_ed25519hetzner

Verbindung geht wieder. Aber dann failed das Backup, es muss dann das Key-File auch unter /var/packages/HyperBackup/home/.ssh als id_ed25519 stehen...

Die Edits nehmen überhand: Ich hab jetzt auch die Datei in /var/packages/HyperBackup/home/.ssh id_ed25519hetzner umbenennen können. Auch dort muss eine config stehen:

IdentityFile /var/packages/HyperBackup/home/.ssh/id_ed25519hetzner

Die config muss natürlich als Owner HyperBackup haben, sonst geht es nicht:

root@GalacticaNAS091:/var/packages/HyperBackup/home/.ssh# ls -la
total 8
drwx------ 1 HyperBackup HyperBackup  46 Sep  7 13:10 .
drwx------ 1 HyperBackup HyperBackup  16 Sep  7 12:57 ..
-rw------- 1 HyperBackup HyperBackup  67 Sep  7 13:05 config
-rw------- 1 HyperBackup HyperBackup 411 Sep  7 12:58 id_ed25519hetzner

Aber ich muss den Key definitiv an beiden Stellen haben, sonst schlägt das Backup fehl.

 

[luddi]

Danke für deinen Input und die Tests auf deiner Seite.

In deiner config stehen allein diese Einträge

IdentityFile ~/.ssh/id_ed25519hetzner

und in der anderen HyperBackup spezifischen config

IdentityFile /var/packages/HyperBackup/home/.ssh/id_ed25519hetzner

Aber in meiner /root/.ssh/config stehen ja eine Menge anderer Einträge mit Host und deren zugehörigen Identities.
Was passiert wenn hier ohne Angabe eine Hosts pauschal einfach IdentityFile ~/.ssh/id_ed25519hetzner steht?

Und wenn, dann bringt der Eintrag auch nur etwas um das default zu verbiegen von id_ed25519 auf einen eigenen Namen.
Aber wenn man nun mehrere individuelle Schlüssel für weitere Server verwenden möchte scheitert das Vorgehen weiterhin.

Es ist zwar schön dass es eine wohl eingeschränkte Möglichkeit gibt, welche aber in meinen Augen nicht praktikabel erscheint.

Synology müsste einfach die Möglichkeit auf eine Authentifizierung per Schlüssel in HyperBackup per GUI ermöglichen mit der expliziten Angabe des Schlüssels.
So wie man es auch von allen anderen Tools gewohnt ist.

 

[Adama]

Da hilft vielleicht der Blick ins man file:

               It is possible to have multiple identity files specified
               in configuration files; all these identities will be tried
               in sequence.  Multiple IdentityFile directives will add to
               the list of identities tried (this behaviour differs from
               that of other configuration directives).

https://www.man7.org/linux/man-pages/man5/ssh_config.5.html

Ich lese im man file nichts davon, dass IdentityFile eine host-Angabe erwartet. Wie trägst du die denn bei dir ein?

 

[Adama]

Ich hab mal einen zweiten Schlüssel angelegt und an die entsprechenden Stellen kopiert und in die configs eingefügt und das vor dem eigentlichen Hetzner-Schlüssel:

IdentityFile ~/.ssh/id_ed25519test
IdentityFile ~/.ssh/id_ed25519hetzner

IdentityFile /var/packages/HyperBackup/home/.ssh/id_ed25519test
IdentityFile /var/packages/HyperBackup/home/.ssh/id_ed25519hetzner

Anmeldung und Backup funktionieren.

Auch ein dritter Schlüssel in der config stört nicht...

 

[luddi]

Ich lese im man file nichts davon, dass IdentityFile eine host-Angabe erwartet. Wie trägst du die denn bei dir ein?

Ich hätte nie behauptet, dass IdentityFile eine host-Angabe erwartet.
Bei der Konfiguration erwartet eine Option auch keinen Host, sondern eher anders herum.

Das ist auch korrekt, dass eine Vielzahl an IdentityFiles in der Konfiguration zugelassen sind. Und es ist auch so in deinem Auszug aus dem Manual zu entnehmen.

[...] all these identities will be tried in sequence.

Man kann selbstverständlich alle IdentityFiles in der Konfiguration angeben.
Je nach Konfiguration ist dies aber nicht erforderlich, da der ssh agent ohnehin alle Schlüssel innerhalb ~/.ssh ausprobiert wenn dies nicht explizit durch IdentitiesOnly für alle oder den jeweiligen Host unterbunden wird.

Additionally, any identities represented by the authentication agent will be used for authentication unless IdentitiesOnly is set.

Hier mal ein Auszug aus meiner Konfiguration:

Host *
  IdentitiesOnly yes
  PreferredAuthentications publickey
  ServerAliveInterval 10
  ServerAliveCountMax 30

# GITHUB
Host github
  HostName github.com
  IdentityFile ~/.ssh/github_id_ed25519

# Codeberg
Host codeberg
  HostName codeberg.org
  IdentityFile ~/.ssh/codeberg_id_ed25519

# Hetzner
Host hetzner-sub1
  HostName uXXXXXX-sub1.your-storagebox.de
  User uXXXXXX-sub1
  Port 23
  IdentityFile ~/.ssh/uXXXXXX-sub1_at_hetzner_id_ed25519

Host hetzner-sub2
  HostName uXXXXXX-sub2.your-storagebox.de
  User uXXXXXX-sub2
  Port 23
  IdentityFile ~/.ssh/uXXXXXX-sub2_at_hetzner_id_ed25519

Da in meinem Fall die Option IdentitiesOnly yes für alle Hosts Host * gesetzt ist, werden nur die jeweiligen explizit angegeben Schlüssel für die jeweilige Verbindung verwendet.


Somit werden Schlüssel nur explizit verwendet und nicht durch Zufall implizit sukzessive durchprobiert.
Die Vorteile hiervon sind:

• Verhindert, dass unnötig viele Schlüssel an den Server gesendet werden (was zu "too many authentication failures" führen kann).
• Erhöht die Kontrolle und Sicherheit, da wirklich nur der gewünschte Schlüssel genutzt wird.

Ein anderer Vorteil durch die Konfiguration eines Hosts ist, dass man über die Kommandozeile beim Aufbau einer Verbindung nur den Alias Host angeben muss und nicht ständig den gesamten String mit Port, User und Hostname angeben muss um eine Verbindung aufzubauen.

In dem Beispiel meiner Konfiguration von oben würde man für die Verbindung mit dem Server anstelle von:

ssh -p23 -i ~/.ssh/uXXXXXX-sub2_at_hetzner_id_ed25519 uXXXXXX-sub2@uXXXXXX-sub2.your-storagebox.de

lediglich folgenden Befehl ausführen:

ssh hetzner-sub2

Da ich selbst bereits die Erfahrung machen musste zu viele Authentifizierungsanfragen an einen Server gesendet zu haben kam ab diesem Zeitpunkt für mich nur noch die explizite Angabe eines Schlüssels in Frage.
Implizite Willkür und Zufall versuche ich zu vermeiden und gebe lieber den Schlüssel explizit an welchen ich für den Zugang verwenden möchte.

Ein Vergleich zum Alltag wäre der eigene Schlüsselbund in der Hosentasche. Ich probiere doch auch nicht jedes mal alle Schlüssel mit der Annahme einer davon wird schon passen wenn ich vor der Haustür stehe. Ich nehme auch hier bewusst den richtigen Schlüssel der genau für die jeweilige Tür vorgesehen ist.
Okay außer in dem Fall ich bin nicht mehr meiner Sinne selbst und komme Betrunken nach Hause dann kann das schon mal nach diesem impliziten Prinzip laufen.

 

[Adama]

Das war mir schon klar, was du am Ende damit erreichen willst und was mehrere Schlüssel, die übertragen werden, für eine Auswirkung haben.

Irgendwas macht Synology mal wieder anders, sobald der Eintrag Host in der config steht, klappt das nicht mehr.

Ich hab übrigens festgestellt, der Key muss doch auch in /var/packages/HyperBackup/home/.ssh liegen. HyperBackup meldet sich zwar an, aber wenn das Backup gestartet wird, schlägt das fehl. Es sieht so aus, als ob Hyper Backup in dem Augenblick seinen eigenen User benutzt.

 

[luddi]

Zumindest sind wir uns einig. Ich hatte mich auch gefreut als ich dienen Beitrag gelesen habe. Nur dass seitens Synology mal wieder alles restriktiv und nicht sauber konfigurierbar ist scheidet dies für mich leider aus.

Wie ich schon erwähnt habe, müsste Synology diese Option in der HyperBackup GUI anbieten einen Schlüssel explizit angeben zu können.
Ich glaube ich erstelle gleich ein Feature Request

 

[Adama]

Naja, grundsätzlich geht es ja mit mehreren key-Files. Klang für mich am bei dir so, als ob es gar nicht gehen würde.

Ich kann deinen Ansatz verstehen, das eindeutig zu konfigurieren, ich bin normalerweise genauso gestrickt. In diesem Fall hab ich nur ein Ziel, also für mich unerheblich.

Stimmt, Feature-Request ist eine gute Idee.

 

[Ronny1978]

Ich finde die Idee mit den Keys sehr interessant, bin aber ehrlich und bei @luddi : Ich möchte hier nicht unbedingt per SSH eingreifen müssen. Es sollte dann schon über das UI gehen. Ein Feature Request ist eine gute Idee.

 

[Adama]

@Ronny1978 Dann haben wir schon mal drei...

Über das UI wäre das natürlich viel besser. Vermutlich muss man das sowieso bei jedem Update wieder neu einrichten, denke ich.

 

[luddi]

Ich habe meinen Wunsch via Synology Inquiry diesbezüglich bereits geäußert.

Vermutlich muss man das sowieso bei jedem Update wieder neu einrichten,

Das könnte sicher der Fall sein.

 

[Fink]

Danke für die Anleitung. Allerdings sehe ich aktuell keinen Vorteil SSH Keys in Hyperbackup nach Hetzner zu verwenden. Hetzner bietet zum aktuellen Zeitpunkt keine Möglichkeit an, die Authentifizierung via Passwort zu deaktivieren. Somit bleibt weiterhin die Möglich von Bruteforce. Da müssen wir aber dem fail2ban von Hetzner sowie der Verschlüsselung unseres Hyperbackups vertrauen.

 

[Acenoid]

Danke für diesen Beitrag, habe mich schon gefreut bis zu dem Post in dem ich lesen musste , dass die Paswort Anmeldung nicht deaktiviert werden kann Dann ist ja die zusätzliche Sicherheit durhc das Key File wieder zunichte gemacht worden.

Und ich hätte auch gerne den Zugriff auf die Hetzner box eingeschränkt, aber da schriebt Hetzner ja selbst, "zugriff von überall"

 

[plang.pl]

Wenn man eine VM bei Hetzner hat, kann man die StorageBox direkt daran virtuell anschließen und dann direkten Zugriff komplett deaktivieren. Auf der VM dann ein Site2Site WireGuard mit dem heimischen Router gebaut -> läuft.