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

[DrDeath]

Hier noch die Antwort zu "EOF"

https://www.cyberciti.biz/faq/using-heredoc-rediection-in-bash-shell-script-to-write-to-file/


Man kann mit einem EOF Stream mehrere Befehle als Parameter zusammensetzen und dem ersten Befehl "übergeben"

Sprich:

sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH AuthUser@IPexternerServer:/output/ <<EOF
mget * /volume1/Zielverzeichnis/
quit
EOF

Baue eine Verging per SFTP mit dem SSH Key zum Zielsver auf, wenn du verbunden bist verarbeite nacheinander alle Befehle die zwischen <<EOF und ... EOF stehen

Erstmal alle Dateien herunterladen ins Zielverzeichnis, wenn fertig brav beim SFTP ausloggen mit "quit"...erst dann die Verbindung trennen.

Das gleiche gilt für die zweite Verbindung, nachdem man das Inhaltsverzeichnis erstellt hat:

Erst die Verbindung aufbauen und dann Zeile pro Zeile die vorher, erfolgreich heruntergeladenen Dateien mit "rm Dateiname" löschen.
(Der SFTP Server nimmt den Befehl "rm" genauso entgegen wie "delete")


Und ja, SSH und SFTP sind zwei Paar Schuhe
SFTP ist nicht anderes als eine SSH Verbindung, auf der anschliessen per FTP Protokoll weiter "geredet" wird. (Verschlüsseltes FTP)
Daher funktionieren auch nicht alle SSH Befehle, sondern nur noch die fürs FTP Protokoll zugelassen und vom SFTP Server freigegeben wurden.

 

[Alfredo123]

So, und ich bin jetzt das Script mit meinen lokalen Anpassungen Schritt für Schritt durchgegangen; alles gut, bis zu dem Punkt, wo die sftp-Verbindung wieder in die filelist eingetragen werden soll.

sed -i '1s/^/sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH 12345678@123.45.67.89 <<EOF\n/' /volume1/homes/KontoAdmin/filelist.txt

ergibt die Fehlermeldung

sed: -e expression #1, char 15: unknown option to `s'

Mit der Originalzeile (ohne privatekey) funktionierts.

Und uups: erst jetzt habe ich gesehen, dass du das Script ja schon weitgehend für mich angepasst hattest. Nochmal ein extra dickes Danke dafür!!!

 

[DrDeath]

ich melde mich nachher...das bekommen wir aber auch noch hin.

So sollte es klappen:

sed -i '1s~^~sftp -i /volume1/homes/KontoAdmin/.ssh/OpenSSH 12345678@123.45.67.89 <<EOF\n~' /volume1/homes/KontoAdmin/filelist.txt

Ich hatte die ganzen "/" Backslashes im Pfad nicht bedacht.....die Backslashes waren aber auch der Delimeter für sed...das konnte so nicht klappen.

Habe anstelle der / Delimeter nun ~ benutzt.

 

[Alfredo123]

Jawoll, klappt. Wirklich klasse Support und viel Geduld für einen Linux-Un- bzw. Kaumwissenden, danke dir. Bevor ich mich traue, das wirklich in der Produktion einzubauen, werde ich noch ein paar Tage testen. Rückmeldung folgt, versprochen!
Noch eine (hoffentlich letzte) Frage zur Sicherheit:
Ist die sftp- bzw. mget-Übertragung wirklich sicher, soll heissen, wenn die Datei lokal da ist, kann ich auch sicher sein, dass die identisch mit der Server-Datei ist?

 

[DrDeath]

Ja, Dateien die beim mget * Befehl nicht korrekt heruntergeladen wurden (CRC Checksummen Fehler, Verbindungsabbruch usw.) werden nicht auf deine Platte geschrieben.

Somit werden Sie auch nicht bei der Erstellung des lokalen Inhaltsverzeichnis aufgeführt und werden beim zweiten „Lösch“ Durchlauf auch nicht gelöscht.

Erst beim nächsten Komplett Durchlauf wird dann versucht die vorher nicht heruntergeladen Dateien erneut zu laden....

... genau das ist der Grund die Dateien nicht direkt nach dem Download Befehl in der gleichen SFTP Verbindung zu löschen.... man will ja erst nachschauen ob alles ok war.

P.S.: Ich betreue beruflich u.a. größere managed Filetransfer Server...

 

[Alfredo123]

Prima, und schon wieder danke. Hört sich gut an, besser kanns dann WinSCP wohl auch nicht machen, was die Verlässlichkeit der heruntergeladenen Daten angeht ...

 

[luddi]

Ja, Dateien die beim mget * Befehl nicht korrekt heruntergeladen wurden (CRC Checksummen Fehler, Verbindungsabbruch usw.) werden nicht auf deine Platte geschrieben.

Ich habe mal diesen Thread aus Interesse verfolgt und es deutete darauf hin dass der Server der angesprochen wird kein rsync zulässt.
Dennoch wundere ich mich darüber wie ein mget Befehl einen Fehler erkennen soll?
Die Datei wird während der Übertraung bereits auf die lokale Festplatte geschrieben. Verliert man aus welchem Grund auch immer die Verbindung zum Server, so ist die Datei nur partiell auf der Festplatte vorhanden. Jetzt geht man davon aus, die Datei sei komplett übertragen weil sie auf dem Dateisystem zu finden ist?

Ich habe gerade eine Übertragung zu Testzwecken begonnen und mit "Strg+C" abgebrochen. Dennoch vebleibt das bereits heruntergeladene Teilstück der Datei auf der Festplatte.

Wo findet denn der Prüfsummenvergleich statt und wann? Denn wenn jetzt eine Dateiliste erstellt wird und anhand diesser Informationen die Datei auf dem Server gelöscht wird dann hat man vermutlich Datenverlust zu beklagen.

 

[DrDeath]

https://stackoverflow.com/questions...uring-a-sftp-file-transfer-for-data-integrity
Frei übersetzt:

Beim SFTP, das über eine verschlüsselte SSH-Sitzung läuft, ist die Wahrscheinlichkeit, dass der Dateiinhalt während der Übertragung beschädigt wird, vernachlässigbar gering. Bei der SSH-Sitzung wird die Datenintegrität selbst überprüft.

Wenn also der Inhalt beim Lesen der lokalen Datei oder beim Schreiben der entfernten Datei nicht beschädigt wird, können Sie ziemlich sicher sein, dass die Datei korrekt hochgeladen wurde, wenn kein Fehler gemeldet wird. Das bedeutet, dass das Risiko einer Datenbeschädigung in etwa das gleiche ist, als ob Sie die Dateien zwischen zwei lokalen Laufwerken kopieren würden.

Wenn Sie es nicht für notwendig erachten würden, die Datenintegrität nach dem Kopieren der Dateien von einem lokalen Laufwerk auf ein anderes zu überprüfen, dann glaube ich nicht, dass Sie die Integrität nach einem SFTP-Transfer überprüfen müssen und umgekehrt.

Wenn man jedoch zu 100% auf Sicherheit bedacht ist, dann sollte man auch "Managed Filetransfer Systems" ( wie z.B. Axway SecureTransport ) einsetzen. Die beherrschen auch push, pull, transform, retry on failure usw. ... kosten aber eine Stange Geld.

Da hier vorgeschlagene Script sollte schon robust genug sein.

 

[Alfredo123]

UUps, kann ich bestätigen; habs grad mit einer grösseren Datei getestet, bei 50% abgebrochen; die Teildatei ist im Eingangsverzeichnis. Ob es wohl einen Unterschied macht, wenn manuell abgebrochen wird???
Edit: Nein, nicht nur manuell. Habs grad getestet, indem ich während der Übertragung die Inet-Verbindung gekappt habe. Die Teil-Datei ist trotzdem da (mit vollständigem Dateinamen). Ist zwar für mich ein Stück weit nur akademisch, da meine Dateien alle < 3kB sind, aber so sicher scheint die mget-Übertragung doch nicht.
WinSCP macht das anders. Da hat die Datei während der Übertragung die Endung .tmp, und bekommt die "richtige" Endung erst nach vollständiger, fehlerfreier Übertragung.
Also doch nicht so toll...

 

[DrDeath]

Technisch gesehen "verlierst" du nur die letzte übertragene Datei..... es wird ja sequenziell heruntergeladen......

 

[Alfredo123]

"Nur" ist gut - wie gesagt, es geht um Produktions-Aufträge (edifact). Gut wärs nicht - wenn ich auch zugebe, dass es bei dieser Dateigrösse eher unwahrscheinlich ist. Aber "sicher" ist halt was anderes. Und das, wo Linux immer als DAS sichere System angepriesen wird.... Bin schon etwas enttäuscht (nein, nicht von dir und deiner Hilfe, sondern von Linux)

 

[DrDeath]

Ah, edifact..... solche Dateien transferieren wir nicht per SFTP, sondern nur über AS2.....das ist sicherer, aber auch teurer.

Linux ist nur ein Betriebssystem, kein Übertragungsprotokoll ;-)

 

[luddi]

Technisch gesehen "verlierst" du nur die letzte übertragene Datei..... es wird ja sequenziell heruntergeladen......

Und was soll uns das sagen wenn man nur die letzte Datei verliert?
"Ach ist nicht so schlimm... ich habe ja noch genug andere Dateien auf der Festplatte"

Den von dir verlinkten Thread zu stackoverflow kenne ich bereits. Dies heißt aber nur, dass das Protokoll die Datenübertraung absichert, aber nicht die Integrität der Dateien am Ziel.
Die Datenintegrität muss separat abgesichert werden durch die nachträgliche Berechung der Prüfsummen sowohl auf der Quelle als auch am Ziel.

Das mag wohl dein empholenes "Managed Filetransfer Systems" können, aber SFTP allein kann das definitv nicht!
Somit ist deine Behauptung, dass die Integrität mittels irgenwelcher Prüfsummen durch mget abgesichert ist völlig daneben.

P.S.: Ich betreue beruflich u.a. größere managed Filetransfer Server...

Technisch gesehen "verlierst" du nur die letzte übertragene Datei..... es wird ja sequenziell heruntergeladen......

Das nenne ich ganz großes Kino wenn du deinen Kunden erzählst es sei nicht so schlimm wenn man nur eine einzige Datei verliert. Das verdient wahrlich Applaus... ?

 

[DrDeath]

Ich wollte auf die Wahrscheinlichkeit hinweisen.

Aber ja, Du hast recht.

Wenn es um sehr empfindliche, teure Daten geht, dann kann reines SFTP das nicht leisten.
Echtes CRC MD5sum Check unterstützt nicht jeder Server und Client.

Daher wird im edifact Umfeld fast nur mit AS2 und dem alten oFTP gearbeitet, oder auch mit den "teuren" Systemen per SFTP, aber dann halt Softwareseitig komplett überwacht. ( B2Bi Systeme usw... )

Am Anfang der Unterhaltung war mir nicht bewusst, wie sensible die Daten sind.

 

[Alfredo123]

Da mir das Script nach wie vor gefällt, habe ich überlegt, wie die Sicherheit vielleicht doch noch erhöht werden könnte. Meine (hoffentlich nicht ganz blöde) Idee:
Ich könnte doch die Dateien direkt hintereinander 2mal in 2 verschiedene lokale Verzeichnisse runterladen und dann für beide lokalen Verzeichnisse die Dateilisten filelist1.txt und filelist2.txt erstellen. Wenn diese beiden Dateien gleich sind, ist es sehr unwahrscheinlich, dass es irgenwann einen Verbindungsabbruch gab. Oder überseh ich da etwas?
Für noch grössere Sicherheit könnte man ja sogar noch die Ausgaben von ls -l der beiden Verzeichnisse vergleichen; dann wären die Dateigrössen auch noch geprüft.

Und dann (falls die Idee was taugt): Ich hab gefunden, dass diff -q die beiden Dateien vergleichen kann. Wie aber nutze ich im Script den exit-code, um zu entscheiden, ob ich abbreche (Unterschiede festgestellt) oder weitermache mit filelist bearbeiten, lokal kopieren und schliesslich auf Server löschen?

 

[tproko]

Wenn du schon eine Liste der Dateien hast, könntest du dann aber einfach gleich den md5 Hash der jeweiligen Dateien generieren und mit dem 2. Verzeichnis gegenprüfen.

 

[Alfredo123]

Auch dir danke für den Tip; daraus schliesse ich mal, dass die prinzipielle Idee gar nicht so verkehrt ist.
Ok, dachte eben, so ists einfacher, weil die "filelist"-Dateien ja schon da sind. Und ich bin eben nicht so fit in Linux, hab jetzt eben erst durch Suche und Probieren rausgefunden, wie ich den exit-code von diff im Script verwenden kann.
Wenn der md5-Hash aber noch mehr Sicherheit bringt, werd ich mir das auch noch anschauen. Nachteil: den muss ich ja dann für jede einzelne Datei 2mal erzeugen und auch vergleichen. Für einen Script-Spezialisten sicher eine Kleinigkeit, für mich wieder mit viel Suchen und Probieren verbunden....

 

[Alfredo123]

Kann den letzten Post leider nicht mehr bearbeiten: Nach einigem Rumprobieren und Lesen denke ich nun, dass die md5-Lösung wohl die Beste und sicherste und nichtmal so kompliziert ist, wie ich gedacht habe. Meine angedachte Vorgehensweise (hab jetzt nur die nächsten paar Stunden keine Zeit mehr zum Testen):
1. Download aller Dateien 2mal hintereinander in 2 verschiedene Verzeichnisse
2. md5-Datei für alle Dateien in Verzeichnis 1 erstellen
In Download-Verzeichnis 1 ausführen: md5sum * > md5check.txt
3. Dateien in Verzeichnis 2 mit erstellter md5-Datei aus Verzeichnis 1 gegenchecken
In Download-Verzeichnis 2 ausführen: md5sum -c /Verzeichnsi1/md5check.txt
4. Bei exitcode 0 weitermachen, bei exitcode 1 abbrechen.

Was haltet ihr davon? Sollte doch funktionieren und auch sicher sein, oder hab ich noch einen Denkfehler?
Wie ich das sehe, wäre der einzig denkbare nicht zu entdeckende Fehler, dass 2mal hintereinander genau derselbe Download-Fehler passiert - vernachlässigbar.
Danke!

 

[synfor]

Vor dem md5-Check die Dateigröße prüfen und den md5-Check nur bei gleicher Größe durchführen.

Ach ja, vor allem könnte man als aller erstes auch noch überprüfen, ob die Anzahl der Dateien und Ordner identisch ist. Dafür und für die Größenprüfung muss man nicht mal die Daten 2× herunterladen. Wenn der SFTP-Server die Hashs liefern kann, wäre das auch vom Vorteil. Ist leider optional und wird nicht immer unterstützt.

 

[luddi]

@Alfredo123
Punkte 2 bis 4 kannst du alles zusammenfassen. Erspar dir einfach die Prüfsummen in Dateien abzulegen. Kann man direkt on-the-fly über variablen machen.

Zum Beispiel so:

#!/bin/bash

source1=$1
source2=$2

string1=`find $source1 -type f -exec openssl dgst -md5 {} \; | egrep -o [0-9a-zA-Z]{32}`
string2=`find $source2 -type f -exec openssl dgst -md5 {} \; | egrep -o [0-9a-zA-Z]{32}`

if [ "$string1" == "$string2" ]; then
  echo "Result: OK"
else
  echo "Result: ERROR"
fi

Vor dem md5-Check die Dateigröße prüfen und den md5-Check nur bei gleicher Größe durchführen.

Das hier von synfor könnte man sich definitv noch überlegen für eine Optimierung der Laufzeit.