パスワードに対して有効期限を設定することは、一般に推奨されるセキュリティ設定ですが、システムアカウントや共有アカウント (例: Oracle) については、このルールから除外しておく必要があります。これは、パスワードの期限が切れたタイミングで、そのアカウントを使用するアプリケーションが動作しなくなってしまうからです。

一般に企業内のポリシーでは、システムアカウントや共有アカウントのパスワード変更に関する条項を作成しておくべきです。それ以外の一般ユーザのアカウントについては、自動的に期限が切れるように設定しておくとよいでしょう。下記の例では、ユーザアカウントごとにパスワードの有効期限を設定するための方法を示しています。

下記の表には、 useradd コマンドで新しいアカウントを作成する際に使用できる、各種のファイルとパラメータが示されています。これらの設定は、アカウントの作成時に /etc/shadow ファイル内に書き込みが行われます。新しいユーザを作成する際に YaST のツール ( ユーザとグループの管理 ) を使用すると、ユーザごとに設定を行うことができます。また、設定内容によってはシステム全体に適用されるものもあります (たとえば /etc/login.defs ファイルや /etc/default/useradd ファイルの変更がそれにあたります):

注記: 既存のユーザに対する影響について

上記のファイルは、いずれもアカウントの作成時に適用されるもので、ファイルの変更前に作成されたアカウントについては効果がありません。

上記の /etc/login.defs ファイルや /etc/default/useradd ファイルを変更したことを確認したら、あとは実際にユーザを作成して、 /etc/shadow ファイルにどのような設定が行われるのかを確認します。

新しいユーザを作成するには、下記のようなコマンドを入力して実行します:

# useradd -c "テストユーザ" -g グループ ユーザ名

-g オプションは、追加するアカウントのプライマリグループを指定するためのオプションです:

# id ユーザ名
uid=509(test) gid=100(users) groups=100(users)

/etc/login.defs と /etc/default/useradd に設定した内容が、新しく作成した test ユーザに対してどのように反映されたのかを確認します。 /etc/shadow ファイル内を下記のようにして表示します:

# grep ユーザ名 /etc/shadow
test:!!:12742:7:60:7:14::

パスワードの有効期限については、 chage コマンドを使用することでいつでも変更できます。システムアカウントや共有アカウントに対してパスワードの有効期限を無効化したい場合は、 chage コマンドで下記のように入力して実行します:

# chage -M -1 システムアカウント名

パスワードの有効期限に関する情報を表示するには、下記のように入力して実行します:

# chage -l システムアカウント名

たとえば下記のようになります:

# chage -l TEST
Minimum: 7
Maximum: 60
Warning: 7
Inactive: 14
Last Change: Jan 11, 2015
Password Expires: Mar 12, 2015
Password Inactive: Mar 26, 2015
Account Expires: Never

セキュリティの実践の一環として、ユーザに対し単純なパスワードを禁止するような措置を取っておくことが重要です。パスワードが安全に保管されている限り、複雑なパスワードを設定すれば、容易には侵入できなくなるからです。また、複雑なパスワードを設定しておくことで辞書攻撃からアカウントを保護することができますし、ロックアウト (施錠) と併用すれば、さらに侵入を困難にすることができます。しかしながら、必ずしもこの方式が適切とは限りません。ロックアウトを併用すれば誰もアプリケーションやシステムに入れなくなってしまうことになりますので、サービス拒否 (Denial of Service; DoS) 攻撃というもう 1 つの問題を引き起こしてしまいます。

このような事情から、まずはパスワードの管理をより現実的かつ効率的に行うことが重要です。多くの企業ではパスワードに対して、 1 文字以上の数字と小文字、大文字を必要とするようにしています。ポリシーは企業によって異なりますが、パスワードの複雑さの強制と効率性の両立は、いくぶん難しいものになります。

Linux-PAM (Pluggable Authentication Modules for Linux) は共有ライブラリから成るパッケージスイートで、ローカルのシステム管理者に対してアプリケーションからのユーザ認証方法を設定する機能を提供します。

PAM が提供する機能のほか、この仕組みによって提供される環境ごとの最適な構成方式については、よく知っておくことをお勧めします。この設定作業は一度だけ実施すればよく、全てのシステムに対して同じ設定を行っておく (設定の標準化) こともできますし、そこからさらにホスト固有の設定を追加する (特定のホストやサービス、アプリケーションに対するセキュリティ強化) こともできます。これはつまり、この仕組みが非常に柔軟な構造であることを理解することにもなります。

PAM のアーキテクチャを詳しく知りたい場合は、 /usr/share/doc/packages/pam ディレクトリ内にある PAM のドキュメンテーション (英語) をお読みになることをお勧めします。ここには様々な形式が用意されています。

下記の説明では、特にパスワードの強度ポリシーに関する設定など、既定の PAM 設定の変更方法の例を示しています。これにはたとえばパスワードそのものの複雑性のほか、パスワードの再利用やアカウントのロックアウト (一時的な無効化) も含まれます。これらは機能全体のうちのごく一部ではありますが、 PAM の構造や柔軟性を理解するには最適な例です。

重要: pam-config の制限について

pam-config ツールは PAM の設定ファイルのうち、 common-{account,auth,password,session} の各設定ファイルを変更するために使用します。これらのファイルにはグローバルオプションのほか、下記のようなコメントが書かれています:

# This file is autogenerated by pam-config. All changes
# will be overwritten.
# (このファイルは pam-config で自動生成されたものです。直接ここで編集を
# 行っても、上書きされてしまう可能性があります)

それ以外の個別のサービスファイル、たとえば login, password, sshd , su などのファイルについては、手作業で編集しなければなりません。もちろん pam-config を全く使用せず、全てのファイルを手作業で編集してもかまいません。ですが pam-config には古い設定の変換や現在の設定の更新、そして正当性のチェックなど、様々な機能が用意されています。詳しくは man 8 pam-config で表示されるマニュアルページをお読みください。

> sudo pam-config -a --cracklib-minlen=8 --cracklib-retry=3 \
--cracklib-lcredit=-1 --cracklib-ucredit=-1 --cracklib-dcredit=-1 \
--cracklib-ocredit=-1 --cracklib

> sudo pam-config -a --pwhistory --pwhistory-remember=26

auth      required   pam_env.so
auth      required   pam_unix.so     try_first_pass
account   required   pam_unix.so     try_first_pass
password  requisite   pam_cracklib.so
password  required   pam_pwhistory.so        remember=26
password  optional   pam_gnome_keyring.so    use_authtok
password  required   pam_unix.so     use_authtok nullok shadow try_first_pass
session   required   pam_limits.so
session   required   pam_unix.so     try_first_pass
session   optional   pam_umask.so

14.4.3 ログイン失敗時のユーザアカウントのロックアウト #Edit source

ssh, login, su, sudo などで一定回数以上のログイン失敗が繰り返された場合、対象のアカウントをロックアウトする措置は、一般的なセキュリティ対策として実施されるものです。しかしながら、これを実施してしまうとアプリケーションや管理者、 root ユーザでのログインができなくなってしまいます。

重要: サービス拒否攻撃について

パスワードの入力失敗回数は、故意にログインを失敗させるだけで増やすことができてしまいますから、サービス拒否攻撃として容易に悪用されてしまいます。

そのため、パスワードの入力失敗回数によるロックアウトは、どうしても必要な場合だけに留めるものとし、対象のアカウントは少なく、かつ必須のアカウントについては除外するようにしてください。また、ロックアウトは人間が使用するアカウントだけでなく、サービスを提供するシステムアカウントに対しても発生しうることにも注意してください。

openSUSE Leap の既定では、アカウントのロックアウトは行いません。ただし、 pam_tally2 モジュールを使用することで容易にロックアウトを設定することができます。 /etc/pam.d/login 内の冒頭に下記の内容を記述することで、 root を除く全ユーザに対し、 6 回のログイン失敗時に 10 分間のロックアウトを設定することができます:

auth required pam_tally2.so deny=6 unlock_time=600

下記は /etc/pam.d/login ファイルに設定した場合の例です:

#%PAM-1.0
auth     requisite      pam_nologin.so
auth     include        common-auth
auth     required       pam_tally2.so deny=6 unlock_time=600
account  include        common-account
account  required       pam_tally2.so
password include        common-password
session  required       pam_loginuid.so
session  include        common-session
#session  optional       pam_lastlog.so nowtmp showfailed
session  optional       pam_mail.so standard

root ユーザに対してもロックアウトを設定することができますが、注意してお使いください:

auth required pam_tally2.so deny=6 even_deny_root unlock_time=600

root に対して異なるロックアウトを設定することもできます:

auth required pam_tally2.so deny=6 root_unlock_time=120  unlock_time=600

ロックアウトの解除を自動では行わず、管理者の操作を必要としたい場合は、 unlock_time オプションを削除してください。下記の 2 つのコマンド例では、ログイン失敗回数を表示して、ロックアウト解除を行う例を示しています:

> sudo pam_tally2 -u username
Login           Failures Latest failure     From
username            6    12/17/19 13:49:43  pts/1

> sudo pam_tally2 -r -u username

ログインを試した記録は、既定で /var/log/tallylog 内に保存されます。

ロックアウト時間の経過後や管理者によるロックアウト解除を実施すると、上記のカウンタは 0 にリセットされます。

その他のログインサービスで pam_tally2 を使用するには、 /etc/pam.d/ 内にあるそれぞれの設定ファイル (sshd, su, sudo, sudo-i, su-l) に設定を追加してください。

既定では root にはパスワードを設定するため、さまざまな方法でログインができることになります。たとえばローカルの端末やグラフィカルなセッション、 SSH 経由でのログインなどがあります。これらはセキュリティ上の理由から、できる限り制限しておくことが望ましいものです。もちろん root アカウントを共有して使用するようなことも避けるべきです。このようなことから管理者は、 su や sudo (詳しくは man 1 su コマンドもしくは man 8 sudo コマンドで表示されるマニュアルページをお読みください) などのツールを使用して特権を得るべきです。これにより、管理者でのログインを特定のユーザに結びつけることができるようになります。この方式では root のパスワードに加え、もう 1 つの安全性も提供します。それは root の特権を得るには root のパスワード だけでなく 、管理者 (一般ユーザ) のパスワード認証も突破しなければならないようにできる、という点です。本章では、システムのさまざまなレベルにおいて、直接的な root ログインを制限するための方法を説明しています。

14.5.1 ローカルのテキストコンソールへのログイン制限 #Edit source

TTY デバイスはコンソール経由でのテキストモードアクセスを提供するデバイスです。デスクトップシステムの場合は直接接続されたキーボード経由で、サーバシステムの場合は KVM スイッチやリモートマネージメントカード (例: ILO, DRAC) 経由でも使用することができます。既定では、 Linux は 6 つの異なるコンソールを提供します。これらは Alt–F1 から Alt–F6 までを押すことで切り替えることができます。グラフィカル環境が動作している場合は、それぞれ Ctrl–Alt–F1 から Ctrl–Alt–F6 までを押してください。それぞれの端末は tty1 から tty6 に対応します。

下記の手順では、最初の TTY のみを使用できるよう root アクセスを制限しています。この方式は緊急時の管理者アクセスを残しておくためのもので、通常は TTY を使用すべきではありません。

注記

また、ここで示している手順は一般的な PC アーキテクチャ (x86 および AMD64/Intel 64) 向けの設定手順となります。 POWER 等のアーキテクチャの場合は、 tty1 ではないデバイス名になります。また、端末デバイス名は誤って指定することのないように注意してください。現在使用している端末デバイス名を知りたい場合は、 tty コマンドをお使いください。また、 SSH 経由でのログインやグラフィカルなセッションを使用している場合 (表示されるデバイス名が /dev/pts/N のようになります) は設定しないでください。実際のログイン端末 (Alt–FN でアクセスできるもの) にのみ設定してください。

手順 14.1: ローカル TTY への root ログインの制限 #

1. まずは PAM スタックの設定ファイル /etc/pam.d/login 内の auth ブロックに、 pam_securetty モジュールを設定します:

   auth     requisite      pam_nologin.so
    auth     [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so noconsole
    auth     include        common-auth

   これにより、ローカルコンソールでの認証時に、 pam_securetty モジュールが使用されるようになります。このモジュールは root に対し、ログイン可能な TTY デバイスを制限する機能を提供します。ログイン可能な TTY デバイスの一覧は、 /etc/securetty ファイルで設定します。

2. /etc/securetty ファイルの内容を編集して、 1 つだけ残すようにします。これにより、 root ユーザが使用できる TTY デバイスを制限できることになります。

   #
   # This file contains the device names of tty lines (one per line,
   # without leading /dev/) on which root is allowed to login.
   #
   tty1

3. 設定を行ったら、実際に root でログインを試してみて、指定した TTY 以外からログインできなくなっていることを確認します。上記の例ではたとえば tty2 などがそれにあたります。この場合、パスワードを尋ねられることなく即時に拒否されるはずですので、こちらもご確認ください。また、指定した TTY (tty1) からログインできることも確認しておいてください。これにより、ロックアウトされているのではなく、端末の制限でログインできなくなっていることが確定できるためです。

重要: pam_securetty モジュールの追加について

/etc/pam.d/common-auth に対しては pam_securetty を設定してはなりません。設定してしまうと su や sudo のコマンドにも影響が及ぶことになり、これらのコマンドでも TTY が制限されることになるためです。

重要

上記のように設定変更を行うと、シリアルコンソール (例: /dev/ttyS0) からのログインも制限対象となり、ログインができなくなります。シリアルコンソールからのログインを許可したい場合は、 /etc/securetty ファイル内にシリアルのデバイス名を追加してください。

14.5.3 SSH ログインの制限 #Edit source

既定では、 root ユーザは SSH ネットワークプロトコル経由でログインできるようになっています (SSH ポートがファイアウオールでブロックされていない限り) 。 root でのログインを禁止したい場合は、 OpenSSH の設定を変更することで実現することができます:

1. /etc/ssh/sshd_config ファイルを編集して、下記のようなパラメータを設定します:

   PermitRootLogin no

2. あとは sshd サービスを再起動して、設定を適用します:

   systemctl restart sshd.service

注記

OpenSSH の場合、 pam_securetty モジュールでの設定は不適切です。これは SSH の仕様上の理由で、 PAM スタック経由でログインするとは限らない (たとえば SSH は公開鍵認証にも対応しており、この場合は PAM を経由しない) ためです。これに加えて SSH では、パスワードの入力が誤っている場合と、ポリシーによって制限されている場合とで応答が異なるため、悪意のある攻撃者であれば容易に識別されてしまう問題もあります。

sudo コマンドは、他のユーザ (一般的には root) に成り代わってコマンドを実行するためのコマンドです。 sudo コマンドの設定には、成り代わり元や成り代わり先のユーザやグループ、そしてそれらのユーザやグループに対して許可するコマンド等のルールセットを記述します。設定は /etc/sudoers というファイルで指定します。

SUSE システムの既定の設定では、 sudo コマンドは root のパスワードを尋ねるようになっています。ただし、 su とは異なり、 sudo にはパスワードを記憶する機能が用意されていて、 5 分間以内の再実行であれば、パスワードを再度尋ねたりすることはありません。そのため、 sudo は管理者として信頼できるユーザにのみ提供すべきものです。

なお、ここまでの設定は sudo の機能に対する制限を設定しただけであり、 su コマンドの機能は制限していないことに注意してください。こちらのコマンドは従来どおり、誰にでも利用できてしまいます。また、システムへのアクセス方式として別経路の方式が存在する場合、 root のパスワードを知っていれば、その経路でログインして実行できる可能性があることにも注意してください。

対話型のシェルに対しては、何も操作していない場合のタイムアウト時間を設定して、一定の時間が経過すると自動的に切断するように設定するとよいでしょう。この設定を行うことでセッションの盗用を未然に防ぐことができるほか、システムリソースの浪費を防ぐことにも繋がります。

既定では、シェルに対する無操作タイムアウトは設定されていません。シェルを開いて何も操作を行わなくても、何日も何年も開いたままになります。ほとんどのシェルには無操作タイムアウトの設定が存在し、一定時間の経過後自動的にセッションを終了させることができます。下記では、一般的に使用されるシェルを対象に、無操作タイムアウトの設定を示しています。

無操作タイムアウトはログインシェルにのみ適用するか、全ての対話型シェルに適用するかを選択することができます。全ての対話型シェルに設定した場合、タイムアウトはそれぞれのシェルで別々に動作し、タイムアウト値は累積して処理されます。言い換えると、サブシェルや子シェルを起動した場合、そのシェルに対しては新しいタイムアウト値が設定されるため、サブシェルもしくは子シェルが時間切れになっても親のシェルはそのタイミングでは終了せず、動作し続けることになります。

下記の表には、 openSUSE Leap に同梱されている各種のシェルと、設定方法に関する一覧が記述されています:

上記のシェルはいずれも内部タイムアウト値の設定が存在し、これに値を設定することで無操作タイムアウトを実現しています。ユーザ側でタイムアウト設定を上書きさせたくない場合は、シェル変数を読み込み専用にしてください。具体的な設定方法も上記で示しています。

注記: 不正行為に対する保護にはならない件について

この機能は、ユーザがセッションの存在を忘れてしまいがちな状況や、セキュリティに配慮していない使い方に対する対策として設定できる項目であり、悪意に対する対策にはならないことに注意してください。また、このタイムアウト値はシェルの待機状態に対してのみ働くもので、悪意を持ってすれば容易にタイムアウトを無効化できてしまいます。

無操作タイムアウトを設定するには、それぞれのシェルの設定ファイルに対して変数を設定します。ログインシェルのみに設定する場合と、全てのシェルに対して設定する場合とでファイルが異なることにも注意してください。下記の例は bash と ksh に対して働く設定で、ユーザ側からはタイムアウト値を書き換えることができないよう、読み込み専用の設定を行っています。下記の内容は /etc/profile.d/timeout.sh ファイルを作成して記述してください:

# /etc/profile.d/timeout.sh for SUSE Linux
#
# Timeout in seconds until the bash/ksh session is terminated
# in case of inactivity.
# 24h = 86400 sec
readonly TMOUT=86400

ヒント

ログアウト後にもセッションを残しておきたい場合は、 screen ツールをお使いになることをお勧めします。 screen セッションはログアウト時にも終了させられることがなく、必要に応じて再接続できるためです。また、ログアウトせずにセッションをロック (施錠) することもできます (man screen で表示されるマニュアルページで、 Ctrl–A–X / lockscreen ) に関する説明をお読みください) 。

Linux ではユーザやグループに対して、システムリソースの制限を設定することができます。これはプログラム内にバグ (たとえばメモリリーク) があったような場合に非常に有用な仕組みで、これによってシステムの動作が遅くなったり、場合によっては全く使えなくなってしまったりするようなことを防ぐことができます。また、この制限を設定することにより、プログラムがリソースを使用しすぎてしまい (たとえばプログラムが利用可能なファイルハンドル全てを占有してしまったりなど) 、新しい接続を受け付けられなくなってしまったり、ローカルログインができなくなってしまったりする問題を防ぐこともできます。その反面、リソースの制限はサービス拒否 (Denial of Service; DoS) 攻撃を容易にしてしまうことにも注意してください。一般的にはユーザやグループに対してリソース制限を設定すると、その用途にもよりますが、システムの保護に役立てることができます。

14.8.1 システムリソースの制限例 #Edit source

下記の例では Oracle というユーザアカウントに対してリソース制限を設定しています。リソース制限の設定項目については、 /etc/security/limits.conf ファイルを読むか、 man limits.conf で表示されるマニュアルページをお読みください。

bash などのようなほとんどのシェルでは、さまざまなリソース (最大ファイルディスクリプタ数や最大プロセス数など) の制限を行うことができます。これらはユーザ単位で設定することができます。現在のシェルでのリソース制限設定を表示するには、下記のようなコマンドを入力して実行します:

# ulimit -a

bash シェルにおける ulimit の説明については、 bash のマニュアルページをお読みください。

重要: SSH セッションに対する制限の設定について

SSH セッションに対しては、 「hard」 や 「soft」 の制限が期待通りにならないことがあります。正しく動作させたい場合は、いったん root でログインしたのち、対象のユーザ (たとえば Oracle) に su をして切り替えるようにしてください。またリソースの制限は、システムの起動時に開始されたアプリケーションに対しても作用させることができます。 SSH 経由でリソース制限が正しく動作していないように見える場合は、 /etc/ssh/sshd_config ファイル内の UsePrivilegeSeparation オプションを no に設定して、 SSH デーモンを再起動 ( systemctl restart sshd ) してください。ただし、このような設定は、別の意味でシステムのセキュリティを弱める結果になることに注意してください。

ヒント: ssh でのパスワードログインの禁止について

SSH 経由でのログインに際しては、パスワードでのログインそのものを禁止することで、さらに安全性を高めることができます。なお、パスワードでのログインを禁止する場合は、あらかじめ公開鍵でのログインが正しく動作することを確認した後にしてください。パスワードでのログインを禁止するには、 /etc/ssh/sshd_config ファイルに下記のような行を追加します:

UseLogin no
UsePAM no
PasswordAuthentication no
PubkeyAuthentication yes

下記の例では oracle ユーザが開くことのできるファイルおよびファイルハンドルの数を変更しています。この変更は root で /etc/security/limits.conf ファイルを編集することで行います:

oracle           soft    nofile          4096
oracle           hard    nofile          63536

上記の "soft" の行は oracle ユーザがログインしてからのファイルハンドル (開いているファイル) の数の上限を設定していて、この値を超過すると警告メッセージが表示されるようになります。絶対的な上限は "hard" の行で設定し、この例では 65536 個までを利用できることになります。コマンドで設定する場合は、下記のように入力して実行します:

# ulimit -n 63536

上記の "soft", "hard" の値は必要に応じて調整してください。

注記: ulimits を使用する場合の注意について

ulimit を設定する場合は、よく注意して設定してください。 「nofile」 に対して 「hard」 の上限をカーネルの規定する最大値 ( /proc/sys/fs/file-max ) に設定してしまうと、もしもそのユーザが全てのファイルハンドルを使用してしまった場合、 PAM モジュールにアクセスする際にもファイルハンドルを使用しますので、ログインさえもできなくなってしまうことになります。

リソース制限は pam_limits を使用して設定することもできます。全てのサービスで共通で設定する場合は /etc/pam.d/common-auth ファイルを、 SSH, su, login, telnet など、サービスごとに設定する場合は下記のファイルをそれぞれ編集してください:

/etc/pam.d/sshd (SSH の場合)

/etc/pam.d/su (su の場合)

/etc/pam.d/login (ローカルログインや telnet の場合)

全てのログインに対して適用したくない場合は、 /etc/security/limits.conf ファイルを読み込む PAM モジュールがあります。 PAM の設定ディレクティブは下記のようになります:

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

なお、上記で変更を行っても即時には反映されず、次回のログインから適用されることに注意してください:

# su - oracle
> ulimit -n
4096

また、ここでの説明はいずれも bash シェルを使用した場合の例であり、それ以外のシェルを使用する場合は ulimit オプションが異なることに注意してください。たとえば oracle ユーザに対する制限が 4096 であった場合、これを 63536 まで増やすには、下記のように入力して実行します:

# su - oracle
> ulimit -n
4096
> ulimit -n 63536
> ulimit -n
63536

ulimit -n 63536 のような設定 (この例では bash) を恒久的に保存したい場合は、 openSUSE Leap が提供する bash シェル向けのスタートアップファイル ( ~/.bashrc ファイルもしくは ~/.profile ファイル) にそれを記述します (使用しているシェルを確認したい場合は、 echo $SHELL を実行してください) 。下記のようなコマンドを実行することで、 oracle ユーザに対する bash シェルのリソース制限を設定することができます:

# su - oracle
> cat >> ~oracle/.bash_profile << EOF
ulimit -n 63536
EOF

ポリシーや監査の理由から、もしくはユーザに対してセキュリティ手順を示しておく理由から、ログイン時にバナーを表示させることができます。

SSH やローカルコンソールなどからユーザがログインした 後 にログインバナーを表示させたい場合は、 /etc/motd (motd = message of the day の略) ファイルにそれを記述します。このファイルは openSUSE Leap の既定で提供されていますが、特に何も書かれていません。表示したい内容をそのまま記述してください。

注記: バナーの長さについて

バナーとして表示するメッセージは、長くても端末 1 ページ以内に収まるようにしてください。端末によってはスクロールして戻ることができない場合があるため、長すぎると読めなくなってしまうことがあるためです。

ログインバナーはテキストベースの端末であれば、ログイン 前 に表示することもできます。ローカルコンソールへのログイン前に表示したい場合は /etc/issue ファイルに内容を記述してください。これはログインプロンプトよりも前に表示されます。 SSH 経由でのログインの場合は、 /etc/ssh/sshd_config ファイルの 「Banner」 パラメータを設定してください。こちらも SSH のログインプロンプトよりも前に表示されます。

GDM 経由でのグラフィカルログインの場合は、 GNOME 管理者ガイド (英語) にある手順でログインバナーを設定することができます。これに加えて、 はい か いいえ を選択するようなバナーを表示することもできます。これを行うには、 /etc/gdm/Xsession ファイルを編集して、スクリプトの 最初のほう に下記のような内容を記述します:

if ! /usr/bin/gdialog --yesno '
This system is classified...
' 10 10; then
    /usr/bin/gdialog --infobox 'Aborting login'
    exit 1;
fi

上記の This system is classified... の部分に、表示したいバナーテキストを指定します。なお、このダイアログはログイン処理そのものを防ぐ仕組みではありません。 GDM のスクリプト処理について、詳しくは GDM 管理者マニュアル (英語) をお読みください。

下記はユーザログインに関するデータを取得できるコマンドの一覧です:

who： 現時点でログインしているユーザを一覧表示します。

w： 誰がログインしているのかと、何をしているのかを表示します。

last： 直近のユーザログインを一覧で表示します。ログイン日時のほかログアウト日時、 IP アドレスなどの情報が含まれます。

lastb： last と同じ出力を行いますが、こちらはログインの失敗を記録する /var/log/btmp の内容を出力します。

lastlog： このコマンドは、各ユーザの最終ログイン日時を記録する /var/log/lastlog 内のデータを出力します。

ac： acct パッケージをインストールすると利用できるようになるコマンドです。このコマンドは、ユーザ単位もしくは日単位の接続時間を表示します。このコマンドは /var/log/wtmp を読み込んで処理します。

dump-utmp： /var/run/utmp もしくは /var/log/wtmp の内容を読み込んで、これをテキストとして処理可能な形式に変換します。

そのほかにも /var/log/messages や journalctl コマンドの出力を確認してもかまいません。前者は何らかのログ記録 (syslog) アプリケーションが動作している場合、後者は動作していない場合に使用します。 journalctl で使用する systemd のジャーナル機能については、 第11章 「journalctl : systemd ジャーナルへの問い合わせコマンド」 をお読みください。