Linuxのsuとsudoの違い｜su -・sudo -i・-sの比較表

su は「別のユーザーに切り替える」コマンドで切り替え先のパスワードを使い、sudo は「許可された人が、別のユーザーの権限でコマンドを実行する」コマンドで自分のパスワードを使います。 どちらも root の権限で作業するために使われますが、パスワードの持ち方、環境変数、ログの残り方が異なります。

この記事では、su、su -、sudo コマンド、sudo -s、sudo -i、sudo su - の6通りを、Ubuntu 24.04.4 LTS（sudo 1.9.15p5、util-linux 2.39.3 の su）で実行した結果をもとに比べます。ユーザー名とホームディレクトリの表示は、検証用のユーザー名を taro（操作する人）と hanako（切り替え先の一般ユーザー）に置き換えています。RHEL系での動作など、手元で動かせなかった部分は「未実行」と明記しています。

su と sudo の比較早見表

結論を先に書くと、普段は sudo コマンド、root のまま続けて作業したいときは sudo -i を使えば足ります。 以降で、この表の各マスを実行結果で確かめていきます。

su と sudo の仕組みの違い

flowchart LR
    U["taro（一般ユーザー）"]
    subgraph S1["su"]
        A1["root のパスワードを入力"] --> A2["root のシェルが起動"]
    end
    subgraph S2["sudo"]
        B1["自分のパスワードを入力"] --> B2["sudoers で許可を確認"] --> B3["コマンドを root で実行<br>記録を残す"]
    end
    U --> S1
    U --> S2

su は root のパスワードを使う人全員で共有することになります。sudo なら各自が自分のパスワードで操作でき、だれが何を実行したかも記録に残るため、複数人で管理するサーバーでは sudo が基本になっています。

6通りを実行結果で比べる

検証の準備

一般ユーザー taro でログインし、ホーム以外のディレクトリに移動して、目印の環境変数を1つ設定しておきます。

cd /tmp/work
export MYVAR=hello
whoami; pwd; echo $HOME
echo $PATH

実行結果（表示は環境に合わせて置き換えています。以下同じ）:

taro
/tmp/work
/home/taro
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

各コマンドのあとで、ユーザー・カレントディレクトリ・HOME・PATH・MYVAR・SUDO_USER・ログインシェルかどうか（shopt -q login_shell）を表示して比べました。

su（ハイフンなし）

su はユーザー名を省略すると root に切り替えます。Ubuntu は初期状態で root のパスワードが設定されていないため、su で root になろうとすると認証エラーになります。

su

実行結果:

Password: 
su: Authentication failure

そこで、su の環境の扱いは、パスワードを設定した一般ユーザー hanako への切り替えで確かめました（root を切り替え先にした su は未実行です）。

su hanako
whoami; pwd; echo $HOME; echo $MYVAR

hanako
/tmp/work
/home/hanako
hello

ユーザーと HOME は切り替わりますが、カレントディレクトリと自分で設定した環境変数（MYVAR）はそのまま残ります。 ログインシェルではないので、~/.profile は読まれません。

su -（ハイフンあり）

su - hanako
whoami; pwd; echo $HOME; echo $MYVAR

実行結果（~/.profile に目印の echo を入れてあります）:

[.profile read]
hanako
/home/hanako
/home/hanako

su - は切り替え先のユーザーとしてログインし直した状態を作ります。 カレントディレクトリは切り替え先のホームになり、MYVAR は消え、~/.profile が読み込まれました。PATH も /etc/profile や ~/.profile の内容で作り直されます。su -、su -l、su --login は同じ意味です。

sudo コマンド

sudo whoami
sudo pwd
sudo sh -c 'echo $HOME'
sudo echo $HOME

実行結果:

[sudo] password for taro: 
root
/tmp/work
/root
/home/taro

入力するのは taro 自身のパスワードです。 カレントディレクトリは元のまま、HOME は /root になりました。4行目が /home/taro になっているのは、$HOME が sudo に渡る前に taro のシェルで展開されるためです。root 側の値を見たいときは、3行目のように sh -c '...' の中に書きます。

環境変数は次のようになりました。

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
SUDO_USER=taro MYVAR=

PATH は sudoers の secure_path に置き換わり、MYVAR は取り除かれ、SUDO_USER に元のユーザー名が入ります。

sudo -s

sudo -s
whoami; pwd; echo $HOME

root
/tmp/work
/root

sudo -s は root のシェルを起動します。カレントディレクトリは元のままで、ログインシェルではありません（login_shell は off、SUDO_USER=taro）。今いるディレクトリでそのまま root の作業を続けたいときに向いています。

sudo -i

sudo -i
whoami; pwd; echo $HOME

root
/root
/root

sudo -i は root のログインシェルを起動します。カレントディレクトリは /root になり、ログインシェルとして /etc/profile や root の ~/.profile が読まれます（login_shell は on、起動名は -bash）。PATH も root のログイン用の設定で作り直されました。SUDO_USER=taro は残るので、だれが root になったのかを後から確認できます。

sudo su と sudo su -

sudo su -
whoami; pwd; echo $HOME; echo "SUDO_USER=$SUDO_USER"

root
/root
/root
SUDO_USER=

sudo su - は「sudo で root になってから、su で root としてログインし直す」という2段階の動作です。結果は sudo -i とほぼ同じですが、su - が環境を作り直すため SUDO_USER が消えました。ハイフンなしの sudo su では、カレントディレクトリは /tmp/work のまま、SUDO_USER=taro も残りました。

実行結果のまとめ表

Ubuntu 24.04 の su は、PAM（認証の仕組み）の設定で /etc/environment を読むため、sudo su のPATHには /usr/games などが含まれていました。PATH の中身はディストリビューションや設定で変わるので、手元では echo $PATH で確かめるのが確実です。

読み込む設定ファイルの違い

シェルがログインシェルとして起動するかどうかで、読み込まれるファイルが変わります（bash の場合）。

今回は、su - hanako と sudo -u hanako -i で ~/.profile に入れた目印が表示されること、su hanako では表示されないことを確かめました。「root でログインしたときと同じ PATH やエイリアスで作業したい」ときは、ログインシェルになる sudo -i か su - を選びます。

sudo でよく使うオプション

sudo -l で許可内容を確認する

sudo -l

実行結果（sudo グループに入っている taro の場合）:

Matching Defaults entries for taro on vm:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
    use_pty

User taro may run the following commands on vm:
    (ALL : ALL) ALL

(ALL : ALL) ALL は「どのユーザー・グループとしても、すべてのコマンドを実行できる」という意味です。vm は検証環境のホスト名です。

パスワードの有効時間（-v、-k、-n）

sudo -v          # 認証して有効時間を更新
sudo -n true; echo "exit=$?"
sudo -k          # 有効時間を取り消す
sudo -n true; echo "after -k exit=$?"

実行結果:

exit=0
sudo: a password is required
after -k exit=1

一度認証すると、しばらくはパスワードなしで sudo を実行できます。席を離れる前に sudo -k を実行しておくと、次の sudo で再びパスワードが求められます。

環境変数を引き継ぐ（-E）

sudo -s では MYVAR が空になりましたが、sudo -E -s では MYVAR=hello が残ることを確かめました。プロキシの設定など、自分の環境変数を root 側でも使いたいときに使います。

リダイレクトは sudo の外で処理される

sudo echo x > /etc/test.conf

実行結果:

bash: /etc/test.conf: Permission denied

> によるファイルへの書き込みは、sudo ではなく taro のシェルが行うため、権限が足りずに止まります。root でファイルに書き込むときは tee を sudo で動かします。

echo x | sudo tee /tmp/work/root_owned >/dev/null
ls -l /tmp/work/root_owned

-rw-r--r-- 1 root root 2 Oct  3 08:25 /tmp/work/root_owned

別のユーザーとして実行する（sudo -u と su -c）

su も sudo も、切り替え先は root に限りません。アプリケーション用のユーザーとして操作したいときにも使えます。

sudo -u hanako whoami
sudo -u hanako sh -c 'echo $HOME; pwd'
sudo -u hanako -g hanako id

実行結果:

hanako
/home/hanako
/tmp/work
uid=1002(hanako) gid=1003(hanako) groups=1003(hanako)

sudo -u は自分のパスワードで実行できるので、切り替え先のユーザーにパスワードを設定しておく必要がありません。 ログインできない設定のサービス用ユーザーを扱うときに便利です。su でコマンドを1つだけ実行したいときは -c を使います。

su - hanako -c 'whoami; pwd'

Password: 
[.profile read]
hanako
/home/hanako

root から su を実行するときにパスワードを聞かれないのは、/etc/pam.d/su の auth sufficient pam_rootok.so という行によるものです（Ubuntu 24.04 で確認）。同じファイルには pam_wheel.so を使って su を実行できる人を特定のグループに絞る設定がコメントの形で用意されています（有効化は未実行）。

sudo が設定する環境変数

sudo で実行したコマンドからは、元のユーザーの情報を環境変数で参照できます。

sudo env | grep -E '^(SUDO_|HOME|USER|LOGNAME|SHELL|MAIL)' | sort

実行結果（UIDとGIDは環境により異なります）:

HOME=/root
LOGNAME=root
MAIL=/var/mail/root
SHELL=/bin/bash
SUDO_COMMAND=/usr/bin/env
SUDO_GID=1002
SUDO_UID=1001
SUDO_USER=taro
USER=root

スクリプトの中で「sudo を付けて実行した人」を知りたいときは $SUDO_USER を使います。特定の変数だけを引き継ぎたいときは sudo --preserve-env=MYVAR コマンド と書けます（MYVAR=hello が渡ることを確認しました）。

su と sudo が root の権限で動ける理由

ls -l /usr/bin/sudo /usr/bin/su

-rwsr-xr-x 1 root root  55680 Aug 20 01:47 /usr/bin/su
-rwsr-xr-x 1 root root 277936 Mar  2  2026 /usr/bin/sudo

権限の rws の s は setuid という印で、だれが実行しても、所有者である root の権限で動くことを表します。su と sudo はこの仕組みで起動し、パスワードや sudoers を確認したうえで、許可された操作だけを実行します。

つまずきやすい表示と対処

sudo cd /root を実行したときの表示は次のとおりで、sudo 自身が代わりの方法を案内してくれます。

sudo: cd: command not found
sudo: "cd" is a shell built-in command, it cannot be run directly.
sudo: the -s option may be used to run a privileged shell.
sudo: the -D option may be used to run a command in a specific directory.

端末のない場所から sudo を実行したときは、次の表示になりました。

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

定期実行のスクリプトで sudo が必要になったときは、スクリプト全体を root で動かすか、必要なコマンドだけを NOPASSWD: で許可する形にすると、パスワードをスクリプトに書かずに済みます。

Ubuntu系とRHEL系の違い

Ubuntu 24.04 の /etc/sudoers から、コメントを除いた有効な行は次のとおりでした（実行結果）。

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults    use_pty
root    ALL=(ALL:ALL) ALL
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
@includedir /etc/sudoers.d

RHEL系の表の内容と wheel グループの行は、一般に知られた既定の設定をもとにしており、今回は未実行です。

「sudoersファイル内にありません」を再現して直す

エラーを再現する

sudo グループに入っていないユーザーで sudo を実行すると、次の表示になります。

sudo whoami

実行結果:

[sudo] password for taro: 
taro is not in the sudoers file.

日本語の表示にしている環境では「taro は sudoers ファイル内にありません。」という文になります（日本語メッセージは今回の環境では表示できず、未実行です）。このとき sudo -l も次のように表示されました。

Sorry, user taro may not run sudo on vm.

パスワードは合っているが、sudo を使う許可がないという状態です。パスワードが違う場合は別の表示になります。

[sudo] password for taro: 
Sorry, try again.

直し方1：グループに追加する（おすすめ）

sudo を使える別のユーザー（または root）で、対象のユーザーを sudo グループに追加します。

# Ubuntu系
sudo usermod -aG sudo taro
# RHEL系（未実行）
sudo usermod -aG wheel taro
id taro

実行結果（Ubuntu 24.04、ユーザーIDなどの数字は環境により異なります）:

uid=1001(taro) gid=1002(taro) groups=1002(taro),27(sudo)

グループの変更は次のログインから有効になります。taro でログインし直してから確かめると、root として実行できました。

sudo whoami

root

-aG の -a を付け忘れると、ほかの所属グループが外れてしまうので、必ず -aG の形で書きます。グループから外したときに再び taro is not in the sudoers file. に戻ることも確かめました。

直し方2：visudo で設定を追加する

特定のコマンドだけを許可したいときは、sudoers に設定を書きます。sudoers は必ず visudo で編集します。 visudo は保存時に文法を確認してくれるため、書き間違いで sudo が使えなくなる状況を防げます。

sudo visudo                       # /etc/sudoers を編集
sudo visudo -f /etc/sudoers.d/taro   # 個別のファイルに分けて書く（おすすめ）

書き方は「だれが どのホストで=(だれとして) 何を」の順です。

taro   ALL=(ALL) ALL
%devs  ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

1行目は taro にすべてのコマンドを許可、2行目は devs グループに「nginx の再起動だけをパスワードなしで」許可する例です。

今回の検証環境では共有の設定ファイルを書き換えられないため、/etc/sudoers の編集そのものは未実行です。代わりに、visudo の文法チェック機能（-c）を、作業用ディレクトリに置いたファイルに対して実行しました。

visudo -c
visudo -cf /tmp/ok.sudoers     # 上の2行を書いたファイル
visudo -cf /tmp/ng.sudoers     # かっこを閉じ忘れたファイル

実行結果:

/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/tmp/ok.sudoers: parsed OK
/tmp/ng.sudoers:1:15: syntax error
taro ALL=(ALL ALL
              ^~~

文法の誤りは行番号と位置つきで教えてくれます。 /etc/sudoers.d/ にファイルを置く前に visudo -cf ファイル で確認する習慣を付けると安心です。なお、/etc/sudoers の権限は -r--r-----（root だけが読める）でした。

管理者がだれもいないとき

sudo を使えるユーザーが1人もいない場合は、root として操作できる別の手段が必要です。RHEL系で root のパスワードがわかるなら su - で root になってから usermod -aG wheel taro を実行します。クラウドの仮想マシンでは初期ユーザーに sudo の権限が付いているので、そのユーザーで操作します（いずれも未実行）。

ログの残り方の違い

sudo は「だれが・どのディレクトリで・だれとして・何を実行したか」を記録します。 su は「だれがだれに切り替えたか」までで、切り替えたあとに実行したコマンドは認証ログには残りません。

記録の確認先は、Ubuntu系が /var/log/auth.log、RHEL系が /var/log/secure、systemd の環境では journalctl です。sudo の記録は一般に次のような形になります（書式の例です。今回の検証環境はログ収集のサービスが動いておらず、未実行です）。

sudo:     taro : TTY=pts/0 ; PWD=/tmp/work ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

1コマンドずつ sudo コマンド で実行するほど、後から経緯を追いやすくなります。 root のシェルに入ると操作が1行にまとまってしまうため、手順を残したい作業では sudo コマンド の形が向いています。

どれを使うべきか（結論）

sudo su - は多くの手順書に登場し、結果も sudo -i とほぼ同じです。新しく手順を書くなら、コマンド1つで済み、SUDO_USER も残る sudo -i がすっきりします。 すでに sudo su - で書かれた手順は、そのまま使っても同じ環境になります。

作業前のチェックリスト

root のシェルではプロンプトの末尾が # になります（一般ユーザーは $）。作業が終わったら exit で戻る習慣を付けておくと、意図しない操作を減らせます。

よくある質問

Q. su と su - はどちらを使えばよいですか？ A. 迷ったら su - です。切り替え先のユーザーの PATH や設定ファイルで作業できるため、「コマンドが見つからない」といった差が出にくくなります。su は元のディレクトリのまま切り替えたいときに使います。

Q. sudo -i と sudo su - は何が違いますか？ A. 今回の実行結果では、ユーザー・カレントディレクトリ・HOME・ログインシェルである点は同じで、違いは SUDO_USER が残るかどうかと、PATH の一部でした。sudo -i は sudo だけで完結するので、記録も設定も sudo 側にまとまります。

Q. Ubuntu で root のパスワードを設定してもよいですか？ A. sudo passwd root で設定はできますが、Ubuntu は sudo で管理する前提で作られているため、sudo -i を使えば root のパスワードがなくても同じ作業ができます（passwd の実行は未実行）。

Q. sudo のたびにパスワードを聞かれないようにできますか？ A. sudoers に NOPASSWD: を付けると省略できます。すべてのコマンドに付けるより、systemctl restart nginx のように必要なコマンドだけに絞ると、便利さと安全さを両立できます。

Q. root のシェルから元のユーザーに戻るにはどうしますか？ A. exit と入力するか、Ctrl+D を押します。sudo su - のように2段階で入った場合も、su のシェルを抜けると sudo も終わるので、1回の exit で元のユーザーに戻ります。戻ったあとに whoami で確かめると確実です。

まとめ

• su は切り替え先のパスワード、sudo は自分のパスワードを使う
• su - と sudo -i はログインシェル。カレントディレクトリがホームになり、環境が作り直される
• su と sudo -s はカレントディレクトリがそのまま。ログインシェルではない
• Ubuntu は root のパスワードが未設定で su は認証エラーになる。sudo グループ（RHEL系は wheel）で管理する
• 「sudoers ファイル内にありません」はグループへの追加で直せる。usermod -aG のあとログインし直す
• sudoers の編集は visudo。visudo -cf で文法を確認できる
• 普段は sudo コマンド、続けて作業するなら sudo -i。記録が残り、後から経緯を追いやすい

株式会社RJCでは、suとsudoの使い分けのようなLinuxの基本を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。