パッケージとユーザー・SSH｜クラウドインフラ

← クラウドインフラ一覧

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：シェルとファイル操作・権限　|　関連：プロセスとサービス管理（systemd）・CI/CDとは・パイプライン

要点（BLUF）

**パッケージ管理（apt/dnf 等）**は、ソフトと依存関係をまとめて導入・更新・削除する仕組み。手動ダウンロードより安全で再現性が高い。
ユーザーと sudo で権限を分ける。普段は一般ユーザー、管理操作だけ sudo で昇格。root 常用はしない。
SSH 公開鍵認証でサーバにログインする。パスワードより安全で、鍵ペアの秘密鍵は手元、公開鍵をサーバに置く。パスワードログインは無効化が定石。

概念 ── 3つの「導入・権限・接続」

サーバ運用の入口は、(1) ソフトをどう入れるか、(2) 誰が何をできるか、(3) どう安全に入るか、の3点です。

仕組み① ── パッケージ管理

OS ごとに標準のパッケージマネージャがあります（Debian/Ubuntu 系は apt、RHEL/Fedora 系は dnf）。依存関係を自動解決し、署名で改ざんを検出し、一括更新できるのが手動導入との差です。

# Debian/Ubuntu 系の例
sudo apt update                 # パッケージ一覧（カタログ）を最新化
sudo apt install -y nginx       # 依存ごと導入
sudo apt upgrade -y             # 入っているものをまとめて更新（脆弱性対応の基本）
apt list --installed | grep nginx

セキュリティ更新を当て続けることが、サーバを守る最も費用対効果の高い運用です。コンテナ時代は「サーバに ssh して apt」より「イメージを焼き直す」（Dockerイメージとレイヤ）に寄りますが、土台の考え方は同じ。

仕組み② ── ユーザーと sudo

Linux はマルチユーザー前提。root（全権）を日常使いすると、誤操作1つでシステムを壊します。だから一般ユーザーで作業し、管理操作だけ sudo で一時的に昇格します。

# 作業用ユーザーを作り、sudo できるグループに入れる
sudo adduser deploy
sudo usermod -aG sudo deploy     # （RHEL系は wheel グループ）
# 以後 deploy で作業し、管理操作だけ
sudo systemctl restart nginx

sudo には「誰が・何を実行したか」が記録される利点もあります（監査）。root 直ログインは記録も追えず危険。

仕組み③ ── SSH 公開鍵認証

リモートのサーバには SSH で入ります。認証はパスワードより公開鍵が安全。鍵ペアを作り、秘密鍵は自分の手元（外に出さない）、公開鍵をサーバに登録します。

sequenceDiagram
    participant C as 手元PC（秘密鍵）
    participant S as サーバ（公開鍵を登録済み）
    C->>S: 接続要求
    S->>C: 乱数チャレンジを送る
    Note over C: 秘密鍵で署名
    C->>S: 署名を返す
    Note over S: 登録済み公開鍵で検証
    S->>C: 一致すればログイン許可

秘密鍵は外に出ず、毎回違う乱数に署名するので、通信を盗み見られても再利用できません。

# 1) 鍵ペアを作る（ed25519 が現代的）
ssh-keygen -t ed25519 -C "deploy@example"
# 2) 公開鍵をサーバへ登録（~/.ssh/authorized_keys に追記される）
ssh-copy-id deploy@server.example.com
# 3) 以後は鍵でログイン
ssh deploy@server.example.com

サーバ側 /etc/ssh/sshd_config の定石（要最新確認）：

PasswordAuthentication no       # パスワードログインを禁止（総当たり対策）
PermitRootLogin no              # root 直ログインを禁止
PubkeyAuthentication yes        # 公開鍵のみ許可

なぜこうするのか

再現性のため（パッケージ）：「何が・どのバージョン入っているか」が管理下にある。手動導入は更新漏れと依存地獄を生む。
被害の局所化のため（ユーザー/sudo）：日常を非rootにすれば、誤操作も侵入も影響が限定される。sudo の記録が追跡を可能にする。
盗聴・総当たりに強いため（公開鍵）：秘密鍵が漏れない限り破られにくい。パスワードは総当たり・使い回しに弱い。深掘り（鍵管理・証明書・多要素）はサイバーセキュリティへ。

⚠️ よくある誤解・落とし穴

「秘密鍵をサーバや共有ストレージに置く」→ 厳禁。秘密鍵は手元だけ、権限 600（シェルとファイル操作・権限）。漏れたら即ローテーション。
「root で全部やる方が早い」→ 早いが危険。誤操作の代償が大きく、監査も効かない。
「パスワードログインのまま公開」→ 公開IPのサーバは即座に総当たりされる。鍵認証＋パスワード無効が定石。
「apt upgrade は怖いから当てない」→ 当てない方が危険。脆弱性放置が侵入経路に。検証環境で確認しつつ計画的に。
「鍵を1つ作って全サーバ・全用途で使い回す」→ 漏洩時の被害が全体に波及。用途ごとに分け、CI 用はデプロイ鍵を分離（CI/CDとは・パイプライン）。

対応ラボ

cloud-infra-study/labs/02-03_sshd_config_hardening.md（公開鍵認証への切替と sshd 設定の最小ハードニング手順。鍵生成〜パスワード無効化まで観察）。