synchronizować wszystkie pliki zdalnego komputera przez SSH bez użytkownika root?

68

Mam to polecenie, aby wykonać kopię zapasową zdalnego komputera. Problem polega na tym, że potrzebuję praw root, aby czytać i kopiować wszystkie pliki. Nie mam włączonego użytkownika root ze względów bezpieczeństwa i używam sudoUbuntu. Czy potrzebuję fajnej instalacji rurowej lub czegoś takiego?

rsync -chavzP --stats [email protected]:/ /media/backupdisk/myserverbackup/
redanimalwar
źródło
3
Po prostu skorzystaj z rootkonta. sudo, szczególnie w połączeniu z NOPASSWDzaleceniami zawartymi w komentarzach, tak naprawdę nie poprawia bezpieczeństwa komputera.
Martin von Wittich,

Odpowiedzi:

88

Radzę, abyś po prostu używał konta root. Jeśli skonfigurujesz to w ten sposób:

  • Skonfiguruj swój sshd_configkomputer docelowy na PermitRootLogin without-password.
  • Użyj ssh-keygenna komputerze, który pobiera kopię zapasową, aby utworzyć klucz prywatny SSH (tylko jeśli nie masz jeszcze klucza SSH). Nie ustawiaj hasła. Google samouczek, jeśli potrzebujesz szczegółowych informacji na ten temat, powinno być dużo.
  • Dołącz zawartość /root/.ssh/id_rsa.pubkomputera kopii zapasowej do /root/.ssh/authorized_keyskomputera docelowego.
  • Teraz twoja maszyna kopii zapasowej ma dostęp do roota na maszynie docelowej, bez konieczności używania uwierzytelniania hasłem.

wynikowa konfiguracja powinna być całkiem bezpieczna.


sudo, szczególnie w połączeniu z NOPASSWDzaleceniami zawartymi w komentarzach, nie ma żadnych korzyści w zakresie bezpieczeństwa, niż samo używanie konta root. Na przykład ta sugestia:

dodać następujące wpisy do /etc/sudoerspliku:rsyncuser ALL= NOPASSWD:/usr/bin/rsync

zasadniczo i tak daje rsyncuseruprawnienia roota. Ty pytasz:

@MartinvonWittich Łatwo uzyskać pełną powłokę roota, ponieważ jest rsyncwykonywana za pomocą sudo? Przejdź [m] e [przez] to proszę.

Cóż, proste. Przy zalecanej konfiguracji rsyncusermoże teraz działać rsyncjako root, nawet bez pytania o hasło. rsyncjest bardzo potężnym narzędziem do manipulowania plikami, więc teraz rsyncuserma bardzo potężne narzędzie do manipulowania plikami z uprawnieniami administratora. Znalezienie sposobu na wykorzystanie tego zajęło mi tylko kilka minut (przetestowane na Ubuntu 13.04, wymaga dash, bashnie działa):

martin@martin ~ % sudo rsync --perms --chmod u+s /bin/dash /bin/rootdash
martin@martin ~ % rootdash
# whoami
root
# touch /etc/evil
# tail -n1 /etc/shadow
dnsmasq:*:15942:0:99999:7:::

Jak widać, stworzyłem sobie powłokę roota; whoamiidentyfikuje moje konto jako root, mogę tworzyć pliki /etci czytać /etc/shadow. Moim wyczynem było ustawienie bitu setuid na plikudash binarnym; powoduje, że Linux zawsze uruchamia ten plik binarny z uprawnieniami właściciela, w tym przypadku root.

Posiadanie prawdziwego roota nie jest [zalecane] z dobrych powodów. - redanimalwar 15 godzin temu

Nie, niezdarne obejście konta roota w sytuacjach, w których absolutnie właściwe jest jego używanie, nie ma dobrych powodów. Jest to kolejna forma programowania kultowego ładunku - tak naprawdę nie rozumiesz koncepcji sudo kontra root, po prostu ślepo stosujesz przekonanie, że „root jest zły, sudo jest dobry”, ponieważ gdzieś to przeczytałeś.

Z jednej strony zdarzają się sytuacje, w których sudozdecydowanie jest odpowiednie narzędzie do pracy. Na przykład, gdy pracujesz interaktywnie na graficznym pulpicie Linuxa, powiedzmy Ubuntu, wtedy korzystanie z niego sudojest w porządku w tych rzadkich przypadkach, w których czasami potrzebujesz dostępu do roota. Ubuntu celowo ma wyłączone konto root i zmusza cię do sudodomyślnego używania , aby uniemożliwić użytkownikom korzystanie z konta root tylko po to, aby się zalogować. Gdy użytkownik chce tylko użyć np. Przeglądarki internetowej, zalogowanie się jako root byłoby niebezpieczne. , a zatem brak domyślnego konta root uniemożliwia głupcom to zrobić.

Z drugiej strony istnieją sytuacje takie jak Twoja, w których zautomatyzowany skrypt wymaga uprawnień roota do czegoś, na przykład do wykonania kopii zapasowej. Teraz korzystanie sudoz obejścia konta root jest nie tylko bezcelowe, ale także niebezpieczne: na pierwszy rzut oka rsyncuserwygląda jak zwykłe konto nieuprzywilejowane. Ale jak już wyjaśniłem, atakującemu bardzo łatwo byłoby uzyskać pełny dostęp do konta root, gdyby już uzyskał rsyncuserdostęp. Zasadniczo masz teraz dodatkowe konto root, które wcale nie wygląda jak konto root, co nie jest dobrą rzeczą.

Martin von Wittich
źródło
2
Ładne wyjaśnienie. Czy kolejnym powodem korzystania z sudo w systemie root byłaby sytuacja, w której wiele osób pełni role sysadmin na serwerze? W ten sposób każdy może użyć własnego klucza SSH zamiast współdzielić klucz SSH roota?
Nathan S. Watson-Haigh
2
@ NathanS.Watson-Haigh możesz równie łatwo włożyć wszystkie klucze SSH /root/.ssh/authorized_keys, a nawet utworzyć wiele kont root z różnymi domami, aby każdy użytkownik mógł mieć swoją własną powłokę, dom i .ssh/authorized_keys:)
Martin von Wittich
2
Możesz ograniczyć klucze ssh do zezwalania tylko na niektóre polecenia. Zdecydowanie dobry pomysł, ponieważ jeśli coś automatyzujesz, prawdopodobnie utworzysz te klucze ssh bez żadnego hasła, a przynajmniej będą one dostępne przez cały czas działania maszyny. (co oznacza, że ​​root na tym komputerze zapewnia dostęp do roota na innych komputerach).
Peter Cordes,
2
Obawy Martina dotyczące korzystania z sudo root są prawidłowe, ale wydaje się, że można je złagodzić, określając dokładne parametry rsync w pliku sudoers. Według strony podręcznika sudoers (5) w systemie Ubuntu: „Jeśli Cmnd ma skojarzone argumenty wiersza poleceń, wówczas argumenty w Cmnd muszą dokładnie odpowiadać argumentom podanym przez użytkownika w wierszu poleceń (lub dopasować symbole wieloznaczne, jeśli takie istnieją) . ” Jeśli plik sudoers określa dokładne polecenie rsync z dokładnymi opcjami (w tym źródłowymi i docelowymi), wydaje się, że powinno być bezpieczne.
4
Jednym czynnikiem nie wychował wcześniej: sshdna ogół nie nie zalogować, które zezwoliło klucz był używany do łączenia się z kontem, więc jeśli połączyć jak bobwtedy sudo, dostać lepszą ścieżkę audytu niż w przypadku łączenia się, by rootbezpośrednio z bob„s klucza.
Coderer
71

Skorzystaj z --rsync-pathopcji, aby zdalne rsyncpolecenie działało z sudouprawnieniami. Twoje polecenie powinno wówczas brzmieć np .:

rsync -chavzP --rsync-path="sudo rsync" --stats [email protected]:/ .

Jeśli sudopojawi się monit o podanie hasła, musisz tego uniknąć, używając NOPASSWDprzywileju na zdalnym koncie użytkownika (bezcelowe dla użytkownika root, może mieć sens w innych przypadkach użycia) lub jeśli nie chcesz tego robić:

  • Upewnij się, że opcja tty_ticketsjest wyłączona dla użytkownika, którego używasz, uruchamiając np. sudo visudo -f /etc/sudoers.d/local-rsync I wprowadzając:

    Defaults:your.username.for.rsync !tty_tickets
    
  • Upewnij się, że opcja requirettyjest wyłączona dla użytkownika, którego używasz - może być domyślnie wyłączona. Metoda jest taka sama jak powyżej.

  • Zaszczep sudohasło na zdalnym komputerze, uruchamiając np ssh -t [email protected] sudo

M_dk
źródło
1
@scai hasło, które jest proszony o to najprawdopodobniej sudohasło, a nie sshhasła
umläute
2
@redanimalwar pozwala użytkownikowi sudo /usr/bin/rsyncbez pytania o hasło; sprawdź, man sudoersjak to zrobić; możesz w tym celu utworzyć dodatkowego użytkownika kopii zapasowej.
umläute
5
Aby zezwolić sudo /usr/bin/rsyncna uruchomienie bez konieczności podawania jako hasła, dodaj do /etc/sudoerspliku następujące informacje: rsyncuser ALL= NOPASSWD:/usr/bin/rsyncPozwoli to użytkownikowi rsyncuser (jak wspomniano powyżej najlepiej byłoby utworzyć dedykowanego użytkownika kopii zapasowej) z żądaną nazwą użytkownika.
M_dk
4
@M_dk teraz rsynczasadniczo zawsze ma uprawnienia roota; prawdopodobnie bardzo łatwo jest uzyskać pełną powłokę root na tym koncie. Myślę, że lepiej jest po prostu użyć prawdziwego konta root.
Martin von Wittich,
1
Odpowiedź w żaden sposób nie mówiąc o tym, echo "password" | somethingże tak naprawdę nigdy tego nie użyłem i zgadzam się z problemami bezpieczeństwa związanymi z zezwalaniem na szybkie uruchamianie rsync (również tutaj nie sugerowane) jest złe. Co tty_ticketswłaściwie nie mam pojęcia, wydaje się potrzebne i kwestia bezpieczeństwa. To działałoby bezpiecznie, nie zmieniając niczego, po prostu uruchamiając sodo na ssh, a następnie wykonując polecenie, prawda? Ale skoro zadałem to pytanie w celu skrypty, całkowicie zgadzam się, że ssh oparty na kluczach bez pw jest bezpieczny i słuszny. Zamiast tego zaakceptowałem odpowiedź Martinsa.
redanimalwar
17

Jednym prostym sposobem na to jest użycie ssh-askpassprogramu graficznego , dzięki sudoczemu sudomożna obejść fakt, że nie jest on podłączony do terminala i pozwala bezpiecznie wprowadzić hasło:

rsync -chavzPe 'ssh -X' --stats \
  --rsync-path='SUDO_ASKPASS=/usr/lib/ssh/x11-ssh-askpass sudo -A rsync' \
  [email protected]:/ .

Oczywiście ssh-askpassprogram musi być zainstalowany w podanej lokalizacji i musisz uruchomić sesję X na komputerze, na którym pracujesz. Istnieje kilka wariantów ssh-askpassprogramu, które również powinny działać (wersje Gnome / KDE). Również graficzny sudoprogram zastępujący, taki jak gksulub kdesudopowinien również działać.

Graeme
źródło
rsync --rsh='ssh -X' --rsync-path='gksudo -- rsync' user@host:/ .nie działa rsync error: syntax or usage error (code 1) at main.c(1634) [server=3.1.1]. Och, Ubuntu dostarcza gnome-ssh-askpass, ale tak jest /usr/bin/ssh-askpasszamiast /usr/lib/ssh/x11.... Tak to działało :)
Peter Cordes,
1
Jest to jedno z lepszych rozwiązań, ponieważ nie wymaga żadnej rekonfiguracji na drugim końcu - wystarczy zainstalować askpass i włączyć przekazywanie X, które powinny być dość powszechne.
David Gardner
1
Po zainstalowaniu działa jak urok ssh-askpass. Musiałem po prostu sprawdzić znaczenie -chavzPe, świetnie byłoby przeliterować je jako długie opcje.
krlmlr
Próbowałem tego, ale monit otwiera się na komputerze zdalnym i nie jest przekierowywany na komputer lokalny. X11 Forwarding działa oczekiwany zapytaj, który zweryfikowałem, xeyesużywając SSH.
Joyce Babu
7

Jeśli twój użytkownik ma już uprawnienia sudo, które są chronione hasłem, zachowałbym je w stanie, w jakim się znajdują, i dodałem tylko sekcję, aby używać rsync bez hasła:

%admin ALL=(ALL) ALL
%admin ALL= NOPASSWD:/usr/bin/rsync 
Gunnar Thielebein
źródło
5

Zetknąłem się dzisiaj z tym problemem i rozwiązałem go bez potrzeby modyfikowania plików konfiguracyjnych lub przyznawania uprawnień na poziomie root do kont użytkowników. Moja szczególna konfiguracja polegała na tym, że użytkownik Ana komputerze foomusiał skopiować wszystkie katalogi użytkownikówfoo na komputer barw backupkatalogu, który Aposiadał użytkownik . (Użytkownik Ama uprawnienia sudo foo.)

Polecenie, którego użyłem, znajduje się poniżej. Został wywołany przez użytkownikaA w /homekatalogu na foo.

sudo rsync -avu -e "ssh -i /home/A/.ssh/id_rsa -l A"  * B:/home/backup

Spowoduje to uruchomienie rsync jako sudo, aby foomożna było uzyskać dostęp do wszystkich katalogów użytkowników, ale mówi rsync, aby użył ssh, aby uzyskać dostęp do komputera barza pomocą użytkownikaA poświadczeń użytkownika. Moje potrzeby były nieco inne niż powyższe pytanie, ale pozwoliło mi to szybko uzyskać kopię zapasową wszystkich katalogów użytkowników na konkretnej maszynie, którą zarządzam, bez konieczności marnowania konfiguracji systemu.

Ken Anderson
źródło
2
To jest genialne. Zapomniałem o -iopcji ssh. Możesz użyć, --rsync-path="sudo /usr/bin/rsync" jeśli masz sudo na komputerze bar. To następnie czyta jako root@fooi pisze jako root@bar, ale przenosi przez A@foo-> B@bar. Dzięki!
ctbrown
Nie zachowa właściciela (np. Roota), mam rację?
Andris
3

Uruchomienie rsync jako demona na maszynie docelowej pozwala ci robić, co chcesz.

Konstantin
źródło
1
Poparłem tę odpowiedź, ale lepiej byłoby wyjaśnić, jak uruchomić demona rsynch i jak go używać z dostępem do roota.
Mike Lippert,
rsync jako demon nie pasowałby do tego przypadku, ponieważ rsync porzuci uprawnienia root'a nawet po uruchomieniu jako root, wtedy nie wszystkie pliki mogą zostać przesłane.
teissler,
2

Moim rozwiązaniem jest użycie, --rsync-path="sudo rsync"ale wymaga podania hasła, obejście:

rsync -chavzP --stats --rsync-path="echo <SUDOPASS> | sudo -Sv && sudo rsync"  [email protected]:/ .
Bulat
źródło
1
Zazwyczaj umieszczanie haseł w linii poleceń nie jest dobrym pomysłem; stają się widoczne na przykład w drzewie procesów. Czasami zastępuję rzeczywiste hasło tego typu instrukcją, $( cat my_password.txt )która jest nieco lepsza, ale zwykle preferowane jest skonfigurowanie uprawnień po obu stronach i / lub użycie kluczy SSH, tak aby hasła nie były wymagane w interfejsie CLI
JDS