キーパスワードを一度入力すると、ssh-agentの実行中にパスワードを再入力しなくてもリモートシステムに自由に接続できるという記事Master Linux Now 2013を読んでいました。OpenSSH: Easy Loginsssh-agent
最初にこの投稿に興味を持つようになった理由は、パスワードを百万回再入力する必要がないことに加えて、サーバーのコンピュータにあるcronからrsyncを呼び出すsshを介してリモートコンピュータから自動バックアップを実行できることです。でした。
cronがキーを使って簡単にログインできるように、誰かがパスワードをスキップする別の投稿を見ましたが、これは正しいとは思いませんが、実際には大丈夫ですか？つまり、誰かがそのキーファイルを持っていると、バックアップしているコンピュータに大きなダメージを与える可能性があります。
私の考えでは、ユーザーが再起動時にログインしていることを確認し、エージェントを実行するためにログインするときにパスワードを一度入力してから、画面がロックされた状態でcronジョブが実行されるのを待つ方が安全です。これには、cronジョブが実行されているユーザーやユーザーの種類などの内容がありません。
ベストアンサー1
キーを押して呼び出すことができるコマンドを制限します。
すべての種類の自動化または無人操作でSSHキーを使用するには、キーの保存方法と場所についてどのような決定を下したかに関係なく、リモートコンピュータで実行できるコマンドを制限する必要があります。
次のように使用してください~/.ssh/authorized_keys。
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
そうすれば、少なくともあなたが言ったように、鍵が大きな混乱を引き起こすことはありません。予想されるものにのみアクセスできます。それでも損傷を受ける可能性は高いですが、リモートシステムへのフルアクセス権は低くなければなりません。
また、このキーを使用して接続が許可されるIPアドレスを制限し、このキーを使用する接続へのポート転送などの他の多くのSSH機能を無効にすることもできます。
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
これらはすべてにある必要があります~/.ssh/authorized_keys。
キーを守る
脅威モデルが何であるかによって異なります。
たとえば、鍵が保存されているコンピュータが物理的に盗まれた場合など、「コールド」状態で鍵を盗まれたと思われる場合は、その場所にパスワードなしで鍵を保存したくありません。
あなたできるサーバーの起動後にバックグラウンドSSHエージェントを手動で起動し、エージェントにキーを追加し、後でクローン操作で使用できるようにエージェントキーを記録すること$SSH_AUTH_SOCKは、正直なところそれほど価値があるよりも多くの問題のように聞こえます。暗号化されていない鍵をtmpfsファイルシステムに保存し、cron ジョブがそこからアクセスできるようにすることもできます。どちらのキーもメモリにのみ存在します（スワップまたは暗号化されたスワップがない場合）。もちろん、そのファイルは意図したユーザーだけがアクセスできるようにする必要がchownあります。chmod
もう一度、この問題が心配な場合は、このコンピュータに暗号化されたルートファイルシステムとスワップ（luksなど）がすでに設定されているため、心配する必要はありません。
キーが「ホット」（メモリにロードされている）の間に盗まれたかどうか心配している場合は、これができることはあまりありません。 cronジョブがアクセスできる場合は、同じアクセス権を正常に取得した他のアイテムにもアクセスできます。それはすべてです。または、無人ジョブの実行の利便性をあきらめてください。
要約すると、バックアップサーバーには、バックアップするすべてのマシンのファイルシステム全体に読み取り専用アクセス権が付与されているため、非常に特権のあるシステムとして扱う必要があります。たとえば、バックアップサーバーはインターネットからアクセスできないはずです。