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

DrDeath

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de
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:

Bash:
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.
 
  • Love
Reaktionen: Alfredo123

Alfredo123

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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.
Rich (BBCode):
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
Rich (BBCode):
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!!!:D:D:D
 

DrDeath

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de
ich melde mich nachher...das bekommen wir aber auch noch hin.

So sollte es klappen:
Rich (BBCode):
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.
 
Zuletzt bearbeitet:
  • Love
Reaktionen: Alfredo123

Alfredo123

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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?
 
Zuletzt bearbeitet:

DrDeath

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de
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...
 
  • Love
Reaktionen: Alfredo123

Alfredo123

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
05. September 2012
Beiträge
1.558
Punkte für Reaktionen
15
Punkte
64
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

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de

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

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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... :eek: :eek: :eek:
 

DrDeath

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de
Technisch gesehen "verlierst" du nur die letzte übertragene Datei..... es wird ja sequenziell heruntergeladen......
 

Alfredo123

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
"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

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de
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

Benutzer
Mitglied seit
05. September 2012
Beiträge
1.558
Punkte für Reaktionen
15
Punkte
64
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" :ROFLMAO:

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

Benutzer
Mitglied seit
31. August 2018
Beiträge
39
Punkte für Reaktionen
8
Punkte
14
Website
www.lpi-clan.de
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

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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?
 
Zuletzt bearbeitet:

tproko

Benutzer
Mitglied seit
11. Juni 2017
Beiträge
1.066
Punkte für Reaktionen
29
Punkte
74
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.
 
  • Like
Reaktionen: Alfredo123

Alfredo123

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
21. Juni 2020
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
22. Dezember 2017
Beiträge
2.046
Punkte für Reaktionen
33
Punkte
88
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.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Alfredo123

luddi

Benutzer
Mitglied seit
05. September 2012
Beiträge
1.558
Punkte für Reaktionen
15
Punkte
64
@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:

Bash:
#!/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.
 
  • Like
Reaktionen: Alfredo123
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten, denn dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit einem hohen technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive oder Themen fremde Werbung. Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.