リモート側のシェルセッションでSSH公開鍵を識別します(エージェントが存在しないか、エージェントにIDがありません)。

リモート側のシェルセッションでSSH公開鍵を識別します(エージェントが存在しないか、エージェントにIDがありません)。

キーエージェントに保存されているキーを使用するときに認証に使用するキーを確認する方法は次のとおりです。

ssh-add -L 2>/dev/null | awk '{print $1}' | while read identity; do grep -v '^#' ~/.ssh/authorized_keys | grep "${identity}" ; done 

エージェントのIDを1行ずつ一覧表示し、キーを抽出してauthorized_keysファイル内を見つけます。

クライアントがキーエージェントを使用しない場合、キーは表示されませんssh-add -L

公開鍵を識別する他の方法はありますか?SetEnvまたは、キーオプションを使用してカスタム「ユーザー環境」変数を渡したり設定したりすることはenvironment="VAR=VALUE"できません(許可)。

ベストアンサー1

sshdがユーザー認証方法を記録する唯一の場所はシステムログです。この情報はログインセッションでは利用できません。接続元の一意の識別情報は、以下にあります。環境SSH_CLIENTは変数とそのクライアントのIPアドレスとポートですSSH_CONNECTION

ディレクティブを追加できます。~/.ssh/authorized_keysユーザーが特定のキーでログインしている場合は、環境変数を設定します。

environment="SSH_KEY=foo" ssh-rsa AAAA…

ユーザーがキーを使用してログインしていない場合、システムログを確認しないとログイン方法(パスワード、.shostsKerberosなど)がわかりません(システム管理者のみがこれを実行できます)。

システム管理者がこのauthorized_keysファイルの変更を許可していない場合は、管理者と協力して必要な操作を実行する方法を決定する必要があります。あなたが知っておくべき情報とその理由を彼らに説明してください。

プロキシで実行する操作は、接続元を識別する信頼できる方法ではなく、ユーザーがログインした方法については何も伝えません。ユーザーがプロキシを渡していないか、プロキシにキーがない場合。複数のキーを取得することができ、ユーザーはそのいずれかを使用してログインする特別な理由はありません(パスワード、他のキー、または他の方法を使用できます)。私はこの情報で何もしないことをお勧めします。これは信頼できません。

おすすめ記事