【最新Ubuntu 26.04 LTS】サーバー構築入門 第2回：SSH鍵認証（量子耐性対応）とsudo権限の厳格化

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Ubuntu 26.04 LTS サーバー構築入門」の第2回へようこそ。前回はOSのインストールを無事に終え、まっさらなサーバーが立ち上がりました。

しかし、インストール直後のサーバーは、例えるなら「鍵穴がむき出しで、誰でもパスワードを推測できる状態の家」です。インターネット上にサーバーを公開した瞬間から、世界中のハッカーが自動化されたボット（攻撃プログラム）を使って、1秒間に何百回もパスワードを入力する「ブルートフォース攻撃（総当たり攻撃）」を仕掛けてきます。

本記事では、不正アクセスを根絶するための「SSH公開鍵認証」の導入と、Ubuntu 26.04で劇的に進化した「量子耐性暗号」および「Rust化されたsudo」の最先端セキュリティ設定について、世界一詳しく解説していきます。

---

1. パスワード認証の限界と「公開鍵認証」の仕組み

サーバーを遠隔操作するためのプロトコルをSSH（Secure Shell）と呼びます。デフォルトでは、SSHはユーザー名とパスワードの組み合わせでログインを許可します。

1-1. パスワード認証が危険な理由

パスワードは「人間の頭の中にある知識」に依存した認証（知識認証）です。悪意のある攻撃者は、総当たり攻撃（ブルートフォース攻撃）や、よく使われるパスワードのリストを用いた辞書攻撃を24時間365日仕掛けてきます。
一度でもパスワードが破られれば、攻撃者はサーバーの完全な制御権を握り、あなたのサーバーを「スパムメールの送信元」や「仮想通貨のマイニング（発掘）マシーン」へと変貌させてしまいます。

1-2. 公開鍵認証（Public Key Authentication）の概念

この問題を解決するのが公開鍵認証方式です。これは、パスワードという「知識」ではなく、デジタルな「鍵ファイル（所有物）」を用いた認証方式です。

鍵は以下の2つのファイルがペア（対）になって生成されます。

1. 公開鍵（Public Key）： 南京錠（ロック）に相当します。他人にどれだけ見られても安全なデータです。この南京錠を、あらかじめサーバーのドアに取り付けておきます。
2. 秘密鍵（Private Key）： その南京錠を開けることができる世界に一つだけの「本物の鍵」です。これは自分の手元のパソコン（クライアントPC）の奥深くに厳重に保管し、絶対にインターネット上にアップロードしてはいけません。

SSH接続をする際、サーバーは「この南京錠を開けられるか？」という暗号化されたテスト問題を送ってきます。手元のパソコンが秘密鍵を使ってその問題を解き、正しい答えを返すことができた場合のみ、ログインが許可されます。
この仕組みにより、秘密鍵のファイルファイル自体を物理的に盗まれない限り、数学的に絶対に破られない鉄壁の防御が完成します。

---

2. Ubuntu 26.04の目玉：量子耐性暗号（Post-Quantum Cryptography）とは？

さて、ここからがUbuntu 26.04 LTSの真骨頂です。現代の公開鍵暗号（RSAや楕円曲線暗号）は、「巨大な数の素因数分解」や「離散対数問題」といった、現在のスーパーコンピューターでも解くのに数万年かかる数学的難問を安全性の根拠としています。

2-1. 「Store Now, Decrypt Later」の脅威

しかし、圧倒的な計算能力を持つ「量子コンピューター」が実用化されると、これらの暗号はわずか数分で破られてしまう（Shorのアルゴリズム）と予測されています。
「量子コンピューターの完成はまだ先だから大丈夫では？」と思うかもしれません。しかし、国家レベルのハッカー組織は現在、暗号化された通信データを「今は解読できなくても、とりあえず保存だけしておき、将来量子コンピューターが完成した瞬間にまとめて解読する（Store Now, Decrypt Later）」という恐ろしい攻撃をすでに行っています。

2-2. OpenSSHのデフォルトアルゴリズムの進化

この脅威に対抗するため、Ubuntu 26.04 LTSに搭載されている最新の OpenSSH では、量子コンピューターでも解読が困難とされる「量子耐性暗号（Post-Quantum Cryptography: PQC）」のアルゴリズムがデフォルトで有効化されました。
具体的には、従来の楕円曲線暗号（X25519）と、NIST（米国国立標準技術研究所）が選定した格子暗号技術（ML-KEM/Kyber）を組み合わせた mlkem768x25519-sha256 というハイブリッド鍵交換方式が採用されています。

つまり、Ubuntu 26.04を使うだけで、あなたのサーバー通信は「未来の量子コンピューターの脅威」からも自動的に保護されるのです。

---

3. 実践：クライアント側（Windows/Mac）でのSSH鍵ペア作成

それでは、実際に手元のパソコン（クライアントPC）で鍵ペアを作成しましょう。
※この作業は「サーバー上」ではなく「手元のパソコン上」で行うことに注意してください。

3-1. ターミナル（PowerShell / ターミナル.app）の起動

Windowsの場合は「PowerShell」を、MacやLinuxの場合は「ターミナル」を起動します。

3-2. 鍵ペアの生成コマンド

現在、最も安全で処理が高速な署名アルゴリズムである Ed25519 を指定して鍵を作成します。古い RSA 鍵は設定ミスで脆弱になる可能性があるため、特別な理由がない限り Ed25519 を使用します。

# 鍵ペアを生成するコマンド
ssh-keygen -t ed25519 -C "admin@ubuntu26-server"

コマンドを実行すると、いくつか質問されます。

3-3. 生成された2つのファイルを確認

生成が完了すると、.ssh ディレクトリ内に以下の2つのファイルが作成されます。

• id_ed25519（秘密鍵）: 絶対に他人に渡してはいけないファイル。
• id_ed25519.pub（公開鍵）: サーバー側に登録するためのファイル。

---

4. 公開鍵のサーバーへの転送と authorized_keys の設定

次に、作成した「公開鍵（南京錠）」を、Ubuntu 26.04サーバーに転送して取り付けます。この作業までは、一時的にパスワード認証を使います。

4-1. Mac/Linuxの場合（ssh-copy-idコマンド）

非常に便利なコマンドが用意されています。以下のコマンドを実行すると、公開鍵が自動的にサーバーへ転送・登録されます。（192.168.1.100 の部分はサーバーのIPアドレスに、kou は作成したユーザー名に変更してください）

ssh-copy-id -i ~/.ssh/id_ed25519.pub kou@192.168.1.100

サーバーのパスワードを聞かれるので入力します。Number of key(s) added: 1 と表示されれば成功です。

4-2. Windows (PowerShell) の場合（手動設定）

Windows標準のPowerShellには ssh-copy-id コマンドがないため、SSHでサーバーにログインし、手動で設定ファイルを作成します。

手順1：公開鍵の中身をコピーする
PowerShellで以下のコマンドを打ち、表示された文字列（ssh-ed25519 AAA...）をすべてコピーします。

cat ~/.ssh/id_ed25519.pub

手順2：サーバーにパスワードでログインする

ssh kou@192.168.1.100

手順3：サーバー上に設定ファイルを作成し、権限を厳格化する
サーバーにログインした状態で、公開鍵を登録する authorized_keys ファイルを作成します。※ここのディレクトリとファイルのパーミッション（権限）設定を間違えると、SSHサーバーが鍵を読み込んでくれません。非常に重要です。

# .sshディレクトリを作成
mkdir -p ~/.ssh

# ディレクトリの権限を「自分以外アクセス禁止(700)」にする
chmod 700 ~/.ssh

# authorized_keysファイルを作成し、先ほどコピーした公開鍵を貼り付けて保存する
nano ~/.ssh/authorized_keys

# ファイルの権限を「自分だけが読み書き可能(600)」にする
chmod 600 ~/.ssh/authorized_keys

4-3. 鍵認証でのログインテスト

一度 exit コマンドでサーバーからログアウトし、再度ログインを試みます。

ssh kou@192.168.1.100

サーバーのパスワードではなく、「秘密鍵のパスフレーズ」を聞かれるようになれば、鍵認証は無事に成功しています！

---

5. OpenSSH サーバーの堅牢化（パスワード認証の無効化）

鍵を使ってログインできるようになったので、いよいよ「パスワードでのログイン機能」を完全に破壊（無効化）します。これにより、ブルートフォース攻撃は物理的に不可能になります。

Ubuntu 26.04では、SSHの設定は /etc/ssh/sshd_config というメインファイルと、/etc/ssh/sshd_config.d/ 以下のドロップインファイルで管理されています。今回はメインファイルを編集します。

5-1. sshd_config の編集

サーバー上で設定ファイルをエディタ（nano）で開きます。

sudo nano /etc/ssh/sshd_config

ファイルの中から以下の項目を探し、（行頭の # を消して）値を変更します。

5-2. ポート番号の変更（任意）

SSHのデフォルトポートは「22番」です。ボットはこの22番ポートを狙い撃ちしてきます。設定ファイルの上部にある #Port 22 の # を外し、Port 22222 のように1024〜65535の使われていない番号に変更することで、ログに記録される攻撃のスパムを劇的に減らすことができます。
※ただし、「ポートを変えれば安全」というわけではない（ポートスキャンでバレる）ため、本質的な防御はあくまで鍵認証です。今回は22番のままで進めます。

5-3. SSHサーバーの再起動

設定を保存したら、SSHサービスを再起動して設定を反映させます。

# SSHサービスの構文チェック（何も出力されなければOK）
sudo sshd -t

# サービス再起動
sudo systemctl restart ssh

※重要※ 現在接続しているSSHターミナルは閉じずに、別のターミナルを新しく開いてログインできるかテストしてください。設定ミスがあった場合、ターミナルを閉じてしまうと二度とサーバーに入れなくなります。

---

6. Rust化で生まれ変わった sudo：管理者権限の厳格化

外部からの入り口（SSH）を鉄壁にしました。次はサーバー内部のルールである sudo（管理者権限の代行）の設定です。

6-1. そもそもsudoとは何か？

Linuxにおける絶対神「root」ユーザーは、サーバーの破壊すら可能な強大な権限を持ちます。そのため、普段は一般ユーザー（kouなど）で作業し、必要な時だけ「sudo（Super User DO）」という呪文をつけてコマンドを実行することで、一時的に神の力を借ります。

6-2. Ubuntu 26.04におけるsudoのRust化の衝撃

長年、sudo はC言語で書かれていました。しかしC言語は「メモリの管理をプログラマーが手動で行う」必要があり、バッファオーバーフローや「Use-after-free」といったメモリ関連の脆弱性が度々発見され、それがシステムの致命的なセキュリティホールになっていました。

Ubuntu 26.04 LTSでは、Canonical社（Ubuntuの開発元）の主導により、この sudo コマンドがRust（ラスト）言語で完全に書き直されたバージョンが統合されました。Rustは「コンパイル時にメモリ安全性を保証する」という強力な特性を持つため、メモリリークや不正なポインタ参照といった脆弱性が原理的に発生しません。これにより、特権昇格攻撃（一般ユーザーが不正にroot権限を奪う攻撃）のリスクが極限まで低減されています。

---

7. 実践：visudoを使った高度な権限コントロール

Ubuntuインストール時に作成した最初のユーザーは、デフォルトで「何でもできる（ALL権限）」状態になっています。個人開発ならこれでも良いですが、プロの現場では「Webサーバーの再起動だけは許可するが、ファイルの削除は許可しない」といった細かな権限設定を行います。

7-1. visudoコマンドによる安全な編集

sudoの設定は /etc/sudoers というファイルに記述されますが、これを普通のテキストエディタで直接編集してはいけません。文法エラーがあると、誰も sudo が使えなくなり、システムが詰んでしまいます。
必ず visudo という専用コマンドを使います。これは保存時に文法チェックを行ってくれる安全装置付きのエディタです。

sudo visudo

7-2. 権限設定の構文解剖

ファイルの中に以下のような記述があります。

%sudo   ALL=(ALL:ALL) ALL

これは「sudoグループに属するユーザー（%sudo）は、すべてのホストで（ALL=）、すべてのユーザーとグループの権限で（ALL:ALL）、すべてのコマンドを実行できる（ALL）」という意味です。

7-3. 実践：特定のコマンドだけをパスワードなしで許可する

例えば、kou というユーザーに、「Nginx（Webサーバー）の再起動だけは、パスワード入力なしで実行してよい」という権限を与えたい場合、ファイルの末尾に以下のように追記します。

kou ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

解説：

• kou: 対象のユーザー名。
• ALL=: どのサーバーからでも（通常はALLでOK）。
• (root): rootユーザーの権限として実行する。
• NOPASSWD:: 実行時にsudoパスワードの入力を求めない。自動化スクリプトを組む際に必須のテクニックです。
• /usr/bin/systemctl restart nginx: 許可するコマンド。必ず絶対パス（フルパス）で記述しなければなりません。コマンドのフルパスは which systemctl などで調べられます。

編集が終わったら、Ctrl+O で保存、Enter で確定、Ctrl+X で終了します。もし文法エラーがあれば、この時点で警告が表示されます。

---

8. ログ監査とトラブルシューティング：締め出された時の復旧手順

最後に、インフラエンジニアとして避けて通れない「トラブル対応」について触れておきます。

8-1. SSH接続エラー「Permission denied (publickey)」

設定を終えてログインしようとしたらこのエラーが出た場合、原因はほぼ以下の3つに絞られます。

1. サーバー側の権限ミス： ~/.ssh ディレクトリが 700 以外、または authorized_keys ファイルが 600 以外になっている。OpenSSHは権限が緩いファイルを発見すると、セキュリティリスクと見なして強制的に読み込みを拒否します。
2. 公開鍵のコピペミス： 文字が欠けていたり、不要な改行が入っている。
3. クライアント側で鍵を指定していない： 秘密鍵ファイルの名前をデフォルト（id_ed25519）から変えた場合、SSHコマンドが鍵を見つけられません。ssh -i ~/.ssh/my_custom_key kou@192.168.1.100 のように -i オプションで鍵を指定する必要があります。

8-2. 完全にサーバーから締め出されたら？

「PasswordAuthentication no」にした状態で鍵を紛失したり、設定を間違えたままSSHを再起動してターミナルを閉じてしまった場合、ネットワーク経由でのログインは不可能になります。
この場合、VPSやクラウドプロバイダの管理画面（コンソールパネル）から提供されている「シリアルコンソール（仮想的な直接接続画面）」機能を使うしかありません。ここから直接rootやユーザーでログインし、/etc/ssh/sshd_config を一時的に元に戻して復旧させます。物理サーバーなら、直接キーボードとモニターを繋いで操作します。

8-3. 認証ログ（Auth Log）の監視

サーバーへのログイン試行やsudoの実行履歴は、すべて /var/log/auth.log に記録されます。Ubuntu 26.04ではsystemdのjournal機能も強化されています。

# 認証関連のログをリアルタイムで監視する
sudo journalctl -u ssh -f

パスワード認証を無効化する前と後で、このログに記録される「攻撃の失敗ログ」の質がどう変わるか、ぜひ観察してみてください。パスワード無効化後は、攻撃者のボットが瞬時に接続を切断される様子がわかります。

---

総まとめ：鉄壁の要塞の完成

第2回の講座、本当にお疲れ様でした！情報量が多かったと思いますが、ここまでやり切ったあなたのサーバーは、すでに一般的な企業のサーバーと同等か、それ以上のセキュリティレベル（量子耐性＆Rust化）に達しています。

パスワードという脆弱な知識認証を捨て、暗号数学に基づいた「鍵認証」を取り入れたこと。
そして、管理者権限である sudo の仕組みを理解し、visudo によって必要最小限の権限（最小特権の原則）を設計できるようになったこと。

これらは、インフラエンジニアとして「サーバーを守る」ための基礎であり、最も重要なマインドセットです。

さて、入り口の扉は頑丈になりましたが、まだ「壁」がありません。不要なポート（窓）が開けっ放しになっています。
次回、第3回「UFWとFail2ban：強固なファイアウォールと不正アクセス対策」では、Ubuntu特有の直感的なファイアウォール「UFW」を使って不要な通信を完全に遮断し、さらに「Fail2ban」を使って悪意あるIPアドレスを自動的にブラックリストに登録する、AI顔負けの「自動防衛システム」を構築します。

サーバー構築の旅はまだまだ続きます。次回もお楽しみに！