rsync tất cả các tập tin của máy từ xa qua SSH mà không cần người dùng root?


68

Tôi có lệnh này để sao lưu một máy từ xa. Vấn đề là tôi cần quyền root để đọc và sao chép tất cả các tập tin. Tôi không kích hoạt người dùng root vì lý do bảo mật và sử dụng sudocách Ubuntu. Tôi sẽ cần một số đường ống mát mẻ hoặc một cái gì đó để làm điều này?

rsync -chavzP --stats user@192.168.1.2:/ /media/backupdisk/myserverbackup/

3
Chỉ cần sử dụng roottài khoản ở nơi đầu tiên. sudo, đặc biệt kết hợp với NOPASSWDnhư được đề xuất trong các nhận xét, không thực sự cải thiện tính bảo mật của máy của bạn.
Martin von Wittich

Câu trả lời:


88

Tôi khuyên bạn chỉ nên sử dụng tài khoản root ở nơi đầu tiên. Nếu bạn thiết lập nó như thế này:

  • Cấu hình của bạn sshd_configtrên máy mục tiêu để PermitRootLogin without-password.
  • Sử dụng ssh-keygentrên máy kéo bản sao lưu để tạo khóa riêng SSH (chỉ khi bạn chưa có khóa SSH). Không đặt cụm mật khẩu. Google một hướng dẫn nếu bạn cần chi tiết cho việc này, sẽ có rất nhiều.
  • Nối các nội dung của /root/.ssh/id_rsa.pubmáy dự phòng vào máy đích /root/.ssh/authorized_keyscủa bạn.
  • Bây giờ máy sao lưu của bạn có quyền truy cập root vào máy mục tiêu của bạn mà không phải sử dụng xác thực mật khẩu.

sau đó thiết lập kết quả sẽ khá an toàn.


sudo, đặc biệt kết hợp với NOPASSWDnhư được đề xuất trong các nhận xét, không có lợi ích bảo mật so với việc chỉ sử dụng tài khoản root. Ví dụ đề xuất này:

thêm phần sau vào /etc/sudoerstập tin của bạn :rsyncuser ALL= NOPASSWD:/usr/bin/rsync

về cơ bản cho rsyncuserphép quyền root nào. Bạn hỏi:

@MartinvonWittich Dễ dàng có được một vỏ gốc đầy đủ vì được rsyncthực thi với sudo? Đi bộ [m] e [thông qua] mà làm ơn.

Vâng, đơn giản. Với cấu hình được đề xuất, rsyncusergiờ đây có thể chạy rsyncbằng root mà không cần hỏi mật khẩu. rsynclà một công cụ rất mạnh để thao tác các tệp, vì vậy bây giờ rsyncusercó một công cụ rất mạnh để thao tác các tệp có quyền root. Tìm cách khai thác điều này chỉ mất vài phút (đã thử nghiệm trên Ubuntu 13.04, yêu cầu dash, bashkhông hoạt động):

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:::

Như bạn có thể thấy, tôi đã tạo cho mình một vỏ gốc; whoamixác định tài khoản của tôi là root, tôi có thể tạo tập tin /etcvà tôi có thể đọc từ đó /etc/shadow. Khai thác của tôi là đặt bit setuid trên dashnhị phân; nó khiến Linux luôn chạy nhị phân đó với sự cho phép của chủ sở hữu, trong trường hợp này là root.

Có một gốc thực sự không phải là [khuyến nghị] vì lý do tốt. - redanimalwar 15 giờ trước

Không, vụng về làm việc xung quanh tài khoản root trong các tình huống hoàn toàn phù hợp để sử dụng nó không phải là lý do chính đáng. Đây chỉ là một hình thức lập trình sùng bái hàng hóa khác - bạn không thực sự hiểu khái niệm đằng sau sudo vs root, bạn chỉ áp dụng một cách mù quáng niềm tin "root là xấu, sudo là tốt" bởi vì bạn đã đọc nó ở đâu đó.

Một mặt, có những tình huống sudochắc chắn là công cụ phù hợp cho công việc. Ví dụ: khi bạn tương tác làm việc trên máy tính để bàn đồ họa Linux, giả sử Ubuntu, thì việc sử dụng sudolà ổn trong những trường hợp hiếm hoi mà đôi khi bạn cần quyền truy cập root. Ubuntu cố tình có một tài khoản root bị vô hiệu hóa và buộc bạn phải sử dụng sudotheo mặc định để ngăn người dùng luôn luôn sử dụng tài khoản root để đăng nhập. Khi người dùng chỉ muốn sử dụng, ví dụ như trình duyệt web, thì đăng nhập bằng root sẽ là một điều nguy hiểm. và do đó không có tài khoản root theo mặc định sẽ ngăn những người ngu ngốc làm điều này.

Mặt khác, có những tình huống như của bạn, trong đó một tập lệnh tự động yêu cầu quyền root đối với một cái gì đó, ví dụ để tạo bản sao lưu. Bây giờ sử dụng sudođể làm việc xung quanh tài khoản root không chỉ vô nghĩa, nó còn nguy hiểm: thoạt nhìn rsyncusertrông giống như một tài khoản không có đặc quyền thông thường. Nhưng như tôi đã giải thích, sẽ rất dễ dàng để kẻ tấn công có được quyền truy cập root đầy đủ nếu anh ta đã có rsyncuserquyền truy cập. Vì vậy, về cơ bản, bây giờ bạn có một tài khoản root bổ sung trông không giống tài khoản root nào cả, đây không phải là một điều tốt.


2
Giải thích tốt đẹp. Một lý do khác cho việc sử dụng sudo over root sẽ xảy ra trong trường hợp nhiều người có vai trò sysadmin trên máy chủ? Bằng cách này, mỗi người có thể sử dụng khóa SSH của riêng mình thay vì chia sẻ khóa SSH gốc?
Nathan S. Watson-Haigh

2
@ NathanS.Watson-Haigh bạn có thể dễ dàng đặt tất cả các khóa SSH vào /root/.ssh/authorized_keyshoặc thậm chí tạo nhiều tài khoản root với các ngôi nhà khác nhau để mỗi người dùng có thể có vỏ, nhà riêng của mình và .ssh/authorized_keys:)
Martin von Wittich

2
Bạn cũng có thể hạn chế các khóa ssh chỉ cho phép một số lệnh nhất định. Chắc chắn là một ý tưởng tốt, vì nếu bạn đang tự động hóa một cái gì đó, có thể bạn sẽ tạo các phím ssh này mà không cần bất kỳ cụm mật khẩu nào, hoặc ít nhất là chúng có thể truy cập được trong suốt thời gian máy chạy. (có nghĩa là root trên máy đó cấp quyền truy cập root trên các máy khác.)
Peter Cordes

2
Những lo ngại của Martin về việc sử dụng sudo root là hợp lệ, nhưng dường như chúng có thể được giảm thiểu bằng cách chỉ định các tham số rsync chính xác trong tệp sudoers. Theo trang man sudoers (5) trên Ubuntu: "Nếu Cmnd có các đối số dòng lệnh liên quan, thì các đối số trong Cmnd phải khớp chính xác với các đối số được đưa ra bởi người dùng trên dòng lệnh (hoặc khớp với các ký tự đại diện nếu có) . " Nếu tệp sudoers chỉ định lệnh rsync chính xác với các tùy chọn chính xác (bao gồm cả nguồn và đích), thì có vẻ như nó sẽ an toàn.

4
Một xem xét không đưa lên trước đó: sshdnói chung không không đăng nhập mà ủy quyền chính được sử dụng để kết nối với một tài khoản, vì vậy nếu bạn kết nối như bobsau đó sudo, bạn nhận được một đường mòn kiểm toán tốt hơn nếu bạn kết nối trong để roottrực tiếp với bob's quan trọng.
Bộ giải mã

71

Sử dụng --rsync-pathtùy chọn để làm cho rsynclệnh từ xa chạy với các sudođặc quyền. Lệnh của bạn sau đó sẽ là:

rsync -chavzP --rsync-path="sudo rsync" --stats user@192.168.1.2:/ .

Nếu sudonhắc bạn nhập mật khẩu, bạn phải tránh điều đó bằng cách sử dụng NOPASSWDđặc quyền với tài khoản người dùng từ xa (vô nghĩa đối với root, có thể có ý nghĩa trong các trường hợp sử dụng khác) hoặc nếu bạn không muốn làm điều đó:

  • Đảm bảo rằng tùy chọn tty_ticketsbị vô hiệu hóa cho người dùng bạn đang sử dụng, bằng cách chạy ví dụ sudo visudo -f /etc/sudoers.d/local-rsync và nhập:

    Defaults:your.username.for.rsync !tty_tickets
    
  • Đảm bảo rằng tùy chọn requirettybị tắt cho người dùng bạn đang sử dụng - nó có thể bị tắt theo mặc định. Phương pháp tương tự như trên.

  • Hạt giống sudomật khẩu trên máy từ xa, bằng cách chạy ví dụ ssh -t user@192.168.1.2 sudo


1
@scai mật khẩu được yêu cầu rất có thể là sudomật khẩu, không phải sshmật khẩu
umläute

2
@redanimalwar cho phép người dùng của bạn sudo /usr/bin/rsyncmà không yêu cầu cụm mật khẩu; kiểm tra man sudoerslàm thế nào để làm điều này; bạn có thể muốn tạo thêm một người dùng sao lưu cho việc này.
umläute

5
Để cho phép sudo /usr/bin/rsyncchạy mà không yêu cầu mật khẩu, hãy thêm dòng sau vào /etc/sudoerstệp của bạn : rsyncuser ALL= NOPASSWD:/usr/bin/rsyncĐiều này sẽ cho phép người dùng rsyncuser (như đã đề cập ở trên, tốt nhất là tạo người dùng sao lưu chuyên dụng) với tên người dùng bạn muốn.
M_dk

4
@M_dk bây giờ rsyncvề cơ bản luôn có quyền root; có thể rất dễ dàng để có được một vỏ gốc đầy đủ trong tài khoản đó. Tôi nghĩ rằng tốt hơn là chỉ sử dụng tài khoản root thực sự ở nơi đầu tiên.
Martin von Wittich

1
Câu trả lời không có cách nào nói về echo "password" | somethingtôi thực sự không bao giờ sử dụng điều này và đồng ý với các vấn đề bảo mật đi kèm với việc cho phép thực thi rsync (cũng không được đề xuất ở đây) là không tốt. Những gì tty_ticketstôi thực sự không có ý tưởng, dường như cần thiết và một vấn đề bảo mật. Điều này sẽ hoạt động an toàn mà không cần điều chỉnh bất cứ điều gì bằng cách chỉ chạy sodo trên ssh và sau đó thực hiện lệnh phải không? Nhưng vì tôi đã hỏi câu hỏi đó cho mục đích viết kịch bản, tôi hoàn toàn đồng ý rằng ssh dựa trên khóa mà không có pw là an toàn và đúng là phải làm. Tôi chấp nhận trả lời Martins thay thế.
redanimalwar 7/03/2015

17

Một cách đơn giản để làm điều này là sử dụng ssh-askpasschương trình đồ họa với sudo, điều này xoay quanh thực tế sudolà không được kết nối với thiết bị đầu cuối và cho phép bạn nhập mật khẩu một cách an toàn:

rsync -chavzPe 'ssh -X' --stats \
  --rsync-path='SUDO_ASKPASS=/usr/lib/ssh/x11-ssh-askpass sudo -A rsync' \
  user@192.168.1.2:/ .

Tất nhiên ssh-askpasschương trình phải được cài đặt ở vị trí đã cho và bạn phải chạy phiên X trên máy bạn đang làm việc. Có một vài biến thể trong ssh-askpasschương trình cũng sẽ hoạt động (phiên bản Gnome / KDE). Ngoài ra một sudochương trình thay thế đồ họa như gksuhoặc kdesudocũng nên làm việc.


rsync --rsh='ssh -X' --rsync-path='gksudo -- rsync' user@host:/ .không hoạt động. rsync error: syntax or usage error (code 1) at main.c(1634) [server=3.1.1]. Ồ, ubfox không gửi gnome-ssh-Askpass, nhưng nó /usr/bin/ssh-askpass, thay vì /usr/lib/ssh/x11.... Vì vậy, nó đã làm việc :)
Peter Cordes

1
Đây là một trong những giải pháp tốt hơn vì nó không cần bất kỳ cấu hình lại ở đầu bên kia - chỉ cần yêu cầu cài đặt và chuyển tiếp X được bật, cả hai đều khá phổ biến.
David Gardner

1
Hoạt động như một bùa mê sau khi cài đặt ssh-askpass. Tôi chỉ cần tìm kiếm ý nghĩa của -chavzPe, sẽ là tuyệt vời để đánh vần những điều này như là các tùy chọn dài.
krlmlr

Tôi đã thử điều này, nhưng lời nhắc đang mở trên máy từ xa và không được chuyển tiếp đến máy cục bộ. X11Forwarding đang hoạt động, hãy hỏi tôi đã xác minh bằng cách chạy xeyesbằng SSH.
Joyce Babu

7

Nếu người dùng của bạn đã có các đặc quyền sudo được bảo vệ bằng mật khẩu, tôi sẽ giữ nguyên trạng đó và chỉ thêm một khổ để sử dụng rsync mà không cần mật khẩu:

%admin ALL=(ALL) ALL
%admin ALL= NOPASSWD:/usr/bin/rsync 

5

Tôi đã gặp vấn đề này ngày hôm nay và giải quyết nó mà không cần sửa đổi các tệp cấu hình hoặc cấp quyền cấp gốc cho tài khoản người dùng. Thiết lập cụ thể của tôi là người dùng Atrên máy foophải sao chép tất cả các thư mục người dùng từ foomáy barsang backupthư mục mà người dùng Asở hữu. (Người dùng Acó quyền sudo trên foo.)

Lệnh tôi đã sử dụng ở bên dưới. Nó được gọi bởi người dùng Atrong /homethư mục trên foo.

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

Điều này chạy rsync dưới dạng sudo để foocó thể truy cập tất cả các thư mục người dùng nhưng nó báo cho rsync sử dụng ssh để truy cập máy barbằng Athông tin đăng nhập của người dùng . Nhu cầu của tôi hơi khác so với câu hỏi ở trên nhưng điều này cho phép tôi nhanh chóng có được bản sao lưu tất cả các thư mục người dùng trên một máy cụ thể mà tôi quản lý mà không cần cấu hình hệ thống.


2
Điều này thật tuyệt vời. Tôi quên mất -itùy chọn để ssh. Bạn có thể sử dụng --rsync-path="sudo /usr/bin/rsync" nếu bạn có sudo trên máy bar. Điều này sau đó không đọc root@foovà viết như root@bar, nhưng chuyển qua A@foo-> B@bar. Cảm ơn!
ctbrown

Nó sẽ không bảo vệ chủ sở hữu (ví dụ root), tôi có đúng không?
Andris

3

Chạy rsync như daemon trên máy đích cho phép bạn làm những gì bạn muốn.


1
Tôi đã đưa ra câu trả lời này, nhưng sẽ tốt hơn nếu có một số giải thích về cách chạy daemon rsynch và cách bạn sử dụng nó với quyền truy cập root.
Mike Lippert

rsync như daemon sẽ không khớp với trường hợp này, vì rsync sẽ bỏ quyền root ngay cả khi bắt đầu bằng root thì không phải tất cả các tệp đều có thể được chuyển.
teissler

2

Giải pháp của tôi là sử dụng --rsync-path="sudo rsync"nhưng nó yêu cầu mật khẩu, cách giải quyết:

rsync -chavzP --stats --rsync-path="echo <SUDOPASS> | sudo -Sv && sudo rsync"  user@192.168.1.2:/ .

1
Nó thường không phải là một ý tưởng tốt để đặt mật khẩu vào một dòng lệnh; chúng trở nên hữu hình trong cây quy trình, ví dụ. Thỉnh thoảng tôi thay thế mật khẩu thực tế trong loại câu lệnh $( cat my_password.txt )này tốt hơn một chút, nhưng thường được ưu tiên cấu hình các quyền ở hai đầu và / hoặc sử dụng các khóa SSH, theo cách mà mật khẩu không được yêu cầu trên CLI
JDS
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.