Przesyłanie plików przez serwer zewnętrzny na inny serwer/urzadzenie/cos

pytanie do znawców sieci :P sam jeszcze nie wiem jak to szczegółowo opisać, ale czy możliwe jest we względnie prosty sposób przesłanie pliku z jednego serwera na jakiś inny (czy serwer, czy tablet, laptop, smartfon itp) przez siec www?

tzn wiem, że to możliwe - do tej pory robiłem to przez np scp, ale chodzi mi raczej o ilość konfiguracji. Jak bardzo można ten proces zautomatyzować?

inaczej: co musiałby zrobić "odbiorca" zeby "wysylajacy" mogl mu wyslac plik? jakaś minimalna, niezbędna ilość kroków

Mam nadzieje, że wiecie o co mi chodzi :)

Przez sieć www, znaczy się na porcie 80? To takim przypadku scp to przecież prawie zero konfiguracji. Serwer stawia sshd na porcie 80, a klient scp się łączy i pobiera plik albo klient pcha scpem plik na serwer.

@mlyszczek tak mi sie napisało przez siec www ;)

szyfrowane to byc jakos specjalnie nie musi bo te pliki nie są jakieś poufne. ważne zeby nikt nikomu nic nie namieszał (nie dostal sie do "wysylajacego" albo "odbiorcy") i to wystarczy

z racji ze scp dziala przy uzyciu ssh, przy pierwszym polaczeniu dostajemy coś takiego: (skopiowane z SO):

The authenticity of host '111.222.333.444 (111.222.333.444)' can't be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)? 

ztcw można to pytanie zautomatyzowac dając flage: -o "StrictHostKeyChecking no"
i tu pytanie: ile takich grzybków po drodze może wystąpić?

chodzi mi o sytuacje gdzie klient nic sam nie robi. to serwer coś wysyła klientowi kiedy on.. powiedzmy ze "nie wie". klient ma nic nie akceptowac, nie klikac, nie pobierac tylko otrzymac plik jak serwer bedzie chciał mu wysłać. czyli cos na zasadzie

na serwerze tj "wysylajacy":

scp nazwapliku.txt user@ipOdbiorcy

jedyna operacją jaka chcialbym zrobic u "odbiorcy" jest otwarcie ssh na porcie xxx i tyle

A to musi być ssh? Bo przeciez plik można wysłać po prostu na pałe socketami i tyle. U klienta stawiasz demona który odbiera dane i zrzuca na dysk i tyle ;]

hmm no teoretycznie nie musi byc ssh ale chciałbym uniknąć tworzenia aplikacji po stronie klienta, choć może to ma sens..
a czy używając socketów i tak nie bede uzywal SSH? pewnie istnieje jakis sposób zaszyfrowania socketu i stawiam ze jedna z opcji jest ssh

poczytam, a jak masz chwile i doswiadczenie z tym napisz coś więcej :)

Jak używałbyś zwykłego socketu to nie potrzebujesz ssh. Na pałę to i netcat się nadaje do wysyłania plików, jeden nasłuchuje, drugi wysyła i pipem pliki się przekazuje. No ale takie zastosowanie jest problematyczne, bo nie masz ŻADNEJ autentykacji i musisz pisać coś swojego, a to może być dziurawe.

Możesz zrobić też tak. Odbiorca, który ma defacto nic nie robić, postawi u siebie serwer sshd, i potem Ty jako klient, pchasz pliki do serwera sshd po scp. I wtedy nadawca się pierdzieli z kluczami. No ale to ma minus ten, że każdy odbiorca musi mieć serwer - dość słabe rozwiązanie.

Pytanie: ile tych klientów jest? Czy klienci się zmieniają? Klucz wystarczy dodać tylko raz, a potem już żadnych haseł i żadnego potwierdzenia nie ma, wszystko leci bez interakcji.

Bez szyfrowania, zawsze jest opcja namieszania, chociażby taki man in the middle attack.

to przez sockety mozna duzo nabroic? przechwytując plik po drodze i coś "brudząc" tam :P
przemyslalem to i chyba jednak to musi byc szyfrowane zeby uniknac sytuacji ze ktos przechwyci właśnie plik, podmieni go na swoj i przekaże do klienta jakiś syf

właśnie myśle, że posiadanie serwera przez klienta to najlepsza opcja - bo nie jest to specjalnie skomplikowane, a szyfrowane

co do klientow:
ciężko powiedziec, może byc ich kilkunastu, kilkudziesięciu, a może dużo więcej (w pozniejszym czasie). wstępnie chciałbym obsłużyć powiedzmy kilkunastu. czy zmienni.. klienci będa dodawani podczas zycia aplikacji
czy będe mógł uzywac kluczy SSH to jeszcze nie wiem, ale to chyba nie gra wiekszej roli czy bede sie autoryzowal kluczem czy username/password

Jak każdy "klient" ma zewnętrzne IP to możesz się pokusić o to, aby każdy miał sshd postawione. Przy ssh możesz sobie podmontować sshfs w systemie i potem po prostu kopiować plik np do /mnt/client1/project. W sensie, klienci mają sshd, a Ty na swoim serwerze masz każdego klienta podmontowanego. Wtedy możesz nawet skryptem kopiować do wielu komputerów jednocześnie (po scp też możesz, ale tak łatwiej).

tylko jeszcze jedna kwestia
jak przesylam coś przez scp 1 raz na klienta do którego jeszcze nie wysyłałem nic, mimo ze do known_hosts dodane jest ip klienta to dostaje komunikat:

The server's host key is not cached. You have no guarantee
that the server is the computer you think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 1029 56:65:51:b6:4e:5f:63:e9:6b:0c:d8:9d:g2:c1:46:54
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) 

da sie go uniknac? (btw tu uzywam pscp zamiast scp)

a juz poza ssh i scp: jaki jeszcze inne podejscie do tematu mógłbym uzyc? rozumiem że sockety (ale to nie do konca bezpieczne?), mowisz cos o netcat(nigdy tego nie uzywalem), pewnie telnet ale to juz wole ssh, jeszcze jakies alternatywy?
w razie gdyby server ssh po stronie klienta byl nie dobrym rozwiazaniem albo performance bylby zły itd

edit1
a co do zewnetrznych IP: raczej nie beda miec stalego ale zawsze zostaje dyndns czy noip

edit2
a co do serwera sshd: jak wiele wymagałaby konfiguracja? wezmy na warsztat jakis komputer z windowsem, linuxem, androida ewentualnie ios'a (odbiorcy)
na linuchu to z linii komend (ale chyba potrzebuje praw roota?)
na windowsie.. openssh pewnie bedzie wystarczajace
android.. sa jakies darmowe aplikacje tworzace serwer ssh ale nie wiem jak to dziala, zwykle sa ograniczone a wiecej jest platne; ale android to przeciez linux - mozna zainstalowac, tylko znow - chyba potrzeba roota telefonu a tego wolalbym uniknac
ios: nie wiem

nie bedzie tu trzeba otwierac jakichs portów w routerze? jesli np serwer bedzie gdzieś-tam cloud/vps pod ip np 123.123.12.12, a urzadzenie bedzie podpiete pod wifi w domu?

Aha, bo Ty chcesz kilka różnych architektur mieć załatwionych.

Ja widzę takie opcje:

Mamy O (nasz komputer) oraz C (komputery klientów)

1. Dane są kompletnie niepoufne, mamy wyrąbane czy ktoś je przejmie czy nie, chcemy jedynie bezpiecznie je posłać: Na O stawiamy serwer https i na C zasysamy pliki wgetem. Wady są takie, że zasoby są bez hasła i każdy ma do nich dostęp, zalety, kompletna przezroczystość rozwiązania

2. Każdy C ma swój sshd, pchasz pliki po scp. Słabe rozwiązanie ze względu na to, że chcesz wiele platform obsługiwać, które mogą nie mieć sshd

3. Własna sieć VPN postawiona na OpenVPN. To chyba najbardziej uniwersalne rozwiązanie. O stawia serwer openvpn a C instalują klientów, potem robimy co chcemy, nawet zwykłym socktem pchamy, bo bezpieczeństwo i szyfrowanie już po stronie openvpn mamy, wady są takie, że pierwsza konfiguracja będzie czasochłonna, postawienie openvpn na każdej maszynie potem trzeba ręcznie dodawać każdą maszynę. Zalety: maksymalne bezpieczeństwo, po konfiguracji kompletna przezroczystość, duże możliwości - montowanie nfs/smb, zrobimy wszystko tak jakbyśmy mieli firmowe LAN.

Czy do known hosts jest dodane tylko ip klienta czy cały fingerprint? W ssh nie wystarczy dodać samo ip, potrzebna jest para ip:fingerprint i wtedy jak fingerprint się zmienia (jakiś atak, jak sam nie zmieniałeś nic na serwerze) to od razu masz error od ssh i żadne ważne dane nie polecą do podstawionej maszyny.

Jeżeli serwer sshd jest za routerem (za natem) to konieczne będzie przekierowanie portu z routera do maszyny docelowej. Rozwiązanie 1 i 3 są odporne na to, bo wystarczy że tylko O ma publiczne IP.

Konfiguracja sshd polega na tym, że instalujesz sshd, generujesz fingerprint i uruchamiasz. W Linuksie każda aplikacja bindująca się na port <1023 potrzebuje uprawnień roota. Nie wiem jednak czy sshd nie tyka się jakichś systemowych warstw do tego stopnia, że musi być uruchomiony z roota.

W sumie to tylko rozwiązanie 1 można skonfigurować wszędzie bez roota. Do apache można też dodać taki globalne hasło do dostępu do serwera - ale nie wiem jak wtedy z jakimiś skryptami automatycznymi.

@mlyszczek
co masz na myśli mówiąc "architektur"?

co do 1:
dane raczej mogą być niepoufne. wymaganie jest takie zeby były bezpieczne tzn jak wysyla sie plik nazwa.txt to zeby nagle ktos nie dostał nazwa.sh z jakimiś podłymi kodami :D nie jestem przekonany czy chciałbym tworzyc aplikacje klienckie bo przypuśćmy te 4 systemy o ktorych mowilem: windows, linux, android i ios - i juz masz 4 rozne wersje.. no ale rozważam każdą z opcji, może to ma jakieś plusy

co do 2:
generalnie tak to teraz działa. urzadzenie wystawia się na jakims porcie, a "serwer" wysyla do niego plik przez scp. (tak to aktualnie wygląda, ale działa w sieci lokalnej [tylko urzadzenia podpiete "pod wifi" wystawiajace ssh są klientami]) - problem jest taki ze chcąc przenieść serwer na jakiś cloud/vps i wysłać plik do klienta podpietego pod wifi trzeba zrobic port forwarding.. a to nie jest zbyt user-friendly. konfiguracja po stronie serwera nie stanowi problemu - ale chce zeby klient musiał robić najmniej jak tylko się da i żeby najlepiej nie była to rzecz typu forwardowanie portów na routerze tylko raczej podanie hasła i loginu czy IP..

co do 3:
emm.. raz przelotem miałem do czynienia z OpenVPN'em [bylem klientem, nie konfigurowalem tego] i nie za bardzo wiem jak to działa przyznam szczerze.. mówiąc o duzej ilosci pierwszej konfiguracji masz na mysli klientów czy serwer? i czym będzie klient instalowany na urzadzeniach klientów? jakis deamon ssh, czy raczej cała aplikacja? np na androidy
poczytam o tym

btw
jak to jest.. jak mamy np tablet z LTE, czyli mamy w nim normalnie internet - to przeciez on ma publiczne IP. dlaczego jak na urzadzeniu wystawie SSH to nie moge się wtedy połączyć? [nawet z pomocą dyndns'a]

1 opcja to bezpieczne przesyłanie danych, ssl zapewnia ci, że nikt nie podmieni pliku po drodze, ale bez hasła każdy może ten plik ściągnąć. No a jak naprawdę się martwisz o integralność danych to jest jeszcze coś takiego jak openPGP, podpisujesz u siebie, wysyłasz, a potem po stronie odbiorcy porównujesz podpisy i wiesz czy plik jest integralny czy nie.

3. Z open vpn jest tak, że na serwerze instalujesz serwer openvpn, generujesz tam klucze, a u klienta instalujesz klienta openvpn (naprawdę;-)), i kopiujesz do klienta wcześniej wygenerowany klucz. Każdy klient ma osobny klucz, więc jak jakiś klient się zbuntuje czy cokolwiek złego z nim się stanie, to zawsze takiego klienta możesz zablokować po stronie serwera. To rozwiązanie jest spoko, ale może być lekkim overkillem do tego co chcesz.

Ja bym chyba poszedł w 1 opcję. serwer https i każdy klient pobiera kiedy chce, ile chce, i ma pewność, że to co pobierze na pewno będzie dobre. Dla podwójnej weryfikacji podpis kluczem pgp.

@mlyszczek poczytałem, czyli w takim razie moglbym uzyc OpenVPN'a i jak już klient polaczy sie z serwerem openvpn'a to moge przez scp sobie słać pliki (bo jak rozumiem w tunelu openvpn dostane przydzielone IP wiec bede mogl uzyc scp?)
to by załątwiło problem port forwardingu. (prosciej bedzie zaimportowac pliczek .ovpn niz klepać cos w ustawieniach rutera)

popraw mnie jesli gdzies sie myle..

i pare pytan

1. jak mocno openvpn zabije predkosc przesylania? gdzies czytalem, że spada ze 30%?
2. jak z tym LTE? (w poscie wczesniej na koncu) [jesli wiesz ;)]

co do opcji pierwszej: to jest troche bardziej skomplikowane. te pliki nie beda ciagle dostepne tylko przez chwile. akcja "z zewnatrz" spowoduje ze serwer bedzie wysylal cos klientowi - tak po krótce mówiąc

Jak będziesz miał OpenVPN to w sumie nie musisz scp używać. Wtedy nawet zwykły socket TCP się sprawdzi. OpenVPN już zajmie się szyfrowaniem i otrzymasz zamkniętą sieć, więc nie potrzebujesz też autentykacji. Przy openVPN w systemie tworzy się nowy interfejs sieciowy tun albo tap, sieć taka ma własną podsieć i pulę adresów (np 10.1.1.0/24). Z punktu widzenia aplikacji nie różni się to nic jakby do komputera podłączyć drugą kartę sieciową, która byłaby wpięta w inną sieć.

Niestety nie robiłem testów prędkości openvpn, ja mam 5 maszyn w openvpn i nigdy nie narzekałem na prędkości, ale ja mam słabe łącze:p

Co do LTE to raczej nie możesz liczyć zawsze na publiczne IP. Pomyśl ile jest telefonów/urządzeń na świecie, a ile adresów w puli IP. Nie ogarniesz tego. Bezpiecznie trzeba założyć, że telefon jest za NATem i nie ma publicznego IP.

Na https też możesz spontanicznie tworzyć i usuwać pliki - kopiujesz do np /var/ww/project/file_to_copy, ściągasz na kliencie, i usuwasz plik, plain and simple.

@mlyszczek jesli chodzi o pomysl 1) to faktycznie jest on fajny, klienci mieliby wlasne katalogi i pobierali pliki - ale jest jeden problem

tzw "klient" to nie klient wykonujacy akcje tylko urzadzenie ktore sobie stoi, leży i nikogo przy nim nie ma
to akcja z poza systemu, czyli np jakis request do serwera odpala procedure przesłania pliku na urzadzenie "klienta"

i teraz: gdyby podejsc do tego opcją 1 to klient musialby dostać request: plik jest gotowy, pobierz go - co oznaczaloby ze klienci musza odpalic np serwer na ktory przyjdzie powiadomienie. nie wydaje mi sie to dobrym pomyslem. dodatkowo - jak jeszcze na laptopie to niewieli wysiłek pewnie, tak na smartfonie trzymanie jakiegos serwera nasluchujacego w tle moze jeść baterie

SCP sie wydaje o tyle easy ze klienci nie musza nawet wiedziec ze cokolwiek do nich przyjdzie, ani niczego pobierac. po prostu nagle plik automagicznie znajduje sie na urzadzeniu

Co do 1 opcji, to masz rację. Ale SCP niczym się tutaj nie różni. Też serwer sshd w tle nasłuchuje. Ale nie ma się co bać o baterię. Funkcja listen zablokuje wątek i aplikacja pójdzie nyny (spać:p) i system wybudzi apkę, gdy coś na jego socket przyjdzie. Jak się tak nie dzieje to nie spieraj takich idiotycznych systemów:p

W takim przypadku masz rację, że serwer httpd odpada. Możesz się pokusić o te zwykłe sockety i wraz z plikiem przesyłać podpis pgp. W ten sposób zapewnisz sobie gwarancję integralności danych.

Postaw na każdym kliencie zwykły socket z listen i pchaj tam plik oraz pgp. Później tą samą apką serwerową sprawdź czy podpis pgp się zgadza, jak tak zamykasz połączenie w przeciwnym przypadku wysyłasz jakieś retry do klienta i ten przesyła raz jeszcze parę plików.

Albo w drugą stronę, klienci (telefony) mają klienta zainstalowanego i łączą się z serwerem - tylko musiałyby być cały czas połączone z serwerem (tobą), żeby serwer mógł jakiś pakiet wysłać do klienta. Pewnie potrzebny byłby też jakiś ping co jakiś czas, aby NAT nie zapomniał do kogo ruch na danym porcie przekierowywać. I w sumie to rozwiązanie może nawet więcej batki zjeść, bo zamiast po prostu słuchać, pinguje. Tego z pingami to do końca nie jestem pewien, trzeba by dobrze w NAT wejść i zobaczyć kiedy i w jakich warunkach zapomina o tym komu ma pakiety forwardować.