「rootで作業したいけどsuとsudoどちらを使えばいい?」「ユーザー切り替え後に環境変数が引き継がれて困った」——Linuxのユーザー切り替えは日常的に発生する操作ですが、suとsudoの違いや環境変数の扱いを正確に理解していないと、予期しないトラブルの原因になります。
この記事では、su・sudoコマンドの基本構文と使い分け・セキュリティ上の注意点・リモート接続時の運用方法まで体系的に解説します。
Linuxでユーザーを切り替える目的

管理者権限での作業が必要な場合
Linuxでは一般ユーザーが実行できる操作が制限されており、システム管理に関わる以下の作業にはroot(管理者)権限が必要です。
- パッケージのインストール・削除(
apt install・yum installなど) - システム設定ファイルの変更(
/etc/以下のファイル編集) - サービスの起動・停止・再起動(
systemctlコマンド) - ユーザーアカウントの作成・削除
- ネットワーク設定の変更
別ユーザーでの作業やテスト環境の利用
rootへの切り替えだけでなく、以下のような場面でも一般ユーザー間の切り替えが必要になります。
- Webアプリケーションの動作を特定のサービスユーザーで検証する
- cronジョブの実行ユーザーを確認してデバッグする
- 別ユーザーの権限設定をテストする
- 共有サーバーで別のユーザーの環境を管理者がチェックする
権限分離やセキュリティ管理の重要性
Linuxのセキュリティ設計の基本は最小権限の原則(Principle of Least Privilege)です。必要最小限の権限で作業することで、誤操作やマルウェアによる被害を最小限に抑えられます。
| アプローチ | リスク | 推奨度 |
|---|---|---|
| rootで常時作業する | 誤操作でシステム全体に影響が出る | × 非推奨 |
| 一般ユーザーで作業+必要時にsudo | 誤操作の影響範囲が限定される | ◎ 推奨 |
| 権限ごとに専用ユーザーを分ける | さらに細かい権限管理が可能 | ◎ 本番環境で推奨 |
suコマンドを使ったユーザー切り替え

基本構文
su ユーザー名 の使い方
su(switch user)コマンドは指定したユーザーにセッションごと切り替えるコマンドです。
# 基本構文
su [オプション] [ユーザー名]
# 一般ユーザーからwebappユーザーに切り替え
su webapp
# パスワードを求められるので入力する
Password:
# 切り替え後のユーザーを確認
whoami
# webapp
ユーザー名を省略した場合はrootへの切り替えになります。
# rootへの切り替え(ユーザー名省略)
su
# 上記と同じ意味
su root
rootユーザーへの切り替え
rootへ切り替える際はrootのパスワードが必要です。Ubuntu系ではデフォルトでrootのパスワードが設定されていないため、suでrootに切り替えられない場合があります。
# rootへの切り替え
su -
# Ubuntu系でrootパスワードが設定されていない場合
sudo su -
# または
sudo -i # rootシェルを起動する(推奨)
確認方法: root切り替え後はwhoamiコマンドでrootと表示されることを確認してください。プロンプトが$から#に変わったことでも確認できます。
パスワード入力の注意点
suコマンド実行時のパスワードは切り替え先ユーザーのパスワードです。sudoと混同しやすいので注意が必要です。
| コマンド | 要求されるパスワード |
|---|---|
su webapp |
webappユーザーのパスワード |
su root |
rootユーザーのパスワード |
sudo コマンド |
現在のユーザー自身のパスワード |
su – と su の違い(環境変数の引き継ぎ)
これがsuコマンドで最も重要な知識です。suとsu -では環境変数の扱いが大きく異なります。suコマンドの環境変数の挙動についてはこちらの記事も参考になります。
# su(ハイフンなし): 現在の環境変数を引き継いでユーザーを切り替え
su webapp
# su -(ハイフンあり): 切り替え先ユーザーの環境で完全にログインし直す
su - webapp
# 違いを確認する
su webapp
echo $HOME # 元のユーザーのホームディレクトリが表示される(/home/currentuser)
echo $PATH # 元のユーザーのPATHが引き継がれる
su - webapp
echo $HOME # 切り替え先のホームディレクトリが表示される(/home/webapp)
echo $PATH # 切り替え先ユーザーのPATHが設定される
| 比較項目 | su(ハイフンなし) | su -(ハイフンあり) |
|---|---|---|
| 環境変数 | 元のユーザーから引き継ぐ | 切り替え先ユーザーの設定を使用 |
| ホームディレクトリ | 変わらない | 切り替え先のHOMEに変更される |
| PATH | 元のユーザーのPATH | 切り替え先ユーザーのPATH |
| ログインシェル | 非ログインシェル | ログインシェル(.bash_profileが実行される) |
| 推奨場面 | 環境変数を維持したい場合 | 完全に別ユーザーとして作業したい場合 |
rootに切り替えてシステム管理作業を行う場合は必ずsu -を使ってください。suだと元ユーザーのPATHが引き継がれ、意図しないコマンドが実行される危険があります。
元のユーザーに戻るにはexitまたはCtrl+Dを実行します。
# 元のユーザーに戻る
exit
# または
logout
sudoコマンドを使った一時的な権限昇格

基本構文
sudo コマンド の使い方
sudo(superuser do)は、管理者権限が必要な単一のコマンドのみを昇格した権限で実行します。セッション全体を切り替えるsuとは根本的に異なります。sudoコマンドの基本的な使い方と活用例はこちらの記事も参考になります。
# 基本構文
sudo [オプション] コマンド
# パッケージのインストール(rootが必要な操作)
sudo apt install nginx
# ファイルのコピー(root権限が必要なディレクトリへ)
sudo cp config.conf /etc/nginx/conf.d/
# rootシェルの起動
sudo -i # su - と同等(rootのログインシェルを起動)
sudo su - # su -と同じ効果(rootに完全切り替え)
# 別ユーザーとしてコマンドを実行
sudo -u webapp ls /home/webapp
管理者権限で単発コマンド実行
sudoの最大の利点は、一般ユーザーとして作業しながら必要な操作だけroot権限で実行できる点です。
# サービスの再起動(root権限が必要)
sudo systemctl restart nginx
# システムファイルの編集
sudo vim /etc/ssh/sshd_config
# ディレクトリの作成(root権限が必要な場所)
sudo mkdir /opt/myapp
# ファイルの権限変更
sudo chmod 644 /etc/nginx/nginx.conf
# 複数コマンドを連続実行
sudo apt update && sudo apt upgrade -y
パスワードと権限設定の注意
sudo実行時は現在のユーザー自身のパスワードを入力します。一度認証に成功すると、デフォルトで15分間はパスワードなしでsudoを実行できます。
# sudoのタイムスタンプを手動でクリア(セキュリティのため)
sudo -k
# 現在のsudo権限を確認する
sudo -l
# 出力例
# User user1 may run the following commands on this host:
# (ALL : ALL) ALL # すべてのコマンドを実行可能
sudoersファイルによる権限管理
/etc/sudoersファイルでユーザーごとのsudo権限を細かく設定できます。sudoersの編集は必ずvisudoコマンドを使用してください。直接編集してシンタックスエラーが発生するとsudoが完全に使用不能になります。
# sudoersを安全に編集
sudo visudo
# sudoersの主な設定例
# ユーザーにすべてのコマンドを許可(一般的なsudoの設定)
username ALL=(ALL:ALL) ALL
# パスワードなしでsudoを許可
username ALL=(ALL) NOPASSWD: ALL
# 特定のコマンドのみ許可(推奨:最小権限の原則)
username ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx
# グループ単位での設定(%はグループを示す)
%sudo ALL=(ALL:ALL) ALL
%wheel ALL=(ALL) ALL
# 別ユーザーとして特定コマンドを実行する許可
username ALL=(webapp) /usr/bin/python3 /opt/app/script.py
# ユーザーをsudoグループに追加(Ubuntu/Debian系)
sudo usermod -aG sudo username
# ユーザーをwheelグループに追加(CentOS/RHEL系)
sudo usermod -aG wheel username
# グループへの追加を確認
groups username
ユーザー切り替え時の確認と注意点

whoamiコマンドで現在ユーザー確認
ユーザーを切り替えた後は、必ず現在のユーザーを確認する習慣をつけましょう。Linuxのユーザー管理コマンドの詳細はこちらの記事も参考になります。
# 現在のユーザーを確認
whoami
# 出力例: root
# より詳細な情報(UID・GID・グループ)を確認
id
# 出力例: uid=0(root) gid=0(root) groups=0(root)
# 現在のシェルのユーザー情報
echo $USER
# ホームディレクトリの確認
echo $HOME
# 現在ログインしているすべてのユーザーを確認
who
w
環境変数やホームディレクトリの違い
ユーザーを切り替えると環境変数が変わる場合があります。特にPATH・HOME・SHELLは作業前に確認が必要です。
# 主要な環境変数の確認
echo $PATH # コマンド検索パス
echo $HOME # ホームディレクトリ
echo $SHELL # 使用中のシェル
echo $USER # 現在のユーザー名
# すべての環境変数を表示
env
# su後に環境変数を確認する例
su - webapp
env | grep -E "HOME|PATH|USER|SHELL"
rootで作業する際の危険性
rootはすべてのファイルとプロセスへの完全なアクセス権を持ちます。誤操作が取り返しのつかない結果を招く可能性があります。
# 危険な操作の例(絶対に実行しないこと)
rm -rf / # システム全体を削除
rm -rf /* # ルートディレクトリの中身をすべて削除
chmod -R 777 / # すべてのファイルの権限を変更
# 安全に作業するためのチェックリスト
# 1. 現在のユーザーを確認(whoami)
# 2. 作業対象のパスを確認(pwd)
# 3. コマンドの対象ファイルを確認(ls -la)
# 4. 破壊的な操作の前にバックアップを作成
# 5. 作業が終わったらすぐにrootセッションを終了(exit)
不要な権限での作業を避ける
最小権限の原則を日常的に実践することがLinuxセキュリティの基本です。
- rootが必要な操作が終わったらすぐに
exitで一般ユーザーに戻る sudoで単発コマンドを実行できる場合はsuを使わない- sudoersで特定コマンドのみを許可する設定にする
- 不必要なユーザーにsudo権限を付与しない
リモート接続時のユーザー切り替え
SSHでのログインユーザー指定
SSHでリモートサーバーに接続する際に、接続するユーザーを指定できます。
# SSHで特定ユーザーとして接続
ssh [email protected]
# 秘密鍵を指定して接続
ssh -i ~/.ssh/id_rsa [email protected]
# rootとして直接SSH接続(セキュリティ上は非推奨)
ssh [email protected]
# ~/.ssh/configで設定を省略する方法
# Host myserver
# HostName 192.168.1.10
# User ubuntu
# IdentityFile ~/.ssh/id_rsa
# 設定後はホスト名だけで接続可能
ssh myserver
本番サーバーへのroot直接SSH接続は禁止することを強く推奨します。/etc/ssh/sshd_configでPermitRootLogin noを設定してください。
su・sudoを併用した作業方法
SSH接続後にsu・sudoを使ってユーザーを切り替える一般的なパターンです。SSH接続とsuコマンドを組み合わせたユーザー切り替えの実践例はこちらの記事も参考になります。
# 一般ユーザーでSSH接続後、管理者作業が必要になった場合
# パターン1: sudoで単発コマンドを実行
ssh [email protected]
sudo systemctl restart nginx
sudo apt update
# パターン2: sudoでrootシェルを起動して複数の管理作業を行う
ssh [email protected]
sudo -i # rootシェルを起動
# 管理作業を実行
exit # 作業完了後にrootを抜ける
# パターン3: 特定のサービスユーザーに切り替えてアプリ管理
ssh [email protected]
sudo su - webapp # webappユーザーとして完全に切り替え
cd /var/www/myapp
python3 manage.py migrate
exit # webappユーザーを抜ける
セキュアな接続と権限管理
リモート接続時のセキュリティベストプラクティスです。
# セキュリティ設定の確認(/etc/ssh/sshd_config)
# rootのSSH直接ログインを禁止
PermitRootLogin no
# パスワード認証を無効にして鍵認証のみ許可
PasswordAuthentication no
# 接続を許可するユーザーを限定
AllowUsers user1 user2 admin
# 設定変更後はsshdを再起動
sudo systemctl restart sshd
応用例
別ユーザーでのアプリテスト
Webアプリケーションが特定のサービスユーザーで正しく動作するかを検証する場合の手順です。
# www-dataユーザー(Apacheの実行ユーザー)として動作確認
sudo su - www-data -s /bin/bash
# www-dataユーザーの環境でアプリをテスト
cd /var/www/myapp
python3 app.py
# 権限の問題を確認
ls -la /var/www/myapp/logs/
# www-dataが書き込めるか確認
# テスト完了後に元のユーザーに戻る
exit
ファイルやディレクトリの権限変更
ファイルの所有者やパーミッションを別のユーザーに変更する操作です。
# ファイルの所有者をwebappに変更
sudo chown webapp:webapp /opt/myapp/config.yml
# ディレクトリ全体の所有者を再帰的に変更
sudo chown -R webapp:webapp /opt/myapp/
# パーミッションの変更(webappのみ読み書き可)
sudo chmod 600 /opt/myapp/config.yml
# webappユーザーに切り替えてファイルを確認
sudo su - webapp
ls -la /opt/myapp/
cat /opt/myapp/config.yml
exit
定期スクリプト実行ユーザーの切り替え
cronジョブで特定のユーザーとしてスクリプトを実行する設定です。
# ユーザー専用のcrontabを編集(そのユーザーの権限で実行される)
sudo crontab -u webapp -e
# webapp ユーザーのcrontabに追記
# 毎日深夜2時にバックアップスクリプトを実行
0 2 * * * /home/webapp/scripts/backup.sh >> /home/webapp/logs/backup.log 2>&1
# 設定確認
sudo crontab -u webapp -l
# rootのcrontabからsudoで別ユーザーとして実行する方法
# /etc/crontab に追記
# 0 2 * * * webapp /home/webapp/scripts/backup.sh
# スクリプトが正しいユーザーで動作するかテスト
sudo -u webapp /home/webapp/scripts/backup.sh
まとめ
suは環境を引き継ぐ完全切り替え、sudoは単発権限昇格
Linuxのユーザー切り替えコマンドの使い分けを正確に把握することが安全な運用の基本です。
| コマンド | 動作 | パスワード | おすすめ場面 |
|---|---|---|---|
su webapp |
環境変数を引き継いでユーザー切り替え | 切り替え先のパスワード | 環境変数を保持したい場合 |
su - webapp |
完全に切り替え先ユーザーの環境でログイン | 切り替え先のパスワード | 完全な別ユーザーとして作業する場合 |
sudo コマンド |
単発コマンドのみroot権限で実行 | 現在ユーザーのパスワード | 1〜2コマンドだけroot実行したい場合 |
sudo -i |
rootのログインシェルを起動 | 現在ユーザーのパスワード | 複数の管理作業をrootで行う場合 |
現在ユーザーの確認や環境に注意して作業
- ユーザー切り替え後は必ず
whoami・idで現在のユーザーを確認する su -とsuの環境変数・HOMEの違いを理解して使い分ける- rootでの作業が終わったらすぐに
exitで一般ユーザーに戻る - 本番サーバーへのroot直接SSH接続は
sshd_configで禁止する
権限管理を意識して安全にユーザー切り替えを活用
最小権限の原則に基づき、必要なコマンドだけをsudoで実行し、sudoersで特定コマンドのみを許可する設定にすることでLinuxサーバーのセキュリティを高く維持できます。visudoで丁寧にsudoers設定を管理し、rootでの作業時間を最短にとどめることが、安全なLinux管理の基本です。

