Shellを/bin/false
に設定して、ユーザーアカウントを無効にすることを推奨することをよく耳にします。しかし、私の既存のLinuxシステムでは、代わりに多数の既存のアカウント(それらすべてがサービスアカウント)に/sbin/nologin
のシェルがあることがわかります。
Manページを見ると、/sbin/nologin
は、アカウントが無効になっていることを示すメッセージをユーザーに出力して終了します。おそらく/bin/false
は何も出力しません。
また、/sbin/nologin
は/etc/shells
にリストされていますが、/bin/false
はリストされていません。
マンページは、FTPが/etc/shells
にリストされているシェルnotを持つユーザーのアクセスを無効にすることを示しており、他のプログラムが同じことを行う可能性があることを示唆していますこれは、誰かが/sbin/nologin
をシェルとして持つアカウントでFTPでログインできることを意味しますか?
ここの違いは何ですか?ユーザーアカウントを無効にするためにこれらのうちどれを使用する必要がありますか、またどのような状況で使用しますか? /etc/shells
のリストには他にどのような影響がありますか?
/bin/false
はユーティリティプログラムであり、/bin/true
のコンパニオンです。これは、UNIXが完全な機能であることを確認する抽象的な意味で役立ちます。ただし、これらのプログラムの緊急の目的が見つかりました。 BASHステートメント/some/program || /bin/true
を検討してください。これは、$? = 0
が返されても、常にブール値が真(/some/program
)に評価されます。
ご指摘のとおり、/bin/false
の緊急使用は、ログインを許可されていないユーザーにとってはヌルシェルとしての役割を果たします。この場合のシステムは、シェルの実行に失敗したかのように動作します。
POSIX(私は間違っている可能性があり、それはSUSかもしれません)は、適切なブール値を返すこと以外にこれらのコマンドの両方が厳密に何もしないように制約します。
/sbin/nologin
は/bin/false
(ブール値falseを返す)と同様の動作をするBSDユーティリティですが、/bin/false
の実行が禁止されているため、出力も出力します。これは、ユーザーが何が起こったかを理解するのに役立つはずですが、実際には、多くのターミナルエミュレーターはシェルが終了すると単純に終了し、場合によってはメッセージを読み取ることができますが、とにかく読めなくなります。
/sbin/nologin
に/etc/shells
をリストする目的はほとんどありません。 /etc/shells
の標準的な効果は、ユーザーが自分のシェルを変更しているときにchsh
での使用が許可されているプログラムをリストすることです(自分のシェルを/sbin/nologin
に変更する明確な理由はありません)。 。スーパーユーザーは、誰のシェルも何にでも変更できます。ただし、/sbin/nologin
に/bin/false
と/etc/rsh
の両方をリストすると、これらのシェルを持つユーザーは、不幸なイベントでchsh
を使用してシェルを変更できなくなります。シェルを取得します。
FTPデーモンは、/ etc/shellsにないシェルを持つユーザーへのアクセスを許可しない場合や、ユーザーが希望する他のロジックを使用する場合があります。 sftp
(同様の機能を提供します)は同様ですが安全であるため、FTPの実行はいかなる場合でも避けてください。一部のサイトでは、/sbin/nologin
を使用して、sftpアクセスを許可しながらシェルアクセスを無効にし、/etc/shells
に入れています。ユーザーがcronjobsの作成を許可されている場合、これによりバックドアが開かれる可能性があります。
どちらの場合でも、scp
は無効なシェルでは動作しません。 scponly
は、このインスタンスでシェルとして使用できます。
さらに、シェルの選択はsu -
(別名su -l
)の操作に影響します。特に、/sbin/nologin
の出力は、シェルの場合はstdoutに出力されます。これは/bin/false
には当てはまりません。どちらの場合でも、su -cl
で実行されるコマンドは失敗します。
最後に、答え:
アカウントを無効にするには、これらのいずれにも依存しませんが、情報提供のためにシェルを/sbin/nologin
に設定します(/sbin/nologin
が/etc/shells
にある場合を除き、その時点で/bin/false
を使用する必要があります、すべきではありません)。代わりに、/etc/passwd
のパスワードフィールドを!
に設定します。これは、パスワードがない場合にcrypt
が有効であることを保証します。バグを回避するために、同じ方法で/etc/shadow
にハッシュを設定することを検討してください。 passwd -l
がこれを行います。
アカウントを無効にする3番目の方法は、アカウントの有効期限フィールドを古い日付に設定することです(例:usermod --expiredate 1
)。これにより、セットアップでユーザーがパスワードなしでUNIXアカウントに対して認証でき、使用しているサービスにシェルが不要な場合に、ログインが防止されます。
これについていくつかの調査を行った後、使用する方法は何をロックアウトする必要があるかによって異なります。ユーザーがこれをシェルに設定してログインすると、This account is currently unavailable.
の効果を示すメッセージが表示されます。少なくともRHELの派生物でファイル/etc/nologin.txt
を作成することにより、これを変更できます。
ご存知のように、/bin/false
はシェルではありません。彼らはそれが機能する方法は、バイナリが終了した直後にログアウトするfalseを返すことです。 /bin/true
でも同じ効果が得られることに注意してください。
FTPに関する質問について:はい、シェルを/sbin/nologin
に設定すると、ユーザーはFTPにログインできますが、/bin/false
または/bin/true
は、ユーザーが完全にログインするのを防ぎます- anyサービス。
したがって、/bin/false
または/bin/true
は、ユーザーがサービスにログインできないようにするのが最善ですが、/sbin/nologin
は、ユーザーにSSHまたはローカルコンソール以外のサービスへのログインを許可しながら、アカウントが非アクティブであり、SSH /ローカルコンソールのみをロックアウトする必要がある場合に最適に使用されるユーザー。
ええと、誰かがtry/bin/falseがFTPアクセスを許可しないことを証明しましたか?
ユーザーのシェルを/ bin/falseに変更したところ、問題なくFTPできました。
私は/ dev/nullを使用して完全にユーザーをロックアウトします(電子メールを除いて、彼らはまだPOP3を使用できます)。