解決策 1:
AuthorizedKeysFile を使用できます これを行うには、/etc/ssh/sshd_config のディレクティブを使用します。デフォルトの場所は .ssh/authorized_keys です ただし、絶対パスを含むものを使用することもできます。例:
AuthorizedKeysFile /path/to/your/keyfile
マニュアルページにはこう書かれています
<ブロック引用>AuthorizedKeysFile
ユーザー認証に使用できる公開鍵を含むファイルを指定します。 AuthorizedKeysFile には、接続のセットアップ中に置換される形式 %T のトークンが含まれる場合があります。次のトークンが定義されています:%% はリテラル '%' に置き換えられ、%h は認証されるユーザーのホーム ディレクトリに置き換えられ、%u はそのユーザーのユーザー名に置き換えられます。展開後、AuthorizedKeysFile は絶対パスまたはユーザーのホーム ディレクトリからの相対パスになります。デフォルトは「.ssh/authorized_keys」です。
解決策 2:
編集 :上記の @Iain の回答に賛成票を投じてください。それは完全で正確です。以下の私の回答は、共有 private を対象としています キー - 明らかに私の誤解です。この回答は貴重な情報であると考えているため、ここに残しておきますが、この特定の質問に関するものではありません.
あなたのユースケースはわかりませんが、「あなたのやり方は間違っている」と言いたくなります。
各ユーザーは、独自の kepair を持つ必要があります。そうすれば、ユーザーが退職したり、異動したり、管理役割に昇格したり、その他の権限の取り消しが必要になったときに、その 1 つのキーを取り消すだけで済みます。これにより、効果的な監査も非常に難しくなります。
ユーザーが他のユーザーになりすますことができるようにする必要がある場合は、sudo でそのように構成する必要があります。 .通常、SSH 鍵を共有することはお勧めできません。
解決策 3:
管理者は sudo の適切な (環境に合わせた) 組み合わせを使用する必要があります。 と su .
ssh これには適切なツールではありません。
矛盾する編集 (すみません、タイトル失明に苦しんでいたようです。Zoredache に感謝します):
すべてのサービス アカウントを同じ group に入れます 、そのグループを Match の一部として使用します sshd_config のブロック AuthorisedKeysFile を指定します あなたはそれらすべてを使用したい.(一致グループは、すべて アカウントには影響しません。)ただし、個別の AuthorizedKeysFiles はありません。 openssh-lpk さらに、個々のアカウントが独自のキーを持つことを許可する場合がありますが、それについてはわかりません.