• HOME
  • OpenSSHの鍵ペア生成と公開鍵認証の設定手順

2026年10月15日

  • シェア
  • ツイート

    • 2026年10月15日

    OpenSSHの鍵ペア生成と公開鍵認証の設定手順

    OpenSSHの公開鍵認証は、手元で鍵ペアを作り、公開鍵だけをサーバーの ~/.ssh/authorized_keys に置き、鍵でログインできることを確かめてからパスワード認証を止める、という順で進めます。この記事では、鍵の種類の選び方から、sshd の設定、ログインできないときの調べ方までを、締め出し事故を起こさない手順でまとめます。WordPress を置いた VPS へのデプロイや WP-CLI の操作を SSH で行う人を想定しています。

    鍵の種類はEd25519を基本にする

    新しく鍵を作るなら、Ed25519 を選ぶのが一般的です。鍵が短く、署名も速く、現行の OpenSSH であれば標準で扱えます。古い機器や一部のサービスが Ed25519 に対応していない場合だけ RSA を使い、その場合は 3072 ビット以上にします。

    なお、OpenSSH 8.8 以降では SHA-1 を使う ssh-rsa 署名が既定で無効になっています。RSA 鍵そのものが使えなくなったわけではなく、rsa-sha2-256 / rsa-sha2-512 の署名で引き続き使えます。古いサーバーに接続できなくなったときは、鍵ではなくサーバー側の OpenSSH が古いことを疑ってください。

    FIDO2 対応のセキュリティキーを持っているなら、ed25519-sk 形式の鍵も選べます（OpenSSH 8.2 以降）。鍵ファイルを盗まれても物理キーがなければ使えない点が利点です。

    鍵ペアを生成する

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

    ssh-keygen -t ed25519 -a 100 -C "taro@laptop-2026"

    -C は鍵の識別用コメントで、どの端末の鍵かが後から分かる名前にしておくと、端末を手放したときに authorized_keys から該当行を消しやすくなります。-a はパスフレーズから鍵を守る処理の繰り返し回数で、値を大きくすると総当たりに強くなる代わりに、鍵を読み込むたびに少し時間がかかります。

    保存先を聞かれたら、既定の ~/.ssh/id_ed25519 のままで構いません。既に同名の鍵がある場合は上書きせず、-f ~/.ssh/id_ed25519_vps のように別名を付けます。上書きすると、その鍵でログインしていた別のサーバーに入れなくなります。

    パスフレーズは空にしないでください。鍵ファイルは PC の盗難やバックアップの流出でそのまま持ち出されるため、パスフレーズが最後の防御になります。毎回の入力が手間なら、後述の ssh-agent で解決します。

    生成すると、秘密鍵 id_ed25519 と公開鍵 id_ed25519.pub の2つができます。サーバーに渡すのは .pub の付いた公開鍵だけです。

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

    Linux や macOS からは ssh-copy-id が簡単です。この時点ではまだパスワードでログインします。

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

    Windows には ssh-copy-id が無いため、公開鍵の中身を送って追記します。

    type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

    手作業で登録する場合に一番つまずきやすいのがパーミッションです。sshd は既定（StrictModes yes）で、他人が書き換えられる場所にある鍵を無視します。次の状態になっているか確認してください。

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

    ホームディレクトリ自体がグループや他人に書き込み可能（drwxrwxr-x など）だと、鍵が正しくても拒否されます。所有者が別ユーザーになっていないか（root で作業して root 所有のファイルを作っていないか）もあわせて見ます。SELinux が有効な RHEL 系では、ファイルをコピーした後に restorecon -Rv ~/.ssh でラベルを直さないと読み込まれないことがあります。

    鍵でログインできることを確認する

    パスワード認証を止める前に、別のターミナルで鍵ログインを試します。今つながっているセッションは閉じないでおくのが安全です。

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

    PreferredAuthentications=publickey を付けると、鍵が通らなかった場合にパスワード入力へ逃げずに失敗するため、本当に鍵で入れているかが分かります。パスフレーズを聞かれてログインできれば成功です。

    sshdの設定でパスワード認証を止める

    鍵ログインを確認できたら、サーバー側の設定を変えます。最近の Ubuntu や Debian、RHEL 系では /etc/ssh/sshd_config が /etc/ssh/sshd_config.d/*.conf を読み込む構成になっていることが多いため、本体を直接書き換えるより、追加ファイルを置く方が管理しやすくなります。

    sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo tee /etc/ssh/sshd_config.d/10-key-auth.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

    KbdInteractiveAuthentication は、古い設定ファイルで ChallengeResponseAuthentication と書かれていた項目の現在の名前です。これを止めないと、環境によってはキーボード対話方式でパスワード入力を受け付け続けます。root で直接ログインする運用をしていないなら PermitRootLogin no にしても構いません。

    注意したいのは、sshd の設定は同じ項目が複数回出てくると最初に読んだ値が使われる点です。クラウドの VPS では cloud-init が 50-cloud-init.conf などに PasswordAuthentication yes を書いていることがあり、ファイル名の順番によってはこちらの設定が負けます。上の例でファイル名を 10- で始めているのはそのためです。実際に効いている値は次のコマンドで確かめます。

    sudo sshd -t
sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|pubkeyauthentication|permitrootlogin'

    sshd -t は構文チェックで、何も出なければ問題ありません。エラーが出たまま再起動すると sshd が起動せず、新しい接続を受け付けなくなります。チェックが通ったら再読み込みします。サービス名は Ubuntu/Debian では ssh、RHEL 系では sshd です。

    sudo systemctl reload ssh   # RHEL系は sudo systemctl reload sshd

    再読み込み後も、元のセッションを残したまま別のターミナルで鍵ログインと、パスワードログインが拒否されることの両方を試してください。両方とも期待どおりなら作業完了です。VPS の管理画面にあるシリアルコンソールや VNC コンソールの使い方も、事前に確認しておくと締め出されたときに慌てずに済みます。

    クライアント側の設定とssh-agent

    接続先が増えたら、手元の ~/.ssh/config に接続情報をまとめておくとコマンドが短くなり、鍵の取り違えも減ります。

    Host wp-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

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

    パスフレーズの入力は ssh-add ~/.ssh/id_ed25519 で ssh-agent に鍵を読み込ませれば、ログイン中は一度で済みます。エージェント転送（ForwardAgent）は、転送先のサーバーの管理者がエージェントを使えてしまうため、信頼できるサーバー以外では有効にしないでください。

    ログインできないときの調べ方

    まずクライアント側で詳しいログを出します。

    ssh -v wp-vps

    出力の中で「Offering public key」の後に「Server accepts key」が出ていればサーバーは鍵を受け入れています。鍵を提示しているのに受け入れられていない場合は、サーバー側の原因です。可能性の高い順に次を確認します。

    1. authorized_keys や ~/.ssh、ホームディレクトリのパーミッションと所有者が正しいか
    2. 公開鍵が1行で登録されているか（コピー時の改行混入や、先頭の ssh-ed25519 の欠落）
    3. ログインしようとしているユーザー名が、鍵を登録したユーザーと一致しているか
    4. sshd -T で見た実際の設定値が意図どおりか（AuthorizedKeysFile が変更されていないか）
    5. SELinux のラベルが合っているか

    サーバー側のログは、Ubuntu/Debian なら /var/log/auth.log または journalctl -u ssh、RHEL 系なら /var/log/secure または journalctl -u sshd で見られます。「Authentication refused: bad ownership or modes」と出ていればパーミッションの問題です。

    鍵を提示すらしていない場合は、クライアントが別の鍵ファイルを見ているか、鍵の権限が緩すぎて ssh が読み込みを拒否しています。秘密鍵は chmod 600 にしてください。

    まとめ

    • 新しい鍵は Ed25519 で作り、パスフレーズを付ける。RSA が必要なら 3072 ビット以上
    • サーバーには公開鍵だけを登録し、~/.ssh は 700、authorized_keys は 600 にする
    • パスワード認証を止める前に、別のターミナルで鍵ログインを確認し、元のセッションは閉じない
    • 設定は sshd_config.d の追加ファイルに書き、sshd -t と sshd -T で効いている値を確かめてから再読み込みする
    • つながらないときは ssh -v とサーバーの認証ログで、鍵を提示しているか、拒否理由は何かを切り分ける
    Views: 39

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲