Ubuntu 26.04 でサーバーを管理する場合、SSH は最初に整えるべき入口です。SSH は単にログインできればよいものではなく、管理ユーザー、公開鍵、sshd_config、信頼する接続元、ログ確認までを一つの管理経路として設計する必要があります。
この記事では、Ubuntu 26.04 で SSH 接続を安全に使うための基本設定を整理します。手元の構成では Ansible によって SSH 鍵、クライアント設定、authorized_keys、/etc/ssh/sshd_config.d/99-local.conf を分けて管理していますが、ここではそれを手動で確認・設定する場合の考え方としてまとめます。
SSH 設定で分けて考えるもの
SSH の設定は、ひとまとめにすると分かりにくくなります。最低限、クライアント側の接続設定、秘密鍵と公開鍵、サーバー側の authorized_keys、サーバー側の sshd_config を分けて考えます。
| 領域 | 主なファイル | 役割 |
|---|---|---|
| SSH クライアント設定 | ~/.ssh/config | 接続先、ユーザー名、鍵、ポートなどを定義する |
| 秘密鍵 / 公開鍵 | ~/.ssh/id_ed25519~/.ssh/id_ed25519.pub | 公開鍵認証に使う鍵を管理する |
| authorized_keys | ~/.ssh/authorized_keys | サーバーへログインを許可する公開鍵を登録する |
| sshd 設定 | /etc/ssh/sshd_config.d/99-local.conf | サーバー側の認証方式や転送可否を制御する |
重要なのは、SSH クライアントの便利設定と、SSH サーバーの認証制御を混同しないことです。~/.ssh/config は接続する側の設定であり、sshd_config は接続を受ける側の設定です。
現在の SSH サービスを確認する
まず、OpenSSH server がインストールされ、ssh.service が起動しているか確認します。Ubuntu 26.04 では、サービス名として ssh.service を確認します。
dpkg -l | grep -E '^ii\s+openssh-server' || true
systemctl status ssh --no-pager
ss -ltnp | grep ':22' || truess -ltnp では、SSH がどのアドレスで listen しているかを確認できます。外部公開するサーバーでは、listen していることだけでなく、Firewall や上位ネットワークでどこから到達できるのかも合わせて見る必要があります。
SSH 鍵と権限を確認する
公開鍵認証を使う場合、鍵ファイルと .ssh ディレクトリの権限が重要です。秘密鍵が広く読める状態になっていると、SSH クライアント側で拒否されることがあります。
ls -ld ~/.ssh
ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys 2>/dev/null || true
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 2>/dev/null || true
chmod 644 ~/.ssh/id_ed25519.pub 2>/dev/null || true
chmod 600 ~/.ssh/authorized_keys 2>/dev/null || true管理用の鍵は、使い回しすぎると境界が曖昧になります。どの管理端末から、どのユーザーで、どのサーバーへ入るのかを整理し、公開鍵の登録先を管理できる状態にしておきます。
authorized_keys を確認する
サーバー側では、管理ユーザーの ~/.ssh/authorized_keys に公開鍵が登録されている必要があります。Ansible では authorized_key 相当の処理で公開鍵を登録し、既存の鍵を排他的に消さない方針にしています。手動で確認する場合は、対象ユーザーを間違えないことが重要です。
sudo -u myadmin ls -ld /home/myadmin/.ssh
sudo -u myadmin ls -l /home/myadmin/.ssh/authorized_keys
sudo -u myadmin sed -n '1,5p' /home/myadmin/.ssh/authorized_keysここで見るべきなのは、公開鍵の内容そのものだけではありません。対象ユーザー、ホームディレクトリ、.ssh ディレクトリ、authorized_keys の所有者と権限が揃っているかを確認します。
sshd_config は drop-in で管理する
Ubuntu 26.04 では、既定の /etc/ssh/sshd_config を直接大きく書き換えるより、/etc/ssh/sshd_config.d/ 配下にローカル設定を置く方が管理しやすくなります。ここでは /etc/ssh/sshd_config.d/99-local.conf として、サーバー固有の SSH ポリシーをまとめます。
sudo install -d -m 755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/99-local.conf >/dev/null <<'EOF'
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding yes
PermitTTY yes
LoginGraceTime 30s
MaxAuthTries 3
MaxSessions 10
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
PrintMotd no
AcceptEnv LANG LC_*
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf基本方針は、root ログインを禁止し、公開鍵認証を有効にし、通常のパスワード認証を無効化することです。LogLevel VERBOSE にしておくと、公開鍵認証まわりの確認もしやすくなります。
信頼済み管理ネットワークだけ例外にする
すべての経路でパスワード認証を許可しない構成は分かりやすい一方で、初期構築や管理端末の復旧時に困ることがあります。そのため、信頼済みの管理ネットワークと管理ユーザーに限定して、Match Address で例外を作る設計もあります。
sudo tee -a /etc/ssh/sshd_config.d/99-local.conf >/dev/null <<'EOF'
Match Address 10.1.0.0/24 User myadmin
PasswordAuthentication yes
Match Address fd00::/64 User myadmin
PasswordAuthentication yes
EOFこの例外は、パスワード認証を広く戻すためのものではありません。対象を管理ユーザーと管理ネットワークに限定し、外部公開経路では公開鍵認証を基本にするための逃げ道です。実環境では、自分の管理ネットワークに合わせて CIDR を調整します。
設定を検証してから反映する
SSH の設定ミスは、作業中の接続を失う原因になります。設定ファイルを書いたら、まず sshd -t で構文を検証します。問題がなければ ssh.service を reload または restart します。
sudo sshd -t -f /etc/ssh/sshd_config
sudo sshd -t -f /etc/ssh/sshd_config.d/99-local.conf
sudo systemctl reload ssh
systemctl status ssh --no-pager通常は /etc/ssh/sshd_config 全体を検証する方が実運用に近い確認になります。drop-in ファイル単体の検証は、テンプレートやローカル設定の構文確認として使います。
別セッションで接続確認する
SSH 設定を変更した直後は、現在の接続を閉じる前に、必ず別セッションでログインできることを確認します。ここを省略すると、設定ミスで自分を締め出すことがあります。
ssh -i ~/.ssh/id_ed25519 myadmin@10.1.0.10
ssh -v -i ~/.ssh/id_ed25519 myadmin@10.1.0.10ssh -v を使うと、どの鍵を試したのか、公開鍵認証が成功したのか、どの段階で失敗しているのかを確認できます。接続できない場合は、クライアント側の鍵、サーバー側の authorized_keys、sshd_config、Firewall、経路を分けて確認します。
ログで SSH 接続を確認する
SSH のログは、接続できない時だけでなく、設定変更後の確認にも使います。Ubuntu 26.04 では journal から ssh.service のログを確認できます。
journalctl -u ssh --since '30 minutes ago' --no-pager
grep -E 'sshd|Accepted|Failed|Disconnected' /var/log/auth.log 2>/dev/null || trueログでは、公開鍵認証が成功したのか、パスワード認証が拒否されたのか、接続元が想定どおりかを確認します。Match Address を使っている場合は、接続元アドレスが例外条件に入っているかも確認対象になります。
SSH 設定の確認観点
| 確認項目 | 見るもの |
|---|---|
| root ログイン | PermitRootLogin no になっているか |
| 公開鍵認証 | PubkeyAuthentication yes と authorized_keys が揃っているか |
| パスワード認証 | 通常は無効、必要な例外だけ Match で限定しているか |
| 鍵ファイル権限 | 秘密鍵が 0600、.ssh が 0700 になっているか |
| サービス状態 | ssh.service が起動し、listen しているか |
| ログ | 成功・失敗・接続元が追えるか |
まとめ
Ubuntu 26.04 の SSH 設定は、ログイン手段を用意するだけではなく、管理経路の入口を設計する作業です。公開鍵、authorized_keys、sshd_config、信頼済み管理ネットワーク、ログ確認を分けて整理すると、設定の意味が見えやすくなります。
特に重要なのは、SSH を広く開けるのではなく、誰が、どこから、どの認証方式で入れるのかを明確にすることです。公開鍵認証を基本にし、パスワード認証を使う場合も管理ネットワークと管理ユーザーに限定することで、運用上の復旧性と安全性のバランスを取りやすくなります。


