はじめに
Linux の "su" (substitute user) コマンドは、ユーザーが一時的に別のユーザーアカウント、多くの場合 root ユーザーに切り替えて、管理タスクを実行できるようにする強力なツールです。しかし、su の認証失敗が発生すると、アクセス拒否や潜在的なセキュリティリスクにつながる可能性があります。このチュートリアルでは、Linux 上での su 認証失敗のトラブルシューティングプロセスについて説明します。一般的な原因、設定、および安全な su 使用のためのベストプラクティスをカバーします。
su コマンドの理解と基本的な使用法
Linux の su コマンドを使用すると、ユーザーは現在のユーザー ID を別のユーザーに切り替えることができます。これは、権限昇格を必要とする管理タスクを実行する際に特に役立ちます。
su コマンドの基本的な使用法を探り、その仕組みを理解しましょう。
Su の基本的な使用法
LabEx VM 環境でターミナルを開きます。次の構文で su コマンドを使用できます。
su [options] [username]
ユーザー名を指定せずに su を実行すると、デフォルトで root ユーザーになります。
su
このコマンドは root を対象にしますが、Ubuntu では通常、root のパスワード認証がロックされています。ここで認証に失敗するのは想定された結果です。root のパスワードログインを有効にしたり、プラットフォームのアカウントを変更したりしないでください。以下の成功するログイン試験では、すべてこの実験専用の一時ユーザーを使います。
練習用にテストユーザーを作成しましょう。
sudo adduser testuser
プロンプトが表示されたら、必要な情報を入力します。この一時的なテストアカウントだけに、練習用のパスワードとして DemoUser123! を使ってください。labex のパスワードや sudo グループへの所属は変更しないでください。
次に、このユーザーに切り替えてみましょう。
su testuser
プロンプトが表示されたら、testuser 用に作成したパスワードを入力します。認証されると、プロンプトが変わり、testuser として操作していることを示します。
ユーザーが正常に切り替わったことを確認するには、次を実行します。
whoami
出力は次のようになります。
testuser
元のユーザーに戻るには、単に次のように入力します。
exit
オプション付きでの Su の使用
su コマンドはいくつかのオプションをサポートしています。最も一般的なのは - (ハイフン) オプションで、完全なログイン環境を提供します。
su - testuser
これは、ユーザー ID を切り替えるだけでなく、次のことも行います。
- ターゲットユーザーのホームディレクトリに移動します
- ターゲットユーザーの環境変数を設定します
- ログインシェルを提供します
このコマンドを試して、違いを観察してください。
pwd
出力は testuser のホームディレクトリを表示します。
/home/testuser
次のように入力して、testuser から終了します。
exit
su コマンドのこの基本的な理解は、次の手順で認証失敗のトラブルシューティングに役立ちます。
一般的な Su 認証失敗とその原因
このステップでは、よくある su 認証失敗を再現して調べます。これらの失敗を理解することが、それらを解決するための最初のステップです。
認証失敗のテスト
理解を深めるために、意図的にいくつかの認証失敗を作成してみましょう。
- 間違ったパスワードで testuser に切り替えてみます。
su testuser
間違ったパスワードを入力します。次のようなエラーメッセージが表示されます。
su: Authentication failure
- 存在しないユーザーに切り替えてみます。
su nonexistentuser
次のようなエラーメッセージが表示されます。
su: user nonexistentuser does not exist
認証失敗の一般的な原因
1. 間違ったパスワード
認証失敗の最も一般的な原因は、単に間違ったパスワードを入力することです。これは、次のような理由で発生する可能性があります。
- タイプミス
- Caps Lock が有効になっている
- パスワードを忘れた
2. アカウントの制限
一部のアカウントは、ログインを防止するように構成されているか、パスワードの有効期限が切れている可能性があります。
これを実証するために、テストユーザーを変更してみましょう。
sudo usermod -L testuser
-L オプションは、一時的な testuser アカウントのパスワード認証をロックします。次に試してください。
su testuser
正しいパスワードを入力しても、認証失敗が表示されます。
-U オプションは、このパスワードのロックを解除します。次のコマンドで、このテストアカウントだけのロックを解除してください。
sudo usermod -U testuser
3. PAM 設定の問題
Pluggable Authentication Modules (PAM) システムは、Linux での認証を制御します。PAM 設定の問題は、su の失敗を引き起こす可能性があります。
su コマンドの PAM 設定を調べてみましょう。
cat /etc/pam.d/su
このファイルには、su コマンドに固有の PAM 設定が含まれています。次のような、アクセスを制限する可能性のある行を探します。
auth required pam_wheel.so
この行は、コメントアウトされていない場合、su のアクセスを wheel グループのメンバーに制限します。
4. Su バイナリの権限の問題
su コマンドのバイナリファイルは、正しく機能するために適切な権限を持っている必要があります。
ls -l $(which su)
出力は次のようになります。
-rwsr-xr-x 1 root root 71816 Apr 18 2022 /usr/bin/su
権限の s は、setuid ビットが設定されていることを示しており、プログラムが実行したユーザーではなく、所有者 (root) の権限で実行できるようになります。
5. 認証ログの確認
この LabEx VM で認証失敗を調査する際は、lastb でログイン失敗の記録を確認します。
sudo lastb | head
このコマンドは /var/log/btmp を読み取り、最近の認証失敗を表示します。システムに記録されている場合は、失敗した su の試行も含まれます。
たとえば、失敗した su の試行では、切り替え先ユーザーとターミナルセッションを含むエントリが表示される場合があります。
su 認証失敗のこれらの一般的な原因を理解することで、次の手順で問題をより効果的に特定して解決できます。
Su コマンドのアクセス制御の設定
このステップでは、一時的な切り替え先アカウントに対して PAM のグループルールをテストします。root のパスワードログインを有効にしたり、プラットフォームへのアクセスを制限したりすることはありません。
一時アカウントを準備する
元の labex シェルから始めます。sudo を使う前に、現在のユーザーを確認してください。
whoami
結果は labex である必要があります。二つ目の呼び出し元と、別の切り替え先アカウントを作成し、それらの一時アカウントだけにパスワードを設定します。
sudo adduser --disabled-password --gecos '' testuser2
sudo adduser --disabled-password --gecos '' su-lab-target
printf '%s\n' 'testuser2:DemoOther123!' 'su-lab-target:DemoTarget123!' | sudo chpasswd
sudo groupadd sugroup
sudo usermod -aG sugroup testuser
sugroup のメンバーは testuser だけです。新しいログインシェルには、このグループへの所属が反映されます。両方の呼び出し元のテストで、切り替え先のパスワードは DemoTarget123! です。
特定の切り替え先だけに PAM ルールを適用する
PAM は /etc/pam.d/su を通じて su の認証を制御します。セットアップは、元の内容を /opt/labex/su-demo に保存しています。以下では、切り替え先が su-lab-target の場合だけグループを確認する設定を、先頭に追加します。最初のルールは、labex を含むそれ以外のすべての切り替え先について、次のルールをスキップします。use_uid は呼び出し元の実際のユーザーを確認し、group=sugroup は許可するグループを指定します。
sudo python3 - <<'PY'
from pathlib import Path
original = Path('/opt/labex/su-demo/pam-su.original').read_text()
prefix = """## Lab-only rule for su-lab-target
auth [success=1 default=ignore] pam_succeed_if.so quiet user != su-lab-target
auth required pam_wheel.so use_uid group=sugroup
"""
Path('/etc/pam.d/su').write_text(prefix + original)
PY
元の PAM ルールは、この追加部分の後に残ります。グループへの所属は、パスワード認証を置き換えるものではありません。labex をデモ用グループに追加したり、SSH、sudo、プラットフォームのアカウント設定を編集したりしないでください。
グループ外の呼び出し元をテストする
DemoOther123! を使い、labex から testuser2 に切り替えます。
su - testuser2
そのシェルから、正しいパスワード DemoTarget123! を使って、今回の対象アカウントへの切り替えを試します。
su - su-lab-target
testuser2 は sugroup に所属していないため、認証エラーで失敗する必要があります。su が失敗した場合、新しいシェルは作成されません。一度 exit して labex に戻ります。
exit
whoami
続ける前に、whoami が labex を表示することを確認してください。
グループ内の呼び出し元をテストする
ステップ 1 で設定した DemoUser123! パスワードを使い、testuser に切り替えます。
su - testuser
id
su - su-lab-target
切り替え先のパスワードとして DemoTarget123! を入力します。この切り替えは成功するはずです。切り替え先のユーザーを確認してください。
whoami
出力は su-lab-target になるはずです。シェルを二つ開いたため、二度 exit します。最初は testuser に戻り、次に labex に戻ります。
exit
exit
whoami
whoami が labex を表示することを確認してください。一時ユーザーのシェルから復元コマンドを実行してはいけません。
元のポリシーを復元する
labex から、保存しておいた設定を復元し、元の内容と比較します。
sudo cp -p /opt/labex/su-demo/pam-su.original /etc/pam.d/su
sudo cmp /opt/labex/su-demo/pam-su.original /etc/pam.d/su
比較が成功すると、何も出力されません。デモ用のグループとユーザーは診断のために残りますが、su は再び元のポリシーを使います。
Su 認証失敗のトラブルシューティングと解決
このステップでは、体系的な手順で su 認証失敗を調査し、解決します。
認証失敗を診断する
su 認証失敗が発生したら、以下の手順で問題を診断します。
手順 1：エラーメッセージを確認する
エラーメッセージは、失敗の種類を知る手がかりになります。よくあるメッセージは以下の通りです。
su: Authentication failure：通常、パスワードが正しくないことを示します。su: user username does not exist：指定されたユーザーアカウントが存在しません。su: permission denied：アクセス制御によって操作が拒否されています。
手順 2：ユーザーアカウントを確認する
切り替え先のアカウントが存在し、ロックされていないことを確認します。
grep testuser /etc/passwd
パスワードファイルの testuser のエントリが表示され、アカウントの存在を確認できます。
アカウントがロックされているかを確認します。
sudo getent shadow testuser | cut -d: -f2 | cut -c1
このコマンドは、一時アカウントのパスワードフィールドの最初の一文字だけを表示し、パスワードハッシュは表示しません。先頭の ! は、パスワード認証がロックされていることを意味します。
手順 3：アクセス制御による制限を確認する
前のステップで学んだように、PAM 設定は su へのアクセスを制限できます。該当する制限を確認します。
grep -v "^#" /etc/pam.d/su | grep pam_wheel
pam_wheel.so を含む行が返る場合は、su へのアクセスが特定のグループのメンバーに制限されている可能性があります。
手順 4：システムのログを確認する
ログイン失敗の記録から、認証失敗について役立つ情報を得られます。
sudo lastb | head
失敗した su の試行に関連するエントリを探してください。追加の状況がわかる場合があります。
よくある Su 認証失敗を解決する
次に、よくある su 認証失敗と、その解決方法を確認します。
1. パスワードが正しくない
正しいパスワードを入力しても認証に失敗する場合は、パスワードのリセットが必要かもしれません。
printf '%s\n' 'testuser:DemoUser123!' | sudo chpasswd
このコマンドは、一時的な testuser のパスワードだけを既知の練習用の値に戻します。labex や root は変更しません。
2. アカウントがロックされている
アカウントがロックされている場合は、ロックを解除します。
sudo usermod -U testuser
3. アクセス制御による制限
アクセス制御が su へのアクセスを妨げている場合は、以下のいずれかを行えます。
a. 必要なグループにユーザーを追加する：
sudo usermod -aG sugroup testuser2
これにより、testuser2 が sugroup に追加されます。
b. この実験では、保存した元のファイルを復元して、デモ用のポリシーだけを取り除く：
sudo cp -p /opt/labex/su-demo/pam-su.original /etc/pam.d/su
この操作は、任意の認証ルールを無効にする代わりに、su の元のポリシーを正確に復元します。
4. ファイルの権限に問題がある
プラットフォームのバイナリを変更せずに、su バイナリの権限を確認します。
ls -l "$(command -v su)"
想定される setuid ビットは、所有者の実行権限の位置に s と表示されます。プラットフォームのバイナリが壊れている場合は、権限を変更するのではなく、新しい VM を使ってください。
修正をテストする
修正を適用した後、su 認証が正しく動作するかをテストします。
su - testuser
プロンプトが表示されたら、testuser のパスワードを入力してください。成功すると、testuser としてログインしているはずです。
whoami を実行して testuser であることを確認し、exit を一度実行して labex に戻ってください。成功の確認に root のパスワードログインを使わないでください。一時アカウントへのログインが成功例です。
これらの手順と修正により、よくある su 認証失敗に対処できます。体系的に診断して解決することで、システム上で su コマンドが正しく動作するようにできます。
安全な Su の使用のためのベストプラクティス
このステップでは、安全な権限の使い方を確認し、デモによってプラットフォームへのアクセスが変更されていないことを確認します。
個別の管理コマンドには Sudo を優先する
Sudo は、root のパスワードを共有せずに、個別の管理操作を許可して記録できます。labex シェルから、root のログインシェルを起動せずに root のホームディレクトリを一覧表示します。
sudo ls /root
プラットフォームの既存の sudo ポリシーを保持してください。ポリシーを変更せずに、自分に許可されているコマンドを確認できます。
sudo -l
認証の変更範囲を限定する
本番システムでは、管理者は承認された設定管理手順を通じて、root ログイン、パスワードの品質、認証ポリシーを管理します。この演習では、SSH の設定、labex のパスワード、labex のグループ所属は変更しません。強力なパスワードポリシーや多要素認証には、それぞれ別の実装が必要です。このチュートリアルは、どちらも設定しません。
一時的な su ポリシーが取り除かれたことを確認します。
sudo cmp /opt/labex/su-demo/pam-su.original /etc/pam.d/su
出力がなければ、ポリシーは保存しておいた元の内容と一致しています。
認証に失敗した試行を監査する
ログイン失敗のデータベースを使って、失敗した試行を調査します。
sudo lastb | head
このコマンドは /var/log/btmp を読み取ります。成功した su セッションをすべて表示するものではありません。システムが実際に書き込んだ記録だけを解釈し、本番環境では繰り返される失敗を調査してください。
ログイン環境を使い、明示的に戻る
ダッシュオプションは、切り替え先ユーザーのログイン環境を起動します。testuser のパスワード DemoUser123! を使ってください。
su - testuser
whoami
exit
whoami
二つのユーザー確認では、最初に testuser、次に labex が表示されるはずです。exit が閉じるのは、su が作成したシェルだけです。VM には、元のプラットフォームのログイン、sudo アクセス、su ポリシーが維持されています。
まとめ
この実験では、Linux の su コマンドについて調査し、一般的な認証失敗のトラブルシューティング方法を学びました。以下をカバーしました。
suコマンドの基本的な使用法とその仕組みの理解- 間違ったパスワード、アカウント制限、PAM 設定の問題など、su 認証失敗の一般的な原因の特定
- セキュリティを強化するための
suコマンドのアクセス制御の設定 - 体系的な診断による su 認証失敗のトラブルシューティングと解決
- 可能な場合は sudo を使用し、強力なパスワードポリシーを設定し、su の使用状況を定期的に監査するなど、安全な su の使用のためのベストプラクティスの実装
これらのテクニックとベストプラクティスを適用することで、Linux システムのセキュリティを維持しながら、su コマンドが正しく機能するようにすることができます。適切な認証管理は、システム管理とセキュリティの重要な側面であることを忘れないでください。
