Zugriff auf externen Server mit SSH - private key - scp funktioniert, rsync nicht

[Alfredo123]

Hi zusammen,
vorab: Ich bin kein Linux-Freak, aber auch nicht ganz blöd, und hab mich schon durch diverse Foren gekämpft, für mein aktuelles Problem aber noch keine Lösung gefunden.

Ich muss von einem externen SFTP-Server regelmässig Daten auf mein System (DS716+, DSM 6.2.3-25426 ) holen. Im Moment mache ich das von einem Win10-Rechner aus über die Aufgabenplanung mit WinSCP und der Authentifizierung über PublicKey/PrivateKey. Funktioniert an sich problemlos.
Allerdings bin ich damit natürlich immer darauf angewiesen, dass der Rechner, auf dem die Aufgabe läuft, auch an ist. Ausserdem gibts - besonders nach Updates - mit der Aufgabenplanung hin und wieder auch Schwierigkeiten.

Also dachte ich, ich lass das doch gleich die Synology machen, zumal die auch das Ziel der Daten ist.
Mit scp funktioniert das auch

scp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH -p AuthUser@IPexternerServer:/output/* /volume1/Zielverzeichnis/

wobei KontoAdmin, AuthUser und IPexternerServer natürlich nur Platzhalter für die "echten" Parameter sind....

Das Problem dabei: Wenn die Dateien erfolgreich! (und nur dann) heruntergeldaden sind, sollen sie auf dem Server gelöscht werden, was über die Aufgabenplanung mit WinSCP problemlos möglich ist, weil WinSCP dazu Scripte zur Überprüfung bereitstellt. Für scp habe ich dafür bis jetzt nichts 100% zuverlässiges gefunden, und es muss 100% zuverlässig sein, da es sich um Produktions-Aufträge handelt.

Also dachte ich, ich, ich nutze statt scp rsync.

rsync -av --progress -e 'ssh -i /volume1/homes/KontoAdmin/.ssh/OpenSSH' -p AuthUser@IPexternerServer:/output /volume1/Zielverzeichnis

Dabei erhalte ich jedoch die folgende (mir nichtssagende) Meldung:

exec request failed on channel 0
rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]

Irgendwelche Ideen dazu? Ist es möglich, dass der externe Server eine Anfrage über rsync einfach nicht akzeptiert? Oder liegt der Fehler bei mir und meinen sehr eingeschränkten Linux-Kenntnissen?
Sonst irgendwelche Ideen, wie ich meine Aufgabe (womöglich auf einem ganz anderen Weg) mit der Synology erledigen kann?

Danke und Grüsse
Alfred

 

[Tommi2day]

Evtl. helfen die Ideen von hier weiter

 

[Alfredo123]

Hi, danke für den (auch noch superschnellen) Tip. Allerdings: Die Ideen beziehen sich - wenn ichs richtig verstanden habe - alle auf die Konfiguration des Servers, und darauf hab und will ich keinen Zugriff. Ist ein "professioneller" Server von T-Systems.

 

[Tommi2day]

Nö, Option 1+2 sind lokale Dinge, ich tippe auf 2 (die Quotes)

 

[Alfredo123]

Nochmal danke, aber dann hab ichs wirklich nicht kapiert. Die "Quotes" sind doch bei mir genau an der gleichen Stelle wie im von dir verlinkten Beispiel (sh. Code in meinem erster Post)? Oder übersehe ich einen Unterschied auch jetzt beim x-ten Vergleich?

 

[DrDeath]

Wenn es ein reiner SFTP Server ist, dann sind reine SSH / rsync Kommandos nicht erlaubt und werden abgewiesen.
Was werkelt denn am anderen Ende? Ein Axway SecureTransport ?

 

[Tommi2day]

Geht denn der Telekom Server von einem normalen Desktop Linux zu syncen? Rsync muss auch erlaubt und auf dem Server vorhanden sein.
Ersetze mal die Single Quotes mit Double Quotes und versuche dann den sync mit einer kleinen Datei. Wenn das klappt, nur die großen Dateien nicht, dann auch die Timeouts in der .ssh/config.

 

[Alfredo123]

Nochmal danke an euch beide!
@DrDeath: Muss und werde ich nachfragen; ist aber immerhin mal ein Hinweis, dass es durchaus "nur" an der Server-Seite liegen kann...
@Tommi2day: Zum "normalen Desktop Linux" kann ich nichts sagen, habe ich nicht getestet, müsste ich mir erst ein Live-System basteln.
Das mit den Double Quotes hatte ich schon getestet (vergessen zu erwähnen, sorry). Und es geht grundsätzlich nur um kleine Dateien, meist unter 1kB, max. 3kB, auch eine Testdatei mit 3Bytes geht nicht.... Und, wie gesagt, mit scp funktionierts problemlos.

 

[DrDeath]

Eine andere Lösung wäre, wenn der T-Systems SFTP Server dir neue Daten einfach "pushen" würde. (Wenn Push Funktion vorhanden ist...)
Dazu müsste dem T-Systems Server deine "Feste IP" und/oder Deine DynDNS Account mitgeteilt werden..... plus Freigabe Ordner, User, Passwort oder SSH Key.....

 

[Alfredo123]

Und schon wieder danke. Auch eine Idee, muss ich mal nachfragen, ob die das machen können/wollen. Befürchte aber eher nein, da das mit Sicherheit auch dort Aufwand bedeutet. Und mit der jetzigen Lösung (über Windows-PC mit WinSCP und Aufgabenplaner) funktionierts ja, für die also kein dringender Handlungsbedarf...

Aber dann erlaube ich mir noch eine Zusatzfrage:
Da es mit scp ja funktioniert: Gibts irgendeine Möglichkeit, die ich nicht kenne, die erfolgreiche Übertragung zu prüfen und dann nur die Dateien auf dem Server zu löschen, die erfolgreich übertragen worden sind? Denn genau das ist mit WinSCP möglich.

 

[DrDeath]

Schau mal hier : https://www.linuxquestions.org/ques...-and-delete-whats-been-downloaded-4175498279/

Dieses Script stellt eine Verbindung zum SFTP Server her und lädt alle Dateien herunter.
Anschliessend schaut es lokal nach, welche Dateien erfolgreich heruntergeladen worden sind, packt sie in eine Liste, stellt noch ein "rm" Befehl vor jede Datei Zeile, reconnectet sich und führt den delete Befehl für jeder Datei durch.

Pfade, Server und User müssen natürlich angepasst werden:

#connect to sftp and download all files to folder
sftp user@sftpsite.com <<EOF
mget * /home/download/
quit
EOF

#put list of all downloaded files into filelist.txt
ls /home/download > /home/docs/filelist.txt

# prefix rm command to each file in filelist.txt
sed -i -e 's_.*_rm "&_' /home/docs/filelist.txt

# put each file in filelist.txt into "" to be able to parse spaces
sed -i.bak 's/$/"/' /home/docs/filelist.txt

#prefix sftp connection information at begining of filelist.txt
sed -i '1s/^/sftp user@sftpsite.com <<EOF\n/' /home/docs/filelist.txt

#append quit and EOF to end of filelist.txt
cat /home/docs/filelist.txt ; echo "quit" >> /home/docs/filelist.txt
cat /home/docs/filelist.txt ; echo "EOF" >> /home/cgerada/sftp/filelist.txt

#make filelist.txt executable
chmod +x /home/docs/filelist.txt

#run filelist.txt as a script to remove all files already downloaded
/bin/bash /home/docs/filelist.txt

# move contents of locally downloaded folder to processed folder to be ready for next download
mv /home/download/* /home/processed/

 

[Alfredo123]

ok, wieder danke! Ist zumindest mal ein vielversprechender Ansatz; anpassen werd ich aber wohl mehr müssen, da ich mich ja mit "private key" verbinden muss. Werd ich aber so versuchen und berichten (kann aber etwas dauern)....

 

[Alfredo123]

So, und nun zur Rückmeldung: Klar ist nach meiner Nachfrage bei T-systems, dass das so nicht geht, weder per rsync noch mit einem Script wie oben. Zitat: " und soll auch so bleiben, dass ssh/rsync Kommandos nicht erlaubt sind."
Vorschlag von T-Systems:
Ein Script, in dem

• das Verzeichnis gescannt wird
• die Dateien runtergeladen werden
• es wird geprüft, ob die Dateien alle erfolgreich runtergeladen wurden
• und danach werden die gelöscht.

Dabei mit „get” runterladen und dann mit „delete” löschen.
Allerdings geht da weit über meine Linux-Kenntnisse hinaus.....

 

[DrDeath]

Genau das macht das von mir vorgeschlagene Script, welch Du natürlich an Deine Pfade und SFTP Server / SSH Keys anpassen musst.

Das Script macht folgendes:

sftp Connect und alles was im Home Ordner vom sftp Account liegt herunterladen in das "/home/download/" Verzeichnis auf deinem NAS (musst Du natürlich anpassen, ist nur ein Beispiel)

Danach wird die Verbindung zum sftp Server getrennt.

Das Script liest nun den kompletten Inhalt von Deinem Verzeichnis "/home/download/" und packt jeden Dateinamen in ein Inhaltsverzeichnis Liste -->
/home/docs/filelist.txt (Auch hier musst du die Pfade anpassen)

nun wird das Inhaltsverzeichnis "filelist.txt" mit verschiedenen Kommandos bearbeitet.

Zum Beispiel sieht das erste Inhaltverzeichnis filelist.txt so aus:

datei1.csv
image3.jpg
Testtext.txt

Das Script macht im ersten Schritt das draus:

rm "datei1.csv
rm "image3.jpg
rm "Testtext.txt

Danach das:

rm "datei1.csv"
rm "image3.jpg"
rm "Testtext.txt"

Nun wir noch in die erste Zeile die sftp Verbindungsdaten hinzugefügt:

sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH AuthUser@IPexternerServer:/output/  <<EOF
rm "datei1.csv"
rm "image3.jpg"
rm "Testtext.txt"

Und zum Schluss noch die Ende Befehle:

sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH AuthUser@IPexternerServer:/output/  <<EOF
rm "datei1.csv"
rm "image3.jpg"
rm "Testtext.txt"
quit
EOF

Nun wird das Inhaltsverzeichnis Liste ausführbar gemacht und ausgeführt.

Abschliessend werden die heruntergeladenen Dateien in ein anderes Verzeichnis geschoben, damit sie beim nächsten Durchlauf des Scripts nicht erneut mit aufgelistet werden.


Du musst also alle "Pfade" anpassen und die vorkommen vom SFTP Verbindungsaufbau anpassen.

Könnte so aussehen:
/volume1/Zielverzeichnis/ und /volume1/Erledigt/ müssen natürlich auch noch angepasst werden, ebenso die Zeilen die das "sftp" beinhalten.

#connect to sftp and download all files to folder
sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH AuthUser@IPexternerServer:/output/ <<EOF
mget * /volume1/Zielverzeichnis/
quit
EOF

#put list of all downloaded files into filelist.txt
ls /volume1/Zielverzeichnis/ > /volume1/homes/KontoAdmin/filelist.txt

# prefix rm command to each file in filelist.txt
sed -i -e 's_.*_rm "&_' /volume1/homes/KontoAdmin/filelist.txt

# put each file in filelist.txt into "" to be able to parse spaces
sed -i.bak 's/$/"/' /volume1/homes/KontoAdmin/filelist.txt

#prefix sftp connection information at begining of filelist.txt
sed -i '1s/^/sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH AuthUser@IPexternerServer:/output/ <<EOF\n/' /volume1/homes/KontoAdmin/filelist.txt

#append quit and EOF to end of filelist.txt
cat /volume1/homes/KontoAdmin/filelist.txt ; echo "quit" >> /volume1/homes/KontoAdmin/filelist.txt
cat /volume1/homes/KontoAdmin/filelist.txt ; echo "EOF" >> /volume1/homes/KontoAdmin/filelist.txt

#make filelist.txt executable
chmod +x /volume1/homes/KontoAdmin/filelist.txt

#run filelist.txt as a script to remove all files already downloaded
/bin/bash /volume1/homes/KontoAdmin/filelist.txt

# move contents of locally downloaded folder to processed folder to be ready for next download
mv /volume1/Zielverzeichnis/* /volume1/Erledigt/

 

[synfor]

Nun wir noch in die erste Zeile die sftp Verbindungsdaten hinzugefügt:

Wozu soll das gut sein?

 

[Alfredo123]

Ok, da hatte ich gestern zu schnell aufgegeben - im Endeffekt hatte ich nicht kapiert, dass eine ssh-Verbindung und sftp offfensichtlich 2 paar Stiefel sind. Ich hatte gestern versucht, mal eine Datei zu löschen, und bin auch damit gescheitert (nach Aufbau der Verbindung per ssh). Jetzt, nachdem ich mir den sftp-Befehl angeschaut habe und gesehen hab, dass auch da die Angabe des private key möglich ist, sieht es anders aus.
Also hab ich jetzt erstmal wieder was zum Testen....
Vorab aber gleich nochmal 2 Fragen (ansonsten denke ich, dass ich das meiste kapiert habe:
Wozu sind die beiden EOF bei
sftp user@sftpsite.com <<EOF
mget * /home/download/
quit
EOF
Wieder Danke!!!

 

[Alfredo123]

Wozu soll das gut sein?

Ich denke, das kann sogar ich beantworten. Da vorher die Verbindung ja geschlossen wurde, muss sie zum Löschen der Dateien wieder hergestellt werden.

 

[synfor]

Zum Löschen von lokalen Dateien, die zuvor auf den SFTP-Server hochgeladen wurden?

Edit: Da hatte ich wohl die Richtung verwechselt

 

[DrDeath]

Nein, zum anschliessenden Remote löschen der bereits heruntergeladenen Dateien auf dem entfernten SFTP Server natürlich.

Hier werden nur Dateien VON einem SFTP Server HERUNTERGELADEN

mget * /volume1/Zielverzeichnis/

Wenn man es direkt in der gleichen Session wir beim Download machen würde, hätte man keine echte Kontrolle, welche Dateien wirklich heruntergeladen wurden.

 

[Alfredo123]

Nein; es geht um genau andersrum... die Dateien werden vom Server heruntergeladen und - bei erfolgreicher Übertragung - anschliessend auf dem Server gelöscht...
Hoppla, @DrDeath war etwas schneller....