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 user@192.168.1.2:/ /media/backupdisk/myserverbackup/
Odpowiedzi:
Radzę, abyś po prostu używał konta root. Jeśli skonfigurujesz to w ten sposób:
sshd_configkomputer docelowy na PermitRootLogin without-password.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./root/.ssh/id_rsa.pubkomputera kopii zapasowej do /root/.ssh/authorized_keyskomputera docelowego.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ą.
/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:)
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.
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 user@192.168.1.2:/ .
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 user@192.168.1.2 sudo
sudohasło, a nie sshhasła
sudo /usr/bin/rsyncbez pytania o hasło; sprawdź, man sudoersjak to zrobić; możesz w tym celu utworzyć dodatkowego użytkownika kopii zapasowej.
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.
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.
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.
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' \
user@192.168.1.2:/ .
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ć.
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 :)
ssh-askpass. Musiałem po prostu sprawdzić znaczenie -chavzPe, świetnie byłoby przeliterować je jako długie opcje.
xeyesużywając SSH.
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
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.
-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!
Uruchomienie rsync jako demona na maszynie docelowej pozwala ci robić, co chcesz.
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" user@192.168.1.2:/ .
$( 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
rootkonta.sudo, szczególnie w połączeniu zNOPASSWDzaleceniami zawartymi w komentarzach, tak naprawdę nie poprawia bezpieczeństwa komputera.