【サーバー管理入門 第2回】「root」は封印せよ。SSH鍵認証とユーザー管理の鉄則
こんにちは！「リナックス先生」です。
前回はVirtualBoxを使ってAlmaLinux 9のサーバーを構築しましたね。
コウ君、あのあとサーバーはどうやって操作していた？
VirtualBoxの黒い画面（コンソール）で直接入力していました！
でも、画面が小さいし、コピペができないからコマンドの手打ちが大変で……。
長いコマンドを間違えて何度も打ち直していました。
それは苦行ね（笑）。
実際の現場では、サーバーールームに入って直接キーボードを叩くことは滅多にないわ。
自分のPCから「SSH」を使って遠隔操作するのが基本よ。
今回は、安全に遠隔操作するための環境作りと、最初のセキュリティ対策を行うわよ！
第2回となる今回は、サーバー管理の第一歩である「SSH接続」と「ユーザー管理」、そしてプロなら絶対にやっておくべき「セキュリティ設定（鍵認証化）」について解説します。
ここで設定をミスすると、サーバーが乗っ取られる危険性もある重要な回です。
本講座のカリキュラム
- サーバー管理入門：RHEL系OSの選定理由とローカル仮想環境の構築
- 【今回】初期設定とセキュリティの要：SSH鍵認証、禁止設定、ユーザー管理の鉄則
- パッケージ管理の裏側：dnf/rpmの仕組みとリポジトリの依存関係解決
- ネットワーク設定の極意：nmcli、IPアドレス設計、DNSリゾルバの設定
- ストレージ管理とファイルシステム：LVMの概念、ディスク拡張、fstabの罠
- プロセスとサービス管理：systemd (systemctl) の仕組みとUnit定義ファイルの作成
- Webサーバー構築(Nginx)：ハイパフォーマンスWebサーバーの導入と設定最適化
- データベース構築(MariaDB)：インストール、初期セキュリティ、バックアップの基礎
- ログ管理とトラブルシュート：rsyslog、journalctl、ログローテートの設計
- 自動化の第一歩：Cronによる定期実行と管理用シェルスクリプトの作成
- バックアップと障害復旧：tar/rsyncによるデータ保全とリカバリ手順
- 監視と運用設計：サーバーのリソース監視、死活監視、そしてプロの運用論
1. なぜ「root」で作業してはいけないのか？
前回、インストール直後のサーバーに root ユーザーでログインしました。
しかし、実務において root で直接ログインして作業すること は、以下の理由からタブーとされています。
プロがrootを使わない3つの理由
- 事故のリスク： rootは何でもできる「神の権限」です。
rm -rf /などの危険なコマンドも警告なしで実行され、システムを一瞬で破壊します。 - セキュリティリスク： 攻撃者は「root」というIDが存在することを知っています。パスワードさえ突破できれば、即座に全権限を奪われます。
- 監査ログの不在： 複数人の管理者が全員 root を使うと、「誰が」「いつ」設定を変更したのか、ログから追跡できなくなります。
そのため、まずは「普段使いの一般ユーザー」を作成し、管理者権限が必要な時だけ sudo (SuperUser DO) コマンドを使って一時的に権限を借りる運用が鉄則です。
2. 一般ユーザーの作成とsudo権限の付与
それでは、VirtualBoxのコンソール画面（まだSSHは使いません）から操作して、管理者用の一般ユーザーを作成しましょう。
ここではユーザー名を admin_user としますが、お好きな名前で構いません。
Step 1: ユーザーの作成
以下のコマンドを実行します。
[root@server01 ~]# useradd admin_user [root@server01 ~]# passwd admin_user Changing password for user admin_user. New password: (パスワードを入力) Retype new password: (もう一度入力)
Step 2: 管理者権限 (sudo) の付与
作成したユーザーに管理者権限を与えます。
RHEL系（AlmaLinux）では、wheel という特殊なグループに所属させることで、sudoコマンドが使えるようになります。
[root@server01 ~]# usermod -aG wheel admin_user
💡 コマンドの解説
useradd：ユーザーを作るコマンド。usermod -aG wheel：-a(append) と-G(Groups) オプションで、既存のグループ所属を維持したまま、新たにwheelグループに追加します。wheelグループ：UNIX系OSにおける「管理者予備軍」のグループ名。名前の由来は「Big Wheel（大物）」から来ていると言われています。
Step 3: 切り替え確認
作成したユーザーに切り替えて、sudoが使えるかテストします。
[root@server01 ~]# su - admin_user [admin_user@server01 ~]$ sudo ls /root
パスワードを求められるので、admin_user のパスワードを入力してください。
本来は見られないはずの /root ディレクトリの中身が見えれば成功です。
3. SSHクライアントの準備と接続
ユーザーができたら、いよいよパソコン（ホストOS）からSSHで接続します。
SSHクライアントソフトには様々な種類がありますが、現在はOS標準のターミナルを使うのが主流です。
- Windows： PowerShell, Windows Terminal, Tera Term
- Mac： ターミナル (Terminal.app), iTerm2
ここでは、最も汎用的なコマンドライン（PowerShell / ターミナル）での接続方法を紹介します。
接続コマンド
PC側のターミナルを開き、以下のコマンドを入力します。
（IPアドレスは、前回 ip addr で確認したアドレス、例えば 192.168.1.15 などに置き換えてください）
ssh admin_user@192.168.1.15
初回接続時は、「このサーバーを信頼しますか？」という警告（Fingerprint確認）が出ます。
The authenticity of host '192.168.1.15' can't be established. ED25519 key fingerprint is SHA256:xxxxxxxxx. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
yes と入力し、パスワードを入力してログインできれば成功です！
これでコピペも自由自在ですね。
4. パスワード認証は捨てる。「公開鍵認証」への移行
SSHで接続できましたが、今のままでは「パスワード認証」です。
パスワードは総当たり攻撃（ブルートフォースアタック）に弱く、短く簡単なパスワードだと数分で突破されてしまいます。
そこで、プロの現場で必ず行われるのが「公開鍵認証（Public Key Authentication）」です。
公開鍵認証の仕組み
「鍵ペア」と呼ばれる2つのファイルを使います。
- 秘密鍵 (Private Key)： あなたのPCの中に隠し持つ鍵。「絶対に誰にも渡してはいけない」。
- 公開鍵 (Public Key)： サーバー側に設置する錠前。「誰に見られても良い」。
サーバー（公開鍵）に対して、持っている秘密鍵が対になるものかを数学的に証明してログインします。
パスワードがネットワーク上を流れないため非常に安全です。
Step 1: 鍵ペアの作成（PC側で操作）
一度ログアウトして、PC側（Windows/Mac）のターミナルで操作します。
# 鍵ペアを作成する（-t ed25519 は現在推奨される最強の暗号化方式） ssh-keygen -t ed25519 -C "my_server_key"
保存場所を聞かれますが、基本はEnter連打でOKです。
これにより、以下の2ファイルが生成されます。
id_ed25519（秘密鍵：人に見せてはいけない！）id_ed25519.pub（公開鍵：これをサーバーに送る）
Step 2: 公開鍵をサーバーへ転送
作成した「公開鍵の中身」をサーバーに登録します。
簡単なコマンドが用意されています。
# Windows (PowerShell) の場合 type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh admin_user@192.168.1.15 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" # Mac / Linux の場合 ssh-copy-id -i ~/.ssh/id_ed25519.pub admin_user@192.168.1.15
これで、サーバー側の ~/.ssh/authorized_keys というファイルに、あなたの公開鍵が書き込まれました。
Step 3: 鍵認証でのログイン確認
再度SSH接続を試みてみましょう。
ssh admin_user@192.168.1.15
パスワードを聞かれずにスッとログインできれば設定完了です！
5. サーバーの「鍵」を閉める：SSH設定の堅牢化
鍵認証ができるようになったので、セキュリティホールとなる古い扉（パスワード認証とrootログイン）を完全に塞ぎます。
サーバー内の設定ファイル /etc/ssh/sshd_config を編集します。
ここからは慎重に作業してください。設定を間違えると二度とSSHできなくなります（その場合はVirtualBoxのコンソールから直せばOKです）。
設定ファイルの編集
[admin_user@server01 ~]$ sudo vi /etc/ssh/sshd_config
Vimで以下の箇所を探し、書き換えてください。
（/PermitRoot のように入力して検索すると早いです）
| 設定項目 | 変更前 | 変更後 | 意味 |
|---|---|---|---|
| PermitRootLogin | yes | no | rootでの直接ログインを禁止する。 ※一般ユーザーで入ってからsudoするのはOK。 |
| PasswordAuthentication | yes | no | パスワード認証を無効化する。 ※鍵を持っていない人は門前払いにする。 |
編集が終わったら :wq で保存します。
設定の反映と接続テスト
設定を反映させる前に、構文エラーがないかチェックします。
[admin_user@server01 ~]$ sudo sshd -t
何も表示されなければOKです。設定を再読み込みします。
[admin_user@server01 ~]$ sudo systemctl reload sshd
先生！ reload した後、今のSSH接続が切れませんか？
締め出されたらどうしよう……。
いい質問ね！systemctl reload は、確立済みの接続は切断せずに、新しい接続から設定を適用するの。
だから、「今の画面は閉じずに」、別のターミナルウィンドウを開いてログインできるかテストするのがプロの定石よ。
最終確認
別のターミナルを開き、以下のテストを行います。
ssh admin_user@192.168.x.x→ ログインできること（成功）ssh root@192.168.x.x→ Permission denied となりログインできないこと（成功）
これで、世界中の誰がパスワードを知っていようとも、あなたの秘密鍵を持っていない限り誰も侵入できない強固なサーバーになりました。
次回予告：インストール作業を快適に
今回は、サーバー管理の基本中の基本、ユーザー管理とSSHの堅牢化を行いました。
これで安心して作業に没頭できる環境が整いました。
次回は、サーバー構築の主役とも言える「パッケージ管理システム (dnf/rpm)」について解説します。
「アプリをインストールする」という単純な動作の裏で、Linuxがどのように依存関係を解決し、ソフトウェアを管理しているのか。
この仕組みを知ると、エラーが出た時の対応力が格段に上がります。お楽しみに！
▼スクリプトの実験場に最適！推奨VPS
コメント