次のシナリオを検討してください。
私はサーバーAにユーザー「common」としてログインしています。一般 ユーザーにとっての最大の問題は、多数のユーザーがアクセスできることです。設計上、制限はなく、安全ではありません。
たとえば、このユーザー/サーバーから定期的にログインしてサーバーBユーザーとして安全な- つまり、所有しているファイルをscpする必要があるsecure@serverB。
私は完全なアクセスと制御権を持っていますが安全なユーザー、私は確かに追加したくない一般の公開鍵を信頼できる鍵に安全なユーザー - 誰でもログインできるようにしたい一般ログインできるようにする安全な同じように。
私も入力したくない安全なのパスワードを 1 時間に 5 回入力します。理想的には、パスワードを 1 回入力して、何らかのエージェントなどにそれを魔法のように記憶させ (ただし、このログイン セッションのみ)、タイムアウトになるまでこのセッションから接続するたびにそのパスワードを使用します。kinit実際、 と似ています。
この目標を達成できるものは何かあるでしょうか?
答え1
中間サーバー上に共有ユーザーがあり、そのユーザーがシェル アクセスを持っている場合は、ほとんどすべてのものがデフォルトで各セッションからアクセス可能であるため、それほど簡単ではありません
。もちろん、最新のカーネルには方法があります。
セッション (プロセス/スレッド) キーリングを使用してカーネルにプライベート データを保存するツールがあるか、同じユーザーの異なるプロセスが相互にアクセスできないようにシステムを十分に安全にして、プログラムが認証情報を他のセッションから保護された通常のユーザー空間メモリにも保持できるようにするかのいずれかです。いずれにせよ、どちらも、基本的な使用には機能する PID/SID 情報に基づいて認証を行うための要求を識別する必要がありました。最終的には、セッションのセットアップを行うデーモン、または保存されたパスワードをプロセスに配信して、sshpass ツールなどで使用できるようにするデーモンが必要です。
別の方法としては、名前空間を利用してプライベート tmpfs または tmpdir をマウントする方法があります (tmpfs は tmpdir よりも保護がしっかりしているか、少なくとも root ユーザーからのアクセスが容易ではありません)。
sshd を別のポートで使用して、そのユーザーの名前空間環境を設定するラッパーを使用するか、少なくとも最新のシステムでは、pam と pam_namespace.so を使用してプライベート ユーザーの tmpdir または tmpfs を設定するのが最も簡単です。そこでは、sshpass などで使用できるようにパスワードを平文で保存したり、さらに良い方法として、ssh-agent のソケットをそのディレクトリに配置して、個人の秘密鍵をそのエージェントにロードし、エージェントへのアクセスが同じユーザーの他のセッションによるアクセスから保護されるようにすることができます。強力なパスワード付きの秘密鍵がある場合は、それをマシンに保存することもできます。それ以外の場合は、転送する必要がありました。/tmp ディレクトリ全体をそのようなプライベート ディレクトリにして (おそらくいくつかのサブディレクトリを共有して)、SSH エージェント転送を非常に安全な方法で使用することもできます (ルート ユーザーによる悪用を完全に防ぐことはできませんが、少なくとも tmpfs を使用する場合は、ルートにとっては困難であり、通常のユーザーが Auth-Sock を使用することはできません)。
とにかく、サーバーを十分に構成できるか、または、少なくともユーザーのプロセスが相互に接続できない程度に十分に構成されている必要があります。
答え2
おそらくあなたが探しているのはssh-agent、OpenSSH に付属しています。-tタイムアウトを設定するには、オプションを使用します。