Automatisiert regelmäßig Dateien per SSH/SFTP vom anderen Server holen

[peterhoffmann]

Hallo,

ich habe eine DS 215j (DSM 5.2-5644 U3) und wollte von einem FTP-Server Dateien auf die DS sichern und habe mir im Aufgabenplaner folgende Zeilen eingetragen:

Zeile 1 => cd //volume1/zielverzeichnis
Zeile 2 => wget -o wget-log.txt -nv -r -N --ftp-user=username --ftp-password=passwort ftp://123456.domain/verzeichnis

Das klappt wunderbar. Einmal pro Woche sichert er alles was er dort findet.

Nun wollte ich das gleiche mit SSH/SFTP von einem anderen Server machen.
Wget kann aber wohl kein SFTP.
Bei SCP und SFTP finde ich wiederum keine Möglichkeit das PW zu hinterlegen.

Wie bekomme ich es hin, dass die DS einmal wöchentlich eine Datei bzw. Verzeichnisinhalt von einem Server abholt, der per SSH/SFTP erreichbar ist?
Dinge wie RSYNC funktionieren nicht, ich will auch auf dem fremden Server nichts verändern, da dies ein produktives System ist und ich dort nichts versauen will.

Ich bin Linux-Laie. Ich verstehe ein wenig das Grundschema (Befehle und Optionen dazu), aber das war es dann schon.

Viele Grüße
Peter

 

[jahlives]

bei scp und/oder sftp geht das via sshpass. Allerdings gibt es afaik sshpass leider nicht auf der DS.
In dem Fall wäre es am Besten via PubKey auf den Server zuzugreifen. Hast du denn eine Möglichkeit auf dem Server (Datenquelle) deinen PubKey zu hinterlegen?

 

[peterhoffmann]

bei scp und/oder sftp geht das via sshpass. Allerdings gibt es afaik sshpass leider nicht auf der DS.

Kann ich sshpass gefahrlos nachinstallieren? Wenn ja, wie?

In dem Fall wäre es am Besten via PubKey auf den Server zuzugreifen. Hast du denn eine Möglichkeit auf dem Server (Datenquelle) deinen PubKey zu hinterlegen?

Ich habe auf dem Server Rootzugriff, aber dennoch Bauchschmerzen da ranzugehen.

Ich habe jetzt auf dem Server dort im Verzeichnis /root/.ssh die Datei authorized_key gefunden. Dort sind schon ein paar Einträge.
Wenn ich das richtig verstehe, muss ich mit der DS mit ssh-keygen ein Paar erzeugen (ohne Passwort?) und den Inhalt von mykey.pub dort reinkopieren.

 

[jahlives]

also wenn du root Zugriff hast und es darfst, dann würde ich den Weg via PubKey Auth empfehlen.
Falls du noch keinen Key hast kannst du folgendermassen einen generieren (auf deinem Client)

# Schlüsselpaar erstellen
ssh-keygen -t rsa -b 4096 -C 'deineEmailAdresse' -f /pfad/wo/der/key/hinsoll

dann kopierst du den Inhalt des öffentlichen Schlüssels in das .ssh/authorized_keys File des entsprechenden Users auf dem Server

# den Output des cat Kommandos kopieren
cat /pfad/wo/der/key/hinsoll/id_rsa.pub
# und auf dem Server einfügen z.B. in
/home/username/.ssh/authorized_keys

das sollte es schon gewesen sein und du kannst es testen mittels

ssh -i /pfad/wo/der/key/hinsoll/id_rsa username@deinServer

und du solltest ohne PW Abfragen als username auf dem Server angemeldet sein

 

[peterhoffmann]

Ich habe auf der DS das Paar mit dem folgenden Befehl erstellen lassen:

ssh-keygen -t rsa -b 4096 -C 'meine@mail.de' -f dun

Ich wurde bei der Erstellung nach einem Passwort gefragt, was ich aber leer gelassen habe.
Im Verzeichnis /root/.ssh/ wurden die Dateien dun und dun.pub erstellt.

Dann habe ich mir mit "cat dun.pub" den Key anzeigen lassen und mit der Zwischenablage kopiert. Das war eine Zeile und sah so aus:

ssh-rsa AAAAB3N ...(viele Zeichen)... 2uOUehVQ== meine@mail.de

Auf dem anderen Server habe ich mit dem Midnight Commander und F4 (Bearbeiten) die "authorized_key" geöffnet und mit Shift+rechte Maustaste diese Zeile eingefügt. Das sieht auch ordentlich aus, hat keine Umbrüche etc. Es steht nun an letzter Stelle von mehreren anderen Einträgen.

Nun habe ich bei der DS den folgenden Befehl eingegeben:

ssh -i /root/.ssh/dun admin@IPvomServer

Leider fragt er nach dem Passwort, sprich irgendwas haut wohl nicht hin. *grübel*
Wenn ich das Passwort eingebe, bin ich eingeloggt und es funktioniert. Wenn ich es richtig verstanden habe, sollte die Abfrage nach dem Passwort aber nicht mehr kommen, oder?
Was mir aufgefallen ist: Meine Zeichenkette ist etwas länger als die anderen schon vorhandenen Zeichenketten.

Hinweis: Der Benutzername ist "admin", da man mit "root" sich nicht direkt einloggen kann. "admin" hat aber Leserechte. Wenn man über SSH root braucht, muss man sich erst mit admin einloggen, dann auf root umloggen (su). Für das Abholen der Dateien reicht der Adminzugang aber.

 

[peterhoffmann]

Nachtrag:

Testweise habe ich es so probiert:

ssh -i /root/.ssh/dun root@IPvomServer

Es klappt! Danke!

 

[jahlives]

dann hat eventuell der Server die Auth per PubKey nicht aktiviert. Haste mal in der /etc/ssh/sshd_config geguckt ob die folgenden beiden Parameter aktiviert sind?

RSAAuthentication yes
PubkeyAuthentication yes

was auch Probleme machen kann sind die Rechte auf dem PrivateKey bzw die Rechte auf dem .ssh Verzeichnis. Der PrivateKey sollte nur Rechte für den Eigentümer haben. Zudem darf der .ssh Ordner keinesfalls Schreibrechte für jemand anders als den Eigentümer haben. Um Probleme weiter einzugrenzen kannst du das ssh Kommando auch mit dem Parameter -v (verbose) aufrufen. Das sollte bei Problemen zusätzliche Infos zeigen

 

[peterhoffmann]

Wie bekomme ich nun den Kopiervorgang gestartet?
Das sieht noch irgendwie falsch aus und ich traue mich nicht es zu testen.

scp -i /root/.ssh/dun root@IPServer:/home/sicherung/testfile.txt /volume1/zielverzeichnis/

 

[jahlives]

das sollte eigentlich so passen. solange du als Quelle (erstes Argument) immer den Server nimmst, solltest du auf dem Server kein Unheil anrichten können. Denn von der Quelle wird ja nur gelesen. Wenn du dann ganze Verzeichnisse holen willst, solltest du den -r Parameter bei scp verwenden (recursive). Zusätzlich am besten auch den -p Parameter, damit z.B. das Datum oder die Rechte (Eigentümer) im Backup nicht verändert werden

 

[peterhoffmann]

Mit etwas Schwitzen hat es geklappt.

Danke jahlives!

 

[jugi]

Urgs - bitte sowas nicht über dee root-user machen! Leg dir einen an, wenn noch kein weiterer da ist.

 

[jahlives]

Urgs - bitte sowas nicht über dee root-user machen!

je nachdem was man backuppen will geht das nur mit root! Wie willst du z.B. ein File/Verzeichnis backuppen wo nur root darauf Zugriff hat? Wenn du dafür dem Backupuser die entsprechenden Rechte geben würdest, reisst du dir u.U. ziemliche Löcher. Der Klassiker wäre ein Backup der .ssh Verzeichnisse und der Keys darin. Oder Verzeichnisse die nur Rechte für den Eigentümer haben. Ohne root würde das Backup dann kaum gehen resp müsste man zusätzliche Rechte geben damit dann das Backup läuft, aber dann könnte sich die applikation wegen zuvieler Rechte querlegen z.B. die Webverzeichnisse eines Apache, der mit suexec läuft. Wenn du da die Rechte aufbohrst geht wohl das Backup als non-root User, aber der Apache verweigert dann den Dienst.

Klar im Idealfall sollte man nicht als root arbeiten. Nur gibt es Fälle wo es kaum anders geht

 

[peterhoffmann]

Urgs - bitte sowas nicht über dee root-user machen! Leg dir einen an, wenn noch kein weiterer da ist.

Der User Admin ist eigentlich extra dafür da. Der darf lesen (nicht alles), aber nicht schreiben.

Ich habe es mit:

ssh -i /root/.ssh/dun admin@IPvomServer

probiert. Da funktioniert es leider nicht.

Nehme ich :

ssh -i /root/.ssh/dun root@IPvomServer

geht es sofort.

 

[jahlives]

wenn es mit admin gehen soll, musst du den Eintrag auch im .ssh/authorized_keys vom admin machen. Da es mit root geht, vermute ich mal du hast den Eintrag bei root und nicht bei admin gemacht

 

[jugi]

@jahlives: Hast ja Recht Es gibt Fälle, da geht es nicht anders. Das hier klang jetzt aber eher nach "0815"-Daten und da ist in den meisten Fällen (IMHO) ein eigener Nutzer, der nur ganz explizit Zugang auf die zu sichernden Daten bekommt, die deutlich bessere Lösung. (Whitelisting > Blacklisting)

 

[peterhoffmann]

wenn es mit admin gehen soll, musst du den Eintrag auch im .ssh/authorized_keys vom admin machen. Da es mit root geht, vermute ich mal du hast den Eintrag bei root und nicht bei admin gemacht

Nun verstehe ich die Logik. (hoffe ich *gg*).
Im Verzeichnis "/home/admin/" habe ich nun .ssh gefunden. Ok. Das probiere ich aus.

Noch mal danke.

Nachtrag:
Hat mit Admin nun funktioniert.

 

[jahlives]

Kleiner Nachtrag:
wenn du den Zugriff via Key weiter absichern willst, gibt es ein nettes Feature in authorized_keys. Dafür gibt es den command Parameter, welcher dazu benutzt werden kann ein Script aufzurufen, welches das SSH Kommando prüft. Damit kannst du verhindern, dass jemand, der dir den Key klaut, sich via ssh anmelden kann

#!/bin/bash

case "$SSH_ORIGINAL_COMMAND" in
 scp\ *|rsync\ *)
  $SSH_ORIGINAL_COMMAND
 ;;
 *)
  exit 1
 ;;
esac

dann in authorized_keys

from="*",command="/pfad/zum/script" ssh-rsa .....

in dem Fall kann der Key nur das Kommando scp und rsync ausführen. Nichts anderes v.a. kein SSH Zugriff. Das Bsp ist nur ganz rudimentär. Man kann es noch verfeinern, indem man auch die Parameter zu einem Kommando genau definiert. Was dann dazu gebraucht werden könnte zu verhindern, dass über scp oder rsync auch auf den Server geschrieben werden kann.
So kann man sehr genau definieren welche Kommandos über einen bestimmten Key überhaupt ausgeführt werden dürfen

 

[peterhoffmann]

@jahlives
Ich verstehe den Sinn und finde das eine gute Idee. Das bekomme ich (im Moment noch) nicht gebacken.
Um vorerst eine Risikominimierung vorzunehmen, läuft der Aufruf auf dem Webserver nicht mehr über Root, sondern einen User, der nur gewisse Bereiche lesen darf.

---

Da ich mich auch immer über praktische Beispiele freue, hier nun meine momentane Version, die mich schon sehr zufrieden stellt.
Ich habe meine Befehlszeile noch etwas verfeinert. Nun bekomme ich Dateiversionen, da die kopierte Datei ein vorangestelltes Datum erhält.

Mein Aufruf über den Aufgabenplaner der DS:
scp -l 1200 -i /root/.ssh/dun -p Benutzername@IPvomServer:/Pfad/zum/quellverzeichnis/dateiname.txt /Pfad/zum/Zielverzeichnis/`date +%Y%m%d`_dateiname.txt

Erklärung:
-l 1200 => Geschwindigkeitsbegrenzung (1200 = ca. 150kb/s)
-i => Pfad zum identity_file (zwecks Login)
-p => Übernahme vom Datum etc.
`date +%Y%m%d` => Einfügen vom Datum in den Dateinamen

Im Quellverzeichnis heißt die Datei => dateiname.txt
Im Zielverzeichnis heißt die Datei => 20160213_dateiname.txt (kopiert am 13.02.2016)

Meine Anwendung:
Bei mir legt ein Webserver täglich ein Backup als gepacktes Archiv vom Inhalt des Webservers (nur Domaininhalte) an. Die DS holt dieses Backup am 01. und 15. des Monats ab. So habe ich auf lange Sicht ein 14tägiges Backup, sprich 24 Files pro Jahr, jeweils im Dateinamen das Datum. Für mich übersichtlich und zielführend.

Ich hoffe, dass ich damit anderen Linuxlaien (wie ich einer bin) den Einstieg vereinfache.

 

[jahlives]

nur so als Tipp: ich würde es bei einem Backup tunlichst lassen, die Dateinamen zu verändern. Sonst musst du die bei einem Restore erst mühsam wieder berichtigen. Klar wenn es nur eine Datei ist, spielt das keine grosse Rolle, aber bei einem rekursiven Backup über ein grösseres Verzeichnis: gute Nacht
Leg besser ein Backupverzeichnis mit dem Datum im Namen an und sichere die Dateien ohne Veränderung in dieses Verzeichnis. Dann kannst du anhand des Verzeichnisnamens das Datum des Backups schnell ermitteln, musst aber beim Restore nicht erst mühsam alle Files erst berichtigen. Also besser sowas

scp -l 1200 -i /root/.ssh/dun -p Benutzername@IPvomServer:/Pfad/zum/quellverzeichnis/dateiname.txt /Pfad/zum/Zielverzeichnis/`date +%Y%m%d`/dateiname.txt

 

[peterhoffmann]

nur so als Tipp: ich würde es bei einem Backup tunlichst lassen, die Dateinamen zu verändern. Sonst musst du die bei einem Restore erst mühsam wieder berichtigen. Klar wenn es nur eine Datei ist, spielt das keine grosse Rolle, aber bei einem rekursiven Backup über ein grösseres Verzeichnis:

In meinem Fall besteht das Backup nur aus einer Datei, da der Webserver selber alles schon gepackt (tgz) hat. Da bleibt es sehr übersichtlich.
Bei Backups aus mehreren Dateien macht es natürlich Sinn für jedes Backup ein Verzeichnis anzulegen, was aus dem Datum besteht.