この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxを学び始めた頃、多くの方がこの疑問を持ちます。私自身、2001年にLinuxサーバーの現場に入ったばかりの頃は、毎日
su -でrootに切り替えてから作業するのが当たり前でした。ところが、SE時代のある夜、rootで作業中に本番Webサーバーの重要なファイル群を誤って削除してしまいました。あの夜の青ざめた感覚と、深夜まで続いた緊急復旧作業の記憶が、私が「sudoの設計思想」と「最小権限の原則」を真剣に学ぶきっかけになりました。
この記事では、20年以上Linuxサーバーを運用し、3,100名以上を指導してきた現役講師の立場から、suとsudoの根本的な違い、sudoersの設定方法、そして現場でroot権限を安全に扱うための実践的な習慣をお伝えします。
この記事のポイント
・suはrootに「変身する」命令、sudoは「1コマンドだけ」root権限を借りる命令
・sudoの設計思想は最小権限の原則——必要なときだけ、必要な権限だけを与える
・sudoersの設定でユーザーごとに許可コマンドをきめ細かく制御できる
・rootで常時作業するとミス1回が取り返しのつかない事故になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ「suでrootになってから作業する」が当たり前になったのか
Linuxを学ぶとき、最初に高い壁として立ちはだかるのが「権限」の問題です。/etc/配下の設定ファイルを書き換えようとすると「Permission denied」が出る。Apacheを起動しようとしても「Operation not permitted」になる。インストール作業でも権限エラーに阻まれる。こうした壁にぶつかるたびに、誰かが「su -でrootになればいい」と教えてくれます。この教えは、ある意味では正しいのです。rootはLinux上のあらゆるファイル・プロセス・デバイスを制御できる特権ユーザーです。rootになれば権限エラーは出なくなります。設定ファイルも書き換えられます。サービスの起動・停止も思い通りです。問題が瞬時に解決するため、「rootで入ってしまえばいい」という習慣が根付きやすいのです。
私が2001年に配属された現場も、まさにこの文化でした。チームの先輩エンジニア全員が
su -でrootになってから作業を始めていました。「一般ユーザーでログインして、必要なときだけsudoを使う」という運用をしている人は、当時の私の周囲には一人もいませんでした。root常時作業は「プロっぽい」ことに見えたほどです。しかし、この習慣には大きなリスクが潜んでいます。rootには「確認せずに何でも実行する」という特性があるからです。一般ユーザーなら「Permission denied」で止まる誤操作も、rootには止める仕組みがありません。
SE時代、私はすべての作業をrootで行っていた
1. rootで入り続けた2年間
2001年にSEとして最初に担当したLinuxサーバーは、社内向けのファイルサーバーでした。Samba経由でWindowsクライアントにファイル共有を提供する、当時は珍しくないシステムです。毎朝の作業ルーティンはこうでした。SSHでサーバーにログインする。
su -と打ち込む。rootのパスワードを入力する。プロンプトが$から#に変わる。「これで準備完了」という感覚です。rootで入っておけば、ファイルのコピーも削除も、設定変更もパッケージインストールも、一切の制限なしにできます。当時の私には、これが「効率的な作業」に見えていました。権限エラーが出ないので、作業がサクサク進むのです。
この習慣は2年以上続きました。その間、小さなヒヤリハットは何度もありました。
rmコマンドの対象を少し間違えたり、mvコマンドで上書きしてしまったり。でもその都度「ミスに気づいてよかった」で終わっていました。本番への直撃事故は起きていなかったのです。2. 本番サーバーのファイルを誤削除した夜
それが変わったのは2003年の秋でした。本番WebサーバーのDocumentRoot配下を整理する作業を任されました。古いバックアップディレクトリを削除しようと、rootシェルでこんなコマンドを打ちました。
# rootで実行したコマンド（誤操作の例） # rm -rf /var/www/html/backup_old/ # ↑ カレントディレクトリが想定と異なっていたため、 # 実際には別のパスが展開されてしまった
一般ユーザーで作業していたなら、権限がないため「Permission denied」が出て止まるはずでした。しかし、rootには止める仕組みがないのです。
そこから先は修羅場でした。直近のバックアップは3日前。差分のコンテンツは手元のどこかに残っているはずだが、それを探し出して復元するのに深夜まで5時間かかりました。先輩に報告するときの緊張と恥ずかしさは今でも覚えています。
この経験が、私がrootでの常時作業をやめる直接のきっかけになりました。
sudoとは何か — suとの根本的な違いを理解する
1. suとsudoの仕組みの違い
suコマンドは「Switch User（ユーザーを切り替える）」の略です。su -でrootに切り替えた瞬間から、セッションを終了するまで、打ち込むすべてのコマンドがroot権限で実行されます。一方、
sudoは「Superuser Do（スーパーユーザーとして実行する）」の略です。sudo コマンド名の形式で使い、指定した1コマンドだけをroot権限で実行します。コマンドが終わった瞬間、権限は元の一般ユーザーに戻ります。・suの動作: rootに「変身する」。以後のすべての操作がroot権限
・sudoの動作: 指定した1コマンドだけroot権限で実行する。終わると権限が戻る
・suのリスク: 誤操作が本番環境への直撃事故になりやすい
・sudoの安全性: 実行コマンドが監査ログに記録され、影響範囲が1コマンドに限定される
sudoはUNIX・Linuxの世界で長年にわたって磨かれてきたツールです。その設計の根底にある考え方が「最小権限の原則（Principle of Least Privilege）」です。人間はミスをする。だから、ミスの影響範囲を最小にする仕組みが必要だ——この発想がsudoを生みました。
2. sudoの基本コマンドと使い方
実際のsudoの使い方を見てみましょう。RHEL 9.4 / AlmaLinux 9.4 / Ubuntu 24.04 LTSで動作確認済みです。# sudoの基本構文 # sudo [オプション] コマンド # 例: /etc/hostsファイルをviで編集する $ sudo vi /etc/hosts # 例: httpdサービスを再起動する（RHEL系） $ sudo systemctl restart httpd # 例: パッケージをインストールする（RHEL系） $ sudo dnf install httpd # 例: パッケージをインストールする（Debian/Ubuntu系） $ sudo apt install apache2 # 自分が実行できるsudoコマンドの一覧を確認 $ sudo -l # 出力例: # User yamada may run the following commands on server01: # (ALL : ALL) ALL
sudo -lは実際の現場でよく使うコマンドです。「自分にどのsudo権限が与えられているか」を確認できます。新しいサーバーに入った際やトラブル調査の際に確認する習慣をつけておくと便利です。また、sudoはコマンドの実行記録を自動的にシステムログに残します。RHEL系では
/var/log/secure、Ubuntu/Debian系では/var/log/auth.logに「誰が、いつ、どのコマンドをsudoで実行したか」が記録されます。これは不正操作の追跡にも、インシデント調査にも活用できる大切なログです。sudoersの設定でユーザーごとの権限をきめ細かくコントロールする
sudoの強力な機能のひとつが、ユーザーごと・コマンドごとに実行権限を設定できるsudoersファイルです。適切に設定することで「特定の担当者には特定のコマンドだけsudoを許可する」という運用が実現できます。1. visudoでsudoers設定を安全に編集する
/etc/sudoersファイルを直接viで編集するのは禁止です。シンタックスエラーがあった場合、sudoが一切使えなくなります。必ずvisudoコマンドを使ってください。visudoはファイルを保存する前にシンタックスチェックを行い、エラーがあれば警告を出して保存を止めてくれます。# sudoersファイルの編集には必ずvisudoを使う $ sudo visudo # sudoersの基本書式: # ユーザー名 ホスト名=(実行ユーザー) コマンド # 例1: yamadaはどのホストでも全コマンドをsudo可能 yamada ALL=(ALL) ALL # 例2: tanakaはhttpdの再起動だけsudo可能 tanaka ALL=(root) /usr/bin/systemctl restart httpd # 例3: deployユーザーはパスワードなしでhttpdを再起動可能（自動化向け） deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd # RHEL系でwheelグループのユーザーにsudoを許可する行（デフォルトで記載あり） %wheel ALL=(ALL) ALL
2. wheelグループを使ったシンプルなsudo管理
RHEL系（AlmaLinux / Rocky Linux）では、wheelグループに所属するユーザーが自動的にsudoを使えるようになっています。新しい管理者ユーザーを追加するときは、usermodコマンドでwheelグループに追加するのが最も簡単な方法です。# yamadaをwheelグループに追加してsudoを使えるようにする $ sudo usermod -aG wheel yamada # グループへの追加を確認する $ id yamada # uid=1001(yamada) gid=1001(yamada) groups=1001(yamada),10(wheel) # 変更はログインし直さないと反映されない（確認方法） $ su - yamada $ sudo whoami # root ← 正常にsudoが使えている証拠
suとsudoで「トラブル」が起きやすいパターンとエラー対処法
「sudo: command not found」が出る場合
sudoコマンド自体がインストールされていないか、実行ファイルへのPATHが通っていない場合に発生します。最小インストール構成のサーバーではsudoがデフォルトで入っていないことがあります。# sudoが入っているか確認する $ which sudo # /usr/bin/sudo ← このように表示されていればOK # RHEL/AlmaLinux系でsudoをインストールする（rootで実行） # dnf install sudo # Ubuntu/Debian系でsudoをインストールする（rootで実行） # apt install sudo
「is not in the sudoers file. This incident will be reported.」が出る場合
このメッセージは、実行しようとしたユーザーがsudoersに登録されていないことを示します。同時に、このイベントが/var/log/secureにセキュリティインシデントとして記録されます。対処法は2つです。
・rootまたはすでにsudo権限を持つ管理者が
visudoで該当ユーザーを追加する・RHEL系では
usermod -aG wheel ユーザー名でwheelグループに追加する「sudo: sorry, you must have a tty to run sudo」が出る場合
cronジョブやシェルスクリプト内でsudoを使おうとしたときに出るエラーです。デフォルトのsudoers設定にDefaults requirettyが有効になっていると、インタラクティブな端末（tty）がない環境でsudoが実行できません。対処法は、
visudoでDefaults requiretty行をコメントアウトするか、自動化専用ユーザーにNOPASSWD:オプションを設定する方法があります。ただし、requirettyをコメントアウトするのはセキュリティポリシーの緩和になるため、本番環境では慎重に判断してください。「sudo: コマンド名: command not found」が出る場合
sudoで実行するコマンドのフルパスが見つからない場合に発生します。一般ユーザーと root ではPATHが異なるため、一般ユーザーの環境では使えるコマンドがsudo越しに使えないことがあります。# コマンドのフルパスを調べる $ which systemctl # /usr/bin/systemctl # フルパスを指定してsudoを実行する $ sudo /usr/bin/systemctl restart httpd # または sudo -i でrootのシェル環境ごと使う（PATHが引き継がれる） $ sudo -i systemctl restart httpd
sudo service ...やsudo systemctl ...が動かないと相談されるケースです。多くの場合、コマンドのPATH問題かsudoers設定の問題で解決できます。最小権限の原則を現場のオペレーションに組み込む3つの習慣
20年以上Linuxサーバーを運用してきた経験から言うと、「最小権限の原則」は頭で理解するのは簡単ですが、実際に現場に組み込むには意識の切り替えが必要です。私が実践してきて効果的だった3つの習慣をお伝えします。習慣1: SSH接続でのrootダイレクトログインを禁止する
/etc/ssh/sshd_configにPermitRootLogin noを設定し、rootでのSSH直接ログインを禁止します。これにより「一般ユーザーでログイン→必要な操作はsudo」という流れが強制されます。「rootで直接入れないと不便では？」とよく聞かれますが、実際は不便を感じることはほとんどありません。
sudoを使えば、一般ユーザーのまま必要な操作ができます。むしろ、rootでのダイレクトログインを禁止することで、不正ログインされた場合のリスクを大幅に下げられます。習慣2: sudoの実行ログを定期的に確認する
sudoは実行コマンドを自動的にシステムログに残します。このログを週1回でも確認する習慣をつけると、不審な操作の早期発見につながります。# RHEL系でsudoの実行ログを確認する $ sudo grep sudo /var/log/secure | tail -20 # 出力例: # Sep 14 09:15:23 server01 sudo: yamada : TTY=pts/0 ; PWD=/home/yamada ; USER=root ; COMMAND=/usr/bin/systemctl restart httpd # Sep 14 09:30:11 server01 sudo: tanaka : TTY=pts/1 ; PWD=/home/tanaka ; USER=root ; COMMAND=/usr/bin/vi /etc/hosts # Ubuntu/Debian系の場合 $ sudo grep sudo /var/log/auth.log | tail -20
習慣3: rootシェルへの切り替えを「最後の手段」にする
su -やsudo -iでrootシェルに入ることを、本当に必要なとき（複数のrootコマンドを連続実行しなければならない特殊な作業など）だけに限定します。普段の作業はsudo コマンド名の形式で、1コマンドずつ実行するようにします。私がセミナーでお伝えしているのは「rootシェルに入ったら5分以内に作業を終えて抜け出す」という意識です。rootシェルで長時間作業しているということは、それだけ誤操作のリスクが高い状態が続いているということです。
受講生からよく聞かれる「でも、複数の設定ファイルを連続で変更するときはrootで入った方が効率的では？」という質問に対しては「その場合は
sudo -iでrootシェルに入り、作業が終わったらすぐexitで抜けてください」とお伝えしています。どちらにせよ、「入ったままにしておく」という習慣をやめることが最重要です。まとめ
suとsudoの違い、sudoersの設定方法、そして最小権限の原則を現場に取り込む習慣をまとめます。| 確認したいこと | コマンドまたは対処法 |
|---|---|
| 自分が使えるsudo権限を確認する | sudo -l |
| 一般ユーザーでroot権限コマンドを実行する | sudo systemctl restart httpd（例） |
| ユーザーをwheelグループに追加してsudo許可 | sudo usermod -aG wheel ユーザー名 |
| sudoers設定を安全に編集する | sudo visudo |
| 特定コマンドだけsudoを許可する（sudoers） | ユーザー名 ALL=(root) /usr/bin/コマンドのフルパス |
| sudoコマンドの実行履歴を確認する | sudo grep sudo /var/log/secure（RHEL系） |
| SSHでのrootダイレクトログインを禁止する | /etc/ssh/sshd_config に PermitRootLogin no を設定 |
| sudo が使えない（sudoersに未登録） | 管理者にwheelグループ追加またはsudoers設定を依頼 |
sudoの設計思想「最小権限の原則」を理解し、日常の作業に組み込むことが、安全なLinuxサーバー運用の第一歩です。rootシェルは「最後の手段」として、sudoを使った最小権限での作業を習慣にしてください。
root権限の正しい使い方を「型」として身につけたい方へ
suとsudoの違い、sudoersの設定、最小権限の原則——これらはコマンドを覚えるだけでは身につきません。「なぜそうするのか」の設計思想から理解することが現場での実践につながります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxでtcpdumpを初めて使ってネットワーク問題を解決した話｜パケットを「見る」という発想が変えた障害調査の視野
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます