web-dev-qa-db-ja.com

SSHロギング機能は、秘密/公開鍵認証のsuロギングと同等ですか?

ここでは、特定のアプリケーションの管理に使用されるUNIX上の非root共有ログインアカウントがあります。ポリシーは、共有アカウントへの直接ログインを許可しないことです。自分でログインし、「su」コマンドを使用して共有アカウントに切り替える必要があります。これは、ロギング/セキュリティを目的としています。

エージェントでSSH公開/秘密鍵認証を使用して、1日に1回パスワードを入力し、エージェント転送でその日の残りのパスワードプロンプトを削除できるようにしました。本当にいいです。

ただし、一部のシステムはロックダウンされているため、共有アカウントにアクセスするには「su」コマンドを使用する必要があります。 Arg!いつもパスワードの入力に戻りましょう!

SSH公開/秘密鍵認証でログに記録される十分な情報があり、公開/秘密鍵が使用されている場合に共有アカウントへのリモートログインを許可するポリシー変更を要求する合理的な機会がありますか?

管理者が/ var/log/secureを調べたところ、特定のIPアドレスからのユーザーアカウントに公開鍵が受け入れられたと表示されました。誰が公開鍵であるか、誰が秘密鍵であるかはわかりませんでした。

11
David I.

sshd_configファイルを介して利用できるロギングの多くのレベルがあります。 manページ を参照して、LogLevelを探してください。デフォルトのレベルはINFOですが、VERBOSEまたはDEBUG#レベルの1つに上げるのは簡単です。

さらに、Sudoの代わりに su を調べる必要があります。 Sudoの利点についての完全な議論は、それ自体の問題です。しかし、Sudoを使用すると、パスワードの入力頻度、実行できるコマンドなどを調整でき、すべて sudoers 構成ファイルで制御できます。

13
dwc

もう1つの方法は、authorized_keysをユーザーのスコープ外に移動して(たとえば、/etc/ssh/authorized_keysに)、システム管理者だけが特定のアカウントへのログ記録に使用できる公開鍵を制御できるようにすることです。

以前は、sshd_configAuthorizedKeysFileディレクティブを次のようなものに変更していました。

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

次に、/etc/ssh/authorized_keysディレクトリを作成して、ログインできるはずの各ユーザーのファイルを入力します。rootファイルがrootに対してのみ読み取り/書き込み可能であり、他のファイルが適切なユーザーによって読み取り可能であることを確認します。 :

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

各ファイルには、特定のアカウントへのログインが許可される公開鍵のセットが含まれています。各ユーザーアカウントには、それぞれのグループも存在することは非常に一般的です。

公開鍵/秘密鍵を使用することは、リモートユーザーアクセスを制御するためのより良い方法です。パスワードを毎月変更する必要はなく(パスワードも設定する必要はありません)、従業員が会社を辞めたという理由だけで公開鍵を削除するだけでパスワードを変更する必要はありません。もちろん、SSHオプション(http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC)を使用すると、特定のユーザーがアクセスできる場所と場所を細かく調整できます。

6
therek

SSH公開/秘密鍵認証は、ホスト認証とは別のものです。ここでは運が悪い。ただし、特定のグループのメンバーがパスワードなしでSudoを介して特定の管理コマンドを実行できるように要求することもできます。たとえば、次の例では、secretariesグループのユーザーがアカウントを管理できます。


# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...
1