Próbuję skonfigurować chroot'd rsync

Próbuję skonfigurować serwer zapasowy. Chcę zrootować każdego użytkownika (klienta) do jego katalogu domowego i pozwolić mu tylko na używanie sftp i rsync .

Szybko odkryłem, że nie tylko ja próbowałem zrobić coś takiego, znalazłem ten przewodnik i poszedłem za nim. Więc teraz mam użytkowników chroot tylko z sftp.

Potem dowiedziałem się, że rsync potrzebuje ssh do odrodzenia się na drugiej maszynie i że sftp to za mało. Nadanie każdemu użytkownikowi loginu ssh to coś, czego chciałem przede wszystkim uniknąć.

Czy ktoś może wymyślić jakieś możliwe rozwiązania?

Dziękuję Ci,

znak

Rozwiązanie sftp wymagałoby również logowania ssh dla wszystkich, więc tak naprawdę nic tu nie straciłeś. Udzielania dostępu ssh niekoniecznie oznacza pełny dostęp do powłoki, na przykład ten pokazuje, jak używać ssh authorized_keysplik, aby umożliwić tworzenie kopii zapasowych za pomocą rsync przy jednoczesnym ograniczeniu dostępnych poleceń tylko odbiornika rsync.

W rzeczywistości, jeśli wybierzesz uwierzytelnianie oparte na kluczu zamiast uwierzytelniania za pomocą hasła (co powinieneś), możesz uruchomić wszystko na jednym koncie użytkownika zamiast wymagać wielu kont. Używałbyś kluczy do identyfikacji zdalnych użytkowników i skierowałbyś odbiornik rsync do określonego katalogu.

Coś takiego w twoim authorized_keyspliku:

command="/usr/bin/rsync --server -a . /tmp/user1" ssh-rsa ... user1
command="/usr/bin/rsync --server -a . /tmp/user2" ssh-rsa ... user2

Ktoś używający user1klucza prywatnego wykona kopię zapasową /tmp/user1, a osoba używająca user2klucza prywatnego utworzy kopię zapasową /tmp/user2. I tak dalej...

Wykonuj zwykle rsyncz klienta na serwer zdalny, ale dodaj dodatkowy pełny przełącznik SSH -v:, a następnie grep dla Sending command. Zobaczysz dokładne polecenie klienta wysyłane na zdalny serwer:

rsync -avz -e'ssh -v -i /ssh-keys/clientprivate.key' --bwlimit=8000 --delete root@server:/path/ /backup/myserver/ 2>&1 | grep "Sending command"

W moim przypadku tak było

rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /path

Dodaj to jako command="..."do /home/USER/.ssh/authorized_keyspliku serwera zdalnego , jak wspomniano w @larsks. Dodaj dodatkowe ustawienia zabezpieczeń, jeśli to konieczne:

no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

Wszyscy razem:

command="rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /backup/path",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

(Zaczerpnięte z bardzo dobrego samouczka http://en.positon.org/post/Rsync-command-restriction-over-SSH )

Musisz mieć dostęp do powłoki, aby móc korzystać z rsync, chyba że łączysz się bezpośrednio z serwerem rsync - domyślny port to 873 (TCP).

Ze strony podręcznika rysnc :

Istnieją dwa różne sposoby skontaktowania się ze zdalnym systemem przez rsync: użycie programu powłoki zdalnej jako transportu (takiego jak ssh lub rsh) lub skontaktowanie się z demonem rsync bezpośrednio przez TCP. Transport powłoki zdalnej jest wykorzystywany, gdy ścieżka źródłowa lub docelowa zawiera pojedynczy separator dwukropka (:) po specyfikacji hosta. Kontaktowanie się z demonem rsync następuje bezpośrednio, gdy ścieżka źródłowa lub docelowa zawiera podwójny dwukropek (: :) po specyfikacji hosta, LUB gdy podano adres URL rsync: // (zobacz także FUNKCJE RSYNC-DAEMON ZA POMOCĄ PILOTA ZDALNEGO) Sekcja CONNECTIONrq dla wyjątku od tej ostatniej reguły).

Aby zapewnić ograniczony dostęp do powłoki, rozważ następujący przewodnik . (Uwaga: oryginalny link nie działa) Podsumowanie:

Ta konfiguracja łączy najlepsze funkcje rsync, SSH i chroot. Rsync zapewnia elastyczność i wydajność przesyłania plików, SSH chroni przesyłane dane, a chroot chroni dane na serwerze przed nieautoryzowanym dostępem. Dummysh ogranicza dostęp tylko do rsync.

Podczas gdy serwer rsync implementuje chroot, brakuje mu często wymaganej ochrony SSH. Poza tym otwarcie dodatkowego portu serwera rsync stanowi zagrożenie dla bezpieczeństwa i czasami nie jest to możliwe ani z technicznego, ani politycznego punktu widzenia. Sftp i scp nie mają elastyczności i wydajności zapewnianej przez rsync, szczególnie gdy zaangażowane jest drzewo katalogów, takie jak strona internetowa.

Lub zapoznać się za pomocą rssh (tam jest przewodnikiem do konfigurowania rssh tutaj ):

rssh jest ograniczoną powłoką do użytku z OpenSSH, pozwalającą tylko na scp i / lub sftp. Obejmuje teraz także obsługę rdist, rsync i cvs. Na przykład, jeśli masz serwer, który chcesz tylko zezwalać użytkownikom na kopiowanie plików za pośrednictwem scp, bez zapewniania dostępu do powłoki, możesz użyć do tego rssh.

możesz napisać powłokę, która otacza rsync.

spójrz na ogólny pomysł tutaj: https://sixohthree.com/1458/locking-down-rsync-using-ssh

w swojej owijającej skorupie możesz robić, co chcesz i być może chrootować użytkownika.

W moim przypadku musiałem włączyć konto wirtualne przy użyciu tego samego użytkownika * nix. Udaje mi się to za pomocą tego rodzaju powłoki oraz wielu wierszy w pliku autoryzowanych_kluczy. Nie chrootowałem użytkownika, ale dodałem poziom folderu użytkownika w poleceniu serwera rsync.

spojrzeć na użytkownika procesu inaczej, używając klucza ssh

SFTP z funkcjami Rsync, bez powłoki

Możesz używać LFTP + SFTP w środowisku chroot i osiągać takie same wyniki jak przy użyciu rsync, bez dostarczania użytkownikowi powłoki lub robienia ciężkich dostosowań w ssh za pomocą wrapperów.

Jest to bezpieczniejsze i może być znacznie szybsze.

Rsync w chroocie jest trudny :) Musisz skonfigurować minimalne środowisko dla / bin / sh i / usr / bin / rsync w katalogu chrootowanym (po stronie docelowej), aby działało.

Zobacz cały artykuł tutaj, konfiguracja środowiska rsync jest do końca
https://medium.com/@deltazero/linux-remote-backup-rsync-chroot-d797ba6babe5