Jak wykonać bezpieczną synchronizację między serwerami w niezabezpieczonej sieci

Zasadniczo pytam, czy ktoś znalazł sposób na zawinięcie rsync w ssh.

Z OpenSSH v4.9 + sftp ma kilka fajnych opcji, które pozwalają na chrootowanie połączenia przychodzącego i takie - i to jest rozwiązanie, na które bym się przyjrzał, jednak utknąłem z RHEL, i ani RHEL4, ani RHEL5 nie są w stanie zaktualizować tej wersji ssh.

Moje obecne rozwiązanie polega na dodaniu czegoś takiego po stronie serwera za pomocą klucza użytkownika klienta ...

serwer% cat ~ / .ssh / Author_keys
polecenie = "cd / srv / rsync / etl && tar --exclude './lost+found' -pcf - ./" ssh-rsa ...

... a więc klient byłby wtedy ograniczony do jednej i tylko jednej rzeczy ...

klient% ssh -T -i $ {HOME} /. ssh / id_rsa oracle@database.com> sensative.tar

Zabezpiecza to połączenie, a także serwer (od klienta), jednak jest nieefektywne, ponieważ wszystkie pliki będą pobierane w kółko.

Po zrobieniu czegoś podobnego (lub po prostu lepszego) przy użyciu rsync.

— Kserkses
źródło

Odpowiedzi:

Rsync obsługuje używanie ssh jako transportu

rsync -az /path/to/source username@host:/path/to/destination

niektóre starsze wersje rsync wymagają jawnego określenia ssh

rsync -aze ssh /path/to/source host:/path/to/destination

Alternatywą dla używania rsync jest BC Pierce's Unison , który ma podobną funkcjonalność do rsync, ale utrzymuje indeks lokalny na obu końcach, aby uniknąć konieczności przejścia systemu plików do obliczania delt

— Dave Cheney
źródło

Dziekuje za szybką odpowiedź! Powinienem wspomnieć, że ja też to zbadałem - problemem (w moim przypadku) jest to, że nie ogranicza / chrootuje użytkownika. Gdyby można było porozmawiać z usługą rsync przez ssh (tj. Używając składni dwukropka definiowania pilota) - byłoby idealnie - ale powyższe działa tylko z pojedynczym dwukropkiem - tj. Przez ssh, a zatem bez chrootowania.

— Kserkses

Zapomniałem wspomnieć - Unison wygląda ładnie i zachowam link do niego - jednak w tym przypadku - nie jestem w stanie zainstalować niczego poza tym oferowanym przez RHN - co jest kiepskie, ale poza moją kontrolą.

— Kserkses

Kolejnym ograniczeniem, o którym powinienem wspomnieć, jest to, że połączenie musi być inicjowane przez klienta - stronę <i> pull </i>, a nie serwer. (Push po stronie serwera byłoby oczywiście łatwe do zabezpieczenia serwera, ponieważ klient nie ma nic do powiedzenia, ale nie dotyczy mojego obecnego problemu).

— Kserkses

rsync -az server: / path / path / on / client?

— Dave Cheney

Dlaczego chroot? Wiesz, że chroot tak naprawdę nie poprawia bezpieczeństwa. Ponadto, jeśli już wychodzisz, udostępniając ssh, rsync over ssh nie zmniejsza bezpieczeństwa systemu. Pomyśl także, że to, co robi rsync nad ssh, wywołuje plik binarny rsync na serwerze. Możesz zabezpieczyć to w ten sam sposób, w jaki zabezpieczasz swoje polecenie kopiowania.

— Paul de Vrieze

Okej, w końcu to wymyśliłem, ale rozwiązanie nie jest tak eleganckie, jak się spodziewałem.

Po stronie serwera należy dodać następujące informacje do pliku uprawniony_klucz dla odpowiedniego użytkownika ...

no-pty, command="exit"

Na kliencie możesz następnie utworzyć tunel w następujący sposób ...

ssh -l username -fNTL 8073:server:873

Po ustanowieniu tunelu możesz rsync jak zwykle - przy użyciu składni dwukropka nie jest możliwe - na localhost.

Numer portu localhost wybrania (8073) są całkowicie opcjonalne oczywiście, ale należy pamiętać, że to, co masz do rsync do ...

rsync --port=8073 -a user@localhost::mySecureStore /srv/some/place/

— Kserkses
źródło

Możesz być zainteresowany trybem demona przez ssh, który jest przedmiotem tego pytania:

Nie można zmusić rsync do działania w trybie daemon-over-ssh

— rjmunro
źródło