2026年9月1日

SSH公開鍵認証の設定方法（ed25519鍵の作成からパスワード認証の無効化まで）

サーバーセキュリティ・SSL

SSH公開鍵認証を設定するには、手元のPCで ssh-keygen -t ed25519 を実行して鍵ペアを作り、公開鍵をサーバーの ~/.ssh/authorized_keys に登録します。この記事では、鍵の作成、ssh-copy-id での登録、つまずきやすいパーミッション、鍵でログインできることの確認、そして締め出されない順番でのパスワード認証の無効化（sshd_config.d を使う方法）までを説明します。

公開鍵認証の仕組みと、なぜパスワードより安全か

公開鍵認証では、秘密鍵と公開鍵の二つを一組で使います。秘密鍵は手元のPCだけに置き、公開鍵をサーバーに登録します。ログインのとき、サーバーは「この公開鍵に対応する秘密鍵を持っているか」を署名で確かめるだけで、秘密鍵そのものはネットワークを流れません。

パスワード認証は、インターネットに公開されたサーバーでは常に総当たり攻撃の対象になります。公開鍵認証にしてパスワード認証を止めれば、パスワードを推測する攻撃はそもそも成立しなくなります。WordPress を置いた VPS で最初に行うべき対策の一つです。

鍵ペアを作成する（ed25519）

手元のPC（クライアント）で実行します。Windows 10/11 には OpenSSH クライアントが標準で入っているため、PowerShell でも同じコマンドが使えます。

ssh-keygen -t ed25519 -C "yourname@laptop"

保存先を聞かれたら、そのまま Enter で ~/.ssh/id_ed25519（Windows では C:\Users\ユーザー名\.ssh\id_ed25519）に保存されます。既に同じ名前の鍵がある場合は上書きするか聞かれるので、既存の鍵を使っているなら n を選んで別名にしてください。

続いてパスフレーズを聞かれます。空にもできますが、PCの紛失や盗難で秘密鍵が漏れたとき、パスフレーズがあれば悪用までの時間を稼げます。毎回の入力が面倒なら、後述の ssh-agent を使えば一度の入力で済みます。

鍵の種類は ed25519 を選ぶのが現在の標準です（2026年10月現在）。RSA に比べて鍵が短く、署名も速く、主要なディストリビューションの OpenSSH はすべて対応しています。古い機器やサービスが ed25519 に対応していない場合に限り、ssh-keygen -t rsa -b 4096 で RSA 鍵を作ります。DSA 鍵は最近の OpenSSH では使えません。

作成されるのは次の二つのファイルです。

id_ed25519：秘密鍵。他人に渡さず、サーバーにも置きません。
id_ed25519.pub：公開鍵。サーバーに登録するのはこちらです。

公開鍵をサーバーに登録する

ssh-copy-id を使う（Linux・macOS）

この時点ではまだパスワードでログインできる状態にしておきます。

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.10

パスワードを入力すると、公開鍵がサーバーの ~/.ssh/authorized_keys に追記されます。~/.ssh ディレクトリがなければ作成し、適切なパーミッションも設定してくれるので、手作業より間違いが起きにくい方法です。SSHのポートを変えている場合は -p 10022 のように指定します。

Windows から登録する

Windows の OpenSSH には ssh-copy-id がないため、PowerShell で公開鍵を送って追記します。

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@203.0.113.10 "umask 077; mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

umask 077 を付けているのは、新しく作られるディレクトリとファイルを本人だけが読み書きできる権限にするためです。>>（追記）を >（上書き）と書き間違えると、既に登録されている他の鍵が消えるので注意してください。

VPS によっては、サーバー作成時に管理画面から公開鍵を登録できるものもあります。その場合は公開鍵の中身（ssh-ed25519 AAAA... yourname@laptop の1行）を貼り付けます。

パーミッションを確認する

公開鍵認証がうまくいかない原因で最も多いのがパーミッションです。sshd は、~/.ssh や authorized_keys が他のユーザーから書き換えられる状態だと、安全でないと判断してその鍵を使いません（StrictModes という既定で有効な設定によるものです）。サーバー上で次のように設定します。

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

ホームディレクトリ自体がグループや他人から書き込める状態でも拒否されるため、chmod go-w ~ も確認しておきます。root で作業してファイルを用意した場合は、所有者がログインするユーザーになっているかも見てください（chown -R user:user ~user/.ssh）。

RHEL 系で SELinux が有効な環境では、手作業でコピーしたファイルにSELinuxのラベルが正しく付かず拒否されることがあります。その場合は restorecon -Rv ~/.ssh でラベルを付け直します。

鍵でログインできることを確かめる

ここからが大切なところです。今つないでいる SSH セッションは閉じずに残したまま、別のターミナルを開いて新しく接続します。

ssh -i ~/.ssh/id_ed25519 -o PreferredAuthentications=publickey user@203.0.113.10

PreferredAuthentications=publickey を付けると、鍵での認証だけを試し、失敗してもパスワードの入力に進みません。パスワードを聞かれずに（パスフレーズを設定した場合はパスフレーズだけを聞かれて）ログインできれば成功です。

うまくいかないときは -v を付けて詳細を表示します。「Offering public key」の後に「Server accepts key」と出ていれば鍵は受け付けられています。サーバー側のログも確認しましょう。

# Debian / Ubuntu
sudo journalctl -u ssh --since "10 min ago"
# RHEL 系
sudo journalctl -u sshd --since "10 min ago"

成功すれば「Accepted publickey for user」、パーミッションが原因なら「bad ownership or modes」を含むメッセージが出ます。

パスワード認証を無効にする

鍵でのログインを別セッションで確認できてから、パスワード認証を止めます。設定は /etc/ssh/sshd_config を直接書き換えるより、/etc/ssh/sshd_config.d/ にファイルを追加する方法がおすすめです。Ubuntu 20.04 以降、Debian 11 以降、RHEL 9 以降などでは、sshd_config の先頭付近に Include /etc/ssh/sshd_config.d/*.conf があり、このディレクトリのファイルが読み込まれます。パッケージの更新で sshd_config が置き換わっても自分の設定が残るのが利点です。

作業前に、設定ディレクトリをバックアップしておきます。

sudo cp -a /etc/ssh /etc/ssh.bak-$(date +%Y%m%d)
sudo vi /etc/ssh/sshd_config.d/10-hardening.conf

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

KbdInteractiveAuthentication は、キーボード入力によるパスワード認証の経路を閉じるための設定です（古い OpenSSH では ChallengeResponseAuthentication という名前でした）。PermitRootLogin prohibit-password は root の鍵ログインだけを許す設定で、root で直接ログインする必要がなければ no にします。

ここで知っておきたいのが、sshd は同じ項目が複数回出てきた場合に最初の値を採用するという点です。sshd_config.d 内のファイルは名前順に読まれるため、クラウドのイメージによっては 50-cloud-init.conf に PasswordAuthentication yes が書かれていて、それより後ろの名前のファイルに書いた設定が効かないことがあります。ファイル名を 10- のように小さい番号で始めるか、既存のファイルの中身も確認してください。

実際に効く値は sshd -T で確認できます。

sudo sshd -t
sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin)'

sshd -t で構文エラーがないことを確かめ、sshd -T で passwordauthentication no になっていれば反映の準備ができています。sshd を再起動します。

# Debian / Ubuntu
sudo systemctl restart ssh
# RHEL 系
sudo systemctl restart sshd

再起動しても、既に確立している SSH セッションは切れません。残しておいたセッションはそのままにして、もう一度別のターミナルから鍵でログインできることを確認します。あわせて、パスワード認証が本当に止まったかも試します。

ssh -o PubkeyAuthentication=no user@203.0.113.10
# → Permission denied (publickey). と出れば無効化できている

ここまで確認できたら、残しておいたセッションを閉じて構いません。

日常の運用を楽にする設定

接続先が増えたら、手元の ~/.ssh/config に接続情報をまとめておくと、ssh myvps だけで接続できます。

Host myvps
    HostName 203.0.113.10
    User user
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes は、指定した鍵だけを使う設定です。鍵を多く持っていると、サーバー側の試行回数の上限に達して「Too many authentication failures」で切断されることがあり、それを防げます。

パスフレーズの入力を省くには ssh-agent を使います。Linux や macOS では ssh-add ~/.ssh/id_ed25519 で鍵を登録します。Windows では「OpenSSH Authentication Agent」サービスが既定で無効なので、サービスを自動起動にしてから ssh-add を実行します。

秘密鍵を新しいPCへ移すときや、PCを手放すときは、サーバーの authorized_keys から不要になった公開鍵の行を削除しておきます。鍵ごとに -C でコメントを付けておくと、どの行がどの端末の鍵かを判別しやすくなります。

まとめ

鍵はクライアントで ssh-keygen -t ed25519 を実行して作り、秘密鍵は手元に、公開鍵だけをサーバーに置きます。
登録は ssh-copy-id が手軽です。Windows では公開鍵をパイプで送り、authorized_keys に追記します。
~/.ssh は700、authorized_keys は600、ホームディレクトリは他人が書き込めない状態にします。
パスワード認証の無効化は、鍵でのログインを別セッションで確認してから行います。設定は sshd_config.d に書き、sshd -T で実際の値を確かめます。
再起動後も別セッションで鍵ログインとパスワード拒否の両方を確認し、それから元のセッションを閉じます。