Datei per https teilen

[reox]

Hin und wieder wäre es sinnvoll eine Datei von Rechner A auf Rechner B zu bringen, das ganze verschlüsselt aber auch einfach und idealerweise nur mit Bordmitteln (zb curl).
Das Problem ist zB auf einem Host der per SSH einem bestimmten User zugänglich ist aber die Datei root gehört.
Ich kann auf dem Host zwar problemlos root werden und die Datei kopieren oder Rechte setzen aber idealerweise möchte ich als root dann nur ein Script starten, welches die Datei etwa einmal per https verfügbar macht, so dass ich sie auf Rechner B runterladen kann.
SSH geht zB nicht, wenn der Key nicht auf Rechner B liegt, usw.

Meine Idee war ein kleines tool schreiben, welches ein Zertifikat generiert, dann einen Webserver startet, die Datei unter einem zufällig generierten Pfad bereitstellt, dann den Fingerprint und URL anzeigt und ich so auf einem zweiten Rechner die Datei per wget/curl laden kann.
Das könnte zB so aussehen:

Code: Alles auswählen

$ sharefile meine_datei.tar.gz
Generating Certificate ...
Open webserver ...
 Download Command: curl -k -O --pinnedpubkey "sha265//47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=" https://1.2.3.4:8085/ldljsdlkj324j327840923_das_ist_ein_geheimer_token_lksdjfkl/meine_datei.tar.gz
 File SHA256: 5ca76d9a9275caf279dff2459adbbc20e0bbd167a152a3bd8ee8a365b1bd5dee
Waiting for download ...
 Received connection from 4.3.2.1 ... Done!
 Download took 4.2s (42MiB/s)
Closing webserver. Bye!

So etwas ähnlich, mit aber einer anderen Ausrichtung, gibt es zB hier: https://pypi.org/project/secureshare/
Ich kann mir kaum vorstellen, das es so etwas nicht schon fix fertig gibt... Oder doch nicht?

[MSfree]

Keine Ahnung, ob ich die hier richtig verstehe. Ich habe jedenfalls den Eindruck, daß du dir ein Problem schaffst, das eigentlich nicht existiert.

Aber, wenn du schon einen SSH-Zugang hast, könntest du die Datei doch auch mit scp runter/hochladen.

[Meillo]

Ich glaube, reox will die Datei einem anderen User bereitstellen als dem, der den SSH-Zugang hat.

[uname]

Ich würde einfach auf dem Rechner einen SSL-Webserver laufen lassen. Dann könnte root die Datei in den Webserver-Ordner kopieren und die Gesamt-URL besteht dann aus URL des Webservers und Dateinamen. Und wo man dabei ist, könnte man natürlich auch eben schnell eine Cloud mit Tiny File Manager bauen siehe meine XMasCLOUD vom Adventskalender 2022, auch sehr nett wäre jirafeau, wo du jedoch die Dateien erst mal downloaden und wieder uploaden müsstest. Oder wo du sowieso dabei ist, warum installierst du dir nicht einfach eine kleine Nextcloud? Dann kannst du auch gleich Dateien mit deinem Smartphone synchronisieren oder darüber auf deinen Rechner zugreifen siehe z. B. Nextcloud Android App.

Nachtrag bzgl. Alternative zu SecureShare. Du könntest dir auch noch https://privatebin.net/ (Projektseite) anschauen, falls du wirklich die Dateien auch noch AES-256 E2E (Ende zu Ende) verschlüsseln willst, was im Übrigen nichts mit TLS/SSL zu tun hat, was eine reine Transportverschlüsselung ist.

[Meillo]

Ich faende einen minimalistischen Ansatz cool: Man startet ein Programm mit der Datei als Argument. Das Programm oeffnet einen hohen Port und wartet. Beim ersten Verbindungsaufbau wird die Datei ausgeliefert und das Programm beendet sich wieder. Das geht doch bestimmt mit einem Python-Einzeiler. Dann muesste man noch nicht mal was installieren.

Sicherheit koennte recht einfach ueber einen zufaelligen Dateinamen umgesetzt werden.

[uname]

Vielleicht könnte man netcat verwenden siehe hier (soll nur ein Beispiel sein, nicht selbst gelesen). Für die Sicherheit kann man die Daten vielleicht beim Sender und Empfänger einmal durch aespipe jagen und sich damit den ganzen TLS/SSL-Quatsch sparen. Wer braucht schon einen SSL-Webserver geschweige denn eine Cloud.

[reox]

Um ein paar Dinge klar zu stellen:

Die Datei liegt auf A, soll auf B.

• von B -> A komme ich nicht per SSH (kein Key deployed, agent forward nicht möglich, faulheit, ...)
• A ist aus dem Internet (oder auch nur im LAN - selbes Problem) erreichbar
• Die Datei auf A gehört zB root - root hat keinen SSH zugang
• Die Datei in ein http zugänglichen Ordner kopieren ist möglich, aber schwierig (zB Datei zu groß)
• Kurzfristig die Rechte ändern, so dass ein User mit SSH Zugang zugriff hat möglich, aber unsicher (vergessen zum rückgängig machen etc) - außerdem hat B ja sowieso keinen Zugriff per ssh
• Ja, nextcloud etc geht - aber ebenfalls zu viele schritte (Datei kopieren, per SSH auf C kopieren, in die Nextcloud geben, freigeben, auf B runterladen)
• Der Transportweg soll verschlüsselt sein
• HTTP bietet sich an, da Clients üblicherweise vorinstalliert sind

Man startet ein Programm mit der Datei als Argument. Das Programm oeffnet einen hohen Port und wartet. Beim ersten Verbindungsaufbau wird die Datei ausgeliefert und das Programm beendet sich wieder. Das geht doch bestimmt mit einem Python-Einzeiler. Dann muesste man noch nicht mal was installieren.

Exakt. Das wäre das, was ich oben schon skizziert habe.
Ich habs auch schonmal ausprobiert - allerdings ist mir grad nicht klar wie man dem http.server HSTS beibringt, so dass er den Fingerprint anhängt.
So, oder ähnlich könnte es dann anfangen:

Code: Alles auswählen

#!/bin/bash

# TODO could be done offline ;)
PUBIP=$(curl ipconfig.sh)

# 1. Generate a SSL Cert
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 10 -nodes \
        -subj "/O=reox" \
        -addext "subjectAltName=IP:${PUBIP}"

# 2. Grab the SHA265 pubkey
PIN=$(openssl x509 -in cert.pem -pubkey -noout | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -binary | openssl enc -base64)

echo "Download URL:"
# Note: -k is required because of self-sign. Pinned certificate should still be checked...
echo "curl -k -O --pinnedpubkey='sha265//${PIN}' https://${PUBIP}:23080"

# TODO: How to HSTS?! using the pinnedpubkey does not work :/
# TODO: create random token, only accept requests to that virtual folder and the file given as $1.
python3 -c "import logging, http.server, ssl; logging.basicConfig(level='DEBUG'); httpd = http.server.HTTPServer(('0.0.0.0', 23080), http.server.SimpleHTTPRequestHandler); httpd.socket = ssl.wrap_socket (httpd.socket, certfile='cert.pem', keyfile='key.pem', server_side=True); httpd.serve_forever()"

Vielleicht könnte man netcat verwenden siehe hier. Für die Sicherheit kann man die Daten vielleicht beim Sender und Empfänger einmal durch aespipe jagen.

Ja per netcat hab ich das im LAN schon gemacht - das funktioniert prima. Aespipe kannte ich noch nicht, das schaut in dem Fall sehr brauchbar aus! Danke für den Tipp! Allerdings kein Bordmittel

[chrbr]

Du könntest die zu versendende Datei oder ein Archiv mit gpg verschlüsseln, und zwar nur mit einer Passphrase. Das Versenden ist dann der zweite Schritt, für den es ja viele Möglichkeiten gibt.

[reox]

Du könntest die zu versendende Datei oder ein Archiv mit gpg verschlüsseln, und zwar nur mit einer Passphrase. Das Versenden ist dann der zweite Schritt, für den es ja viele Möglichkeiten gibt.

Stimmt - das ist eine gute Idee und gpg sollte eigentlich überall drauf sein.

Allerdings glaub ich trotzdem das es genau so ein Tool wie ich es beschrieben habe geben muss. Ich kann mir nicht vorstellen, dass das noch niemand entwickelt hat...

[mat6937]

Stimmt - das ist eine gute Idee und gpg sollte eigentlich überall drauf sein.
Allerdings glaub ich trotzdem das es genau so ein Tool ...

Wenn die Datei verschlüsselt ist, reicht auch http:

Code: Alles auswählen

python3 -m http.server 48838 --bind=<IP-Adresse>

ftp wäre mit python3 und "-m pyftpdlib" auch möglich.

[reox]

Stimmt - das ist eine gute Idee und gpg sollte eigentlich überall drauf sein.
Allerdings glaub ich trotzdem das es genau so ein Tool ...

Wenn die Datei verschlüsselt ist, reicht auch http:

Code: Alles auswählen

python3 -m http.server 48838 --bind=<IP-Adresse>

ftp wäre mit python3 und "-m pyftpdlib" auch möglich.

Der hat aber IMHO keine Möglichkeit nur eine bestimmte Datei zu servieren bzw diese von stdin zu erhalten (jedenfalls nicht wenn man das Modul direkt aufruft. Mit der API gehts vermutlich in ein paar Zeilen).
Idealerweise piped man die Datei nach GPG und dann direkt in den Socket, damit man nicht noch extra auf die Platte schreiben muss.

[mat6937]

Der hat aber IMHO keine Möglichkeit nur eine bestimmte Datei zu servieren ...

Doch, wenn sich im Verzeichnis im dem der http-Server gestartet wird, nur die eine bestimmte Datei befindet, wird auch nur diese eine Datei serviert.

[JTH]

Der hat aber IMHO keine Möglichkeit nur eine bestimmte Datei zu servieren ...

Doch, wenn sich im Verzeichnis im dem der http-Server gestartet wird, […]

Alternativ kann man mit der Option -d den zu servierenden Ordner angeben.

[reox]

Der hat aber IMHO keine Möglichkeit nur eine bestimmte Datei zu servieren ...

Doch, wenn sich im Verzeichnis im dem der http-Server gestartet wird, nur die eine bestimmte Datei befindet, wird auch nur diese eine Datei serviert.

Naja das ist klar. Aber angenommen ich bin gerade in /root und will /root/logdump.tar.gz teilen. Dann ist alles offen (auch ohne dir listing kann jemand mit richtigem Timing Dateien lesen)... oops.
Es geht ja gerade darum Dateikopien etc zu verhindern. Mit gpg kann ich die Datei lesen, verschlüsseln und in den socket pipen. Am anderen Ende lese ich vom socket und pipe wieder in gpg und dann direkt in eine Datei.

Man kann den http.server trotzdem nutzen, muss sich aber seinen eigenen http.server.BaseHTTPRequestHandler schreiben damit er nur Anfragen auf einen ganz bestimmten magischen Pfad annimmt und dann eine spezielle Datei ließt und ausliefert.

[mat6937]

..., muss sich aber seinen eigenen http.server.BaseHTTPRequestHandler schreiben damit er nur Anfragen ...

Du könntest auch droopy mit den Optionen -d, --dl, --ssl benutzen/testen:

https://manpages.debian.org/bullseye/dr ... .1.en.html

Code: Alles auswählen

apt show droopy

[JTH]

Wenn ich das so richtig verstanden hab, geht es „nur“ um eine einzelne, verschlüsselte Übertragung, ohne extra Setup und möglichst mit „Bordmitteln“? Letzteres versteh ich mal als Pakete mit Priorität standard und höher oder solche, die darüber hinaus meist installiert sind.

Wie wäre es mit (als grobes Beispiel)

Code: Alles auswählen

gpg -cq -o- --batch --passphrase=s3cr3tp4ssw0rd FILE | netcat -l -p 12345 -q0

auf Sendeseite und

Code: Alles auswählen

netcat -w1 HOST 12345 | gpg -a -dq --batch --passphrase=s3cr3tp4ssw0rd >FILE

auf Empfangsseite?

Die Passphrase kann man, wenn gewünscht, natürlich nicht hartkodieren. Die --passphrase-Option selbst ist nicht die empfehlenswerteste, aber für den Zweck hier, finde ich, vertretbar.

[uname]

Die Datei in ein http zugänglichen Ordner kopieren ist möglich, aber schwierig (zB Datei zu groß)

Wenn die Datei z. B. im Ordner /root ist und dieser auf der gleichen Partition wie / ist, könntest du einen Ordner /webserverroot anlegen, diesen (dauerhaft) mit Ausführungsrechte/Leserechte für alle (inkl. www-data) ausstatten und in Apache2 irgendwie einbinden (symbolischer Link, Subdomain, ...). Nun kannst du einfach die (große) Datei in den Ordner schieben anstatt kopieren. Ohne den Namen zu kennen, wird man die Datei auch nicht zufällig finden. Ist aber in dem Fall nur eine TLS/SSL-Transportverschlüsselung bei einem SSL-Webserver.

[reox]

Wenn ich das so richtig verstanden hab, geht es „nur“ um eine einzelne, verschlüsselte Übertragung, ohne extra Setup und möglichst mit „Bordmitteln“? Letzteres versteh ich mal als Pakete mit Priorität standard und höher oder solche, die darüber hinaus meist installiert sind.

Genau und so wie du das skizziert hast hab ich es sogar schonmal verwendet - nur ohne gpg.

Die Datei in ein http zugänglichen Ordner kopieren ist möglich, aber schwierig (zB Datei zu groß)

Wenn die Datei z. B. im Ordner /root ist und dieser auf der gleichen Partition wie / ist, könntest du einen Ordner /webserverroot anlegen, diesen (dauerhaft) mit Ausführungsrechte/Leserechte für alle (inkl. www-data) ausstatten und in Apache2 irgendwie einbinden (symbolischer Link, Subdomain, ...). Nun kannst du einfach die (große) Datei in den Ordner schieben anstatt kopieren. Ohne den Namen zu kennen, wird man die Datei auch nicht zufällig finden. Ist aber in dem Fall nur eine TLS/SSL-Transportverschlüsselung bei einem SSL-Webserver.

Ja auch eine Lösung aber das ist eben nicht "fire and forget". Wenn ich ein Script hab, welches genau einen Nutzer die Datei herunterladen lässt UND die Datei an Ort und Stelle unverändert lässt, muss ich mir keine Gedanken machen ob noch irgendwo irgendwas herumliegt.

Du könntest auch droopy mit den Optionen -d, --dl, --ssl benutzen/testen:

https://manpages.debian.org/bullseye/dr ... .1.en.html

Ah, wieder was gelernt, Danke! Das schaut ebenfalls sehr brauchbar aus, zB um von einem Livesystem Logs abzulegen. Genau sowas hatte ich mal gebraucht als ich Hardware getestet habe und die Logs vom grml live auf meine Workstation übertragen wollte... Schlussendlich dann doch per ssh aber so ein upload ist natürlich auch cool.

Ich hab gestern Abend noch mit dem http.server herumgespielt - einen eignen RequestHandler schrieben ist nicht so schwer, aber irgendwie klappt das mit SSL nicht 100%. curl meint immer ein EOF zu bekommen wo es keins erwartet. Außerdem versteh ich nicht, wieso curl den public key pin nicht verifizieren kann. Offenbar wird der von der ssl implementierung nicht übertragen? Dafür wäre es aber wert einen neuen Thread aufzumachen - ist schon ein wenig ein anderes Problem.

[QT]

Keine Ahnung, ob es wirklich genau das abdeckt, was Du suchst, aber schau Dir mal fex und fex-utils an. Das ist der "Nachfolger" von sendfile.

Fex
http://fex.rus.uni-stuttgart.de/

Fex Service den man nach Registrierung nutzen kann:
https://fex.belwue.de/fup

Sendfile
https://fex.belwue.de/saft/sendfile.html

[Patsche]

Muss es https sein?
Was ist denn mit einem sftp Server? openssh-sftp-server
Das wäre auch eine Möglichkeit.....
Habe ich selbst aber noch nicht getestet.

[uname]

Ja auch eine Lösung aber das ist eben nicht "fire and forget"

Die sehr weit oben von mir genannte Lösung PrivateBin hat eine Funktion "Burn after reading" bzw. "Nach dem Lesen löschen". Es lassen sich auch Dateien anhängen, funktioniert aber eher scchlecht und nicht für große Dateien. Außerdem löst du damit viele der anderen Probleme nicht.

[Meillo]

Soweit ich das sehe, gibt es zwei Arten von Loesungsvorschlaegen:

1) Auf dem Rechner A einen Serverprozess starten, der die Datei anbietet. Client B holt die Datei von A am entsprechenden Port ab.

2) Die Datei von Rechner A auf einen separaten Rechner C kopieren. Auf C laeuft irgendein File-Austausch-Server. Client B holt die Datei von C ab.


@reox:
- Kommt (2) ueberhaupt in Frage?
- Gibt es mehrere Rechner A oder genau einen?
- Gibt es mehrere Clients B oder genau einen?

[Blackbox]

Vielleicht ist Retroshare etwas, was deinen Anforderungen entspricht?
Das ist ein P2P-Filesharing Tool mit Chatfunktion (oder umgekehrt), der für alle wichtigen Plattformen bereitsteht.
Und ja, das ist freie Software.

[reox]

Ich hab mal was zusammengeschustert: https://github.com/reox/easysecureshare
Es ist aber nur ein Proof of Concept Funktionieren tut es aber prinzipiell!

[reox]

Ich hab mal was zusammengeschustert: https://github.com/reox/easysecureshare
Es ist aber nur ein Proof of Concept Funktionieren tut es aber prinzipiell!

Hat sich das mal wer angeschaut?^^ Nach so viele Tipps ist es ziemlich ruhig geworden
Ich kann aber immer noch nicht so recht glauben, dass es genau sowas nicht schon vorher gegeben hätte...