有効なシェルを持ち、パスワードを持たないユーザーは、パスワードを使用しない方法 (最も一般的な方法は ssh キー) でログインできます。 cron ジョブを実行するには、有効なシェルが必要です。 su bin -c 'wibble' にも有効なシェルが必要です 動作する (少なくとも Linux では su bin -s /bin/sh -c 'wibble' も動作します)。
binの場合 、ほとんどのシステムはコマンドを bin として実行することはありません 通常の操作では、シェルを /bin/false に設定します 大丈夫です。
bin を許可する直接攻撃のリスクはありません /bin/.ssh/authorized_keys を作成する必要があるため、SSH 経由でログインするには ユーザー bin として またはルートとして。つまり、侵入する唯一の方法は、侵入することです。ただし、有効なシェルを使用すると、設定ミスのリスクが高まります。また、SSH 以外のサービスを使用したリモート攻撃を許可することもできます。たとえば、攻撃者が daemon のパスワードを設定できるとユーザーが報告したとします。 Samba 経由でリモートから、そのパスワードを使用して SSH 経由でログインします。
DenyUsers にシステム ユーザーの名前をリストすることで、SSH ホールを塞ぐことができます。 /etc/ssh/sshd_config のディレクティブ (残念ながら、数値範囲は使用できません)。または、逆に、 AllowGroups を置くことができます ディレクティブを作成し、物理ユーザーを含むグループのみを許可します (例:users すべての物理ユーザーにそのグループ メンバーシップを付与する場合)。
Debian (#274229、#330882、#581899) でこの問題に関して報告されたバグがあり、現在オープンで「ウィッシュリスト」として分類されています。これらはバグであり、システム ユーザーは /bin/false を使用する必要があることに同意する傾向があります。 別の方法で行う必要があると思われる場合を除き、シェルとして。
ユーザーとしてそれらについて心配する必要はありません。彼らはセキュリティ グループという意味での「ユーザー」であり、「ログインして使用する」人々という意味でのユーザーではありません。 「/etc/shadow」を調べると、これらすべての「ユーザー」がパスワードを持っていないことがわかります (長いソルト付きハッシュの代わりに「x」または「!」のいずれか)。これは、これらのユーザーが何があってもログインできないことを意味します。
とはいえ、これらすべてのユーザーに対して「/bin/sh」を「/bin/false」に変更するのが良い考えかどうかはわかりません。プログラムはこれらのグループの下で実行されるため、必要なコマンドを実行できない可能性があります。 「/bin/sh」のままにしておきます。
これらのユーザーについて心配する必要はありません。作成したユーザー (および「/etc/shadow」にハッシュがあるユーザー) についてのみ心配してください