Ubuntu 26.04 講座 / Ubuntu OpenSSH サーバーとキー認証の設定方法

Ubuntu SSHキー認証は、サーバーの実際のリスナーを確認し、クライアント公開キーのみ登録した後、新しい接続で試して構成します。パスワード認証を制限する作業は、キーでのログインと管理者権限の確認が終わった後に行い、既存の管理セッションとコンソールは維持します。

サービス・ソケット・アドレスを確認する

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
ip -br address

実際のリスナーとssh.socket・ssh.serviceを一緒に確認します。この実習では既存のSSHポートを維持します。VM作成講座のNAT+ホスト専用ネットワークでは、サーバーは.20、Linuxクライアントは.10を使用し、キーコマンドは.10クライアントで実行します。インストール形態によっては、非アクティブunitが1つあっても実際のリスナーは正常であることがあります。

Ubuntu OpenSSHの案内は、インストールと設定ファイルの優先順位、検証方法を説明します。

Linuxクライアントで command -v ssh と command -v ssh-copy-id を確認し、なければ sudo apt update && sudo apt install openssh-client で準備します。サーバーの一般ユーザー名はインストール時に実際に作成した値に置き換えます。最初に公開鍵を登録する認証経路やコンソールアクセスをまず確保し、この実習のために運用サーバーの認証ポリシーを無条件で緩和しません。

サーバーの正当性を確認し、クライアントキーを作成する

サーバーコンソールで sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub によりホストキーのフィンガープリントを確認します。クライアントの初回接続時のフィンガープリントと信頼できる経路で照合します。以下のキー生成・コピーコマンドはサーバーではなく Linuxクライアントのターミナルで実行します。

ssh-keygen -t ed25519 -f "$HOME/.ssh/ubuntu-lab-ed25519"
ssh-copy-id -i "$HOME/.ssh/ubuntu-lab-ed25519.pub" labuser@192.168.56.20

labuser とアドレスは実際のアカウント・サーバーの値に置き換え、キーがすでにある場合は上書きしません。秘密鍵のパスフレーズを設定して安全に保管してください。転送するファイルは .pub 公開鍵であり、秘密鍵はサーバーにコピーしません。Windows標準SSHには ssh-copy-id がない場合があり、上記コピー例は Linuxクライアントを基準にしています。

新しい接続でキー認証のみを試す

ssh -i "$HOME/.ssh/ubuntu-lab-ed25519" -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no labuser@192.168.56.20

秘密鍵のパスフレーズ要求とサーバーアカウントのパスワード要求は異なります。この接続が成功すると、サーバーで whoami と必要な sudo 作業を確認します。失敗した場合は、ホームディレクトリ・.ssh・authorized_keys の 所有者と権限、実際のアカウント、ログから調査します。許可権限を 777 に広げません。

演習アカウントポリシーと設定検証

新しく作成した単一キー認証専用演習サーバーでパスワードログインを制限するには、既存の SSH 設定をバックアップし、/etc/ssh/sshd_config.d/00-lab-auth.conf のような別ファイルを確認します。既存の MFA・組織認証があるサーバーには以下のポリシーをそのまま適用しません。

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
PermitRootLogin no

OpenSSH は多くの項目で先に読み込んだ値を使用するため、ファイル名だけを信頼せず最終設定を確認します。Match 条件がある場合は、実際のユーザー・クライアント条件を反映した sshd -T -C の確認も必要です。この例はポリシー説明用であり、公開鍵認証での接続が検証されるまでは適用しません。

sudo sshd -t
sudo sshd -T | grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|permitrootlogin) '

適用・再起動・復元の順序

構文が正常で、SSHサービスが実際に実行中のときに、sudo systemctl reload ssh.serviceで認証設定を再読み込みさせます。この実習ではポートは変更しません。ソケットのPort・ListenAddressまで変更する作業は、ソケット生成設定やdaemon-reloadなど別途手続きを検討する必要があります。

既存のセッションを閉じる前に、新しいキーでのログイン・sudo・許可されていない認証の拒否を試します。計画した再起動後にも再接続し、失敗した場合はコンソールで今回の設定ファイルだけをバックアップ状態に戻して、構文チェックと適用を繰り返します。ホストキーが変更されたという警告は、原因が確認されるまでは無視したり、既知のホストキーを無条件に削除したりしません。