rootユーザーなしでSSH経由でリモートマシンのすべてのファイルをrsyncしますか？

リモートマシンをバックアップするこのコマンドがあります。問題は、すべてのファイルを読み取り、コピーするためにルート権限が必要なことです。セキュリティ上の理由でルートユーザーを有効にしておらずsudo、Ubuntuの方法を使用しています。これを行うには、クールなパイピングなどが必要ですか？

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

そもそもルートアカウントを使用することをお勧めします。このように設定した場合：

• sshd_configターゲットマシンでをに設定しますPermitRootLogin without-password。
• ssh-keygenバックアップを取得するマシンで使用して、SSH秘密鍵を作成します（SSH鍵がまだない場合のみ）。パスフレーズを設定しないでください。この詳細が必要な場合は、Googleでチュートリアルを作成してください。
• /root/.ssh/id_rsa.pubバックアップマシンのコンテンツを/root/.ssh/authorized_keysターゲットマシンのコンテンツに追加します。
• これで、バックアップマシンは、パスワード認証を使用することなく、ターゲットマシンへのルートアクセス権を持ちます。

その結果、セットアップはかなり安全になります。

sudo、特にNOPASSWDコメントで推奨されているように組み合わせると、ルートアカウントを使用するだけではセキュリティ上の利点はありません。たとえば、この提案：

/etc/sudoersファイルに次を追加します。rsyncuser ALL= NOPASSWD:/usr/bin/rsync

rsyncuserとにかく基本的にルート権限を付与します。あなたが尋ねる：

@MartinvonWittichでrsync実行されるため、完全なルートシェルを簡単に取得できsudoます。お願いします[m] e [through]

まあ、簡単です。推奨構成でrsyncuserはrsync、パスワードを要求されることなく、rootとして実行できるようになりました。rsyncは、ファイルを操作するための非常に強力なツールであるため、現在rsyncuser、ルート権限でファイルを操作するための非常に強力なツールがあります。これを悪用する方法を見つけるのにほんの数分しかかかりませんでした（Ubuntu 13.04でテストしましたがdash、動作bashしませんでした）：

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

ご覧のとおり、ルートシェルを作成しました。whoamiアカウントをルートとして識別し、でファイルを作成でき、/etcから読み取ることができます/etc/shadow。私の悪用は、バイナリにsetuidビットを設定することでしたdash。これにより、Linuxは常に所有者（この場合はroot）の許可でそのバイナリを実行します。

正当な理由により、実際のルートを持つことは推奨されません。– redanimalwar 15時間前

いいえ、それを使用することが絶対に適切な状況でrootアカウントを不器用に操作するのは、正当な理由ではありません。これは貨物カルトプログラミングのもう1つの形式です。sudoとrootの背後にある概念を本当に理解していないので、「rootは悪い、sudoは良い」という信念を盲目的に適用します。

一方でsudo、仕事に間違いなく適切なツールである状況があります。たとえば、グラフィカルなLinuxデスクトップでインタラクティブに作業している場合、Ubuntuを使用するsudoと、ルートアクセスが必要なまれなケースで使用する必要があります。Ubuntuは意図的に無効化されたルートアカウントを持ち、sudoユーザーがログインするために常にルートアカウントを使用することを防ぐためにデフォルトで使用することを強制します。 、したがって、デフォルトでルートアカウントを持っていないため、愚かな人々はこれを行うことができません。

一方、あなたのような状況では、自動化されたスクリプトが何かに対するルート権限を必要とする場合があります。たとえば、バックアップを作成する場合です。sudoルートアカウントを回避するために使用することは無意味であるだけでなく、危険でもありrsyncuserます。一見すると、通常の特権のないアカウントのように見えます。しかし、既に説明したように、攻撃者が既にrsyncuserアクセスを取得していれば、完全なルートアクセスを取得することは非常に簡単です。したがって、基本的に、ルートアカウントのように見えない追加のルートアカウントがありますが、これは良いことではありません。

--rsync-pathオプションを使用して、リモートrsyncコマンドをsudo特権で実行します。コマンドは次のようになります。

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

sudoパスワードの入力を求められた場合はNOPASSWD、リモートユーザーアカウントで特権を使用することで（rootには無意味で、他のユースケースでは意味があるかもしれません）、またはそれを行いたくない場合は、それを回避する必要があります：

• tty_ticketseg sudo visudo -f /etc/sudoers.d/local-rsync を実行し、次のように入力して、使用しているユーザーのオプションが無効になっていることを確認します。

  Defaults:your.username.for.rsync !tty_tickets
  

• requiretty使用しているユーザーのオプションが無効になっていることを確認してください-デフォルトでオフになっている可能性があります。方法は上記と同じです。

• sudoたとえば、次のコマンドを実行して、リモートマシンのパスワードをシードします。 ssh -t user@192.168.1.2 sudo

これを行う簡単な方法の1つは、でグラフィカルssh-askpassプログラムを使用することです。これにより、ターミナルに接続されていないsudoという事実を回避しsudo、パスワードを安全に入力できます。

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

もちろん、ssh-askpassプログラムは指定された場所にインストールする必要があり、作業中のマシンでXセッションを実行する必要があります。ssh-askpass動作するはずのプログラムにはいくつかのバリエーションがあります（Gnome / KDEバージョン）。また、グラフィカルなsudo交換プログラムのようなgksuまたはkdesudoも動作するはずです。

ユーザーがすでにパスワードで保護されているsudo特権を持っている場合、私はそれらをそのままにして、パスワードなしでrsyncを使用するためのスタンザを追加するだけです。

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

今日、この問題に遭遇し、構成ファイルを変更したり、ユーザーアカウントにルートレベルのアクセス許可を付与したりすることなく解決しました。私の特定のセットアップでは、Aマシン上fooのユーザーは、ユーザーが所有するディレクトリ内のすべてのユーザーディレクトリfooをマシンbarにコピーbackupする必要Aがありました。（ユーザーにAはsudo特権がありfooます。）

使用したコマンドは次のとおりです。上Aの/homeディレクトリでユーザーによって呼び出されましたfoo。

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

これにより、rsyncがsudoとして実行され、すべてのユーザーディレクトリにfooアクセスできますが、barユーザーAの資格情報を使用してsshを使用してマシンにアクセスするようにrsyncに指示します。私のニーズは上記の質問とは少し異なりましたが、これにより、システムの構成に手を加えることなく、管理している特定のマシンのすべてのユーザーディレクトリのバックアップをすばやく取得できました。

ターゲットマシンでrsyncをデーモンとして実行すると、必要な処理を実行できます。

私の解決策は使用--rsync-path="sudo rsync"することですが、パスワードを要求します、回避策：

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