サーバーにリモートで接続する際、多くの人がまず思い浮かべるのは「ユーザー名とパスワードを入力してログインする方法」ではないでしょうか。確かに手軽ですが、実際にはパスワードを狙った総当たり攻撃（ブルートフォース攻撃）や辞書攻撃のリスクに常に晒されており、セキュリティ面では十分とはいえません。また、接続するたびに長いパスワードを入力するのは手間がかかり、日々の運用作業において非効率です。
そこでおすすめなのが「SSH公開鍵認証（鍵認証）」です。公開鍵と秘密鍵のペアを用いることで、通信経路上にパスワードを一切流すことなく、安全かつ瞬時にサーバーへログインできるようになります。セキュリティを大幅に強化しながら、日々のログイン作業やスクリプトによる自動処理を快適に行うことができます。
この記事では、初心者から実務担当者まで迷わず実践できるように、SSH鍵認証の仕組みから現代推奨の鍵生成（Ed25519）、サーバーへの公開鍵登録、厳格なパーミッション設定、sshd設定によるパスワード認証の無効化、締め出し防止手順、トラブルシューティングまでを網羅して分かりやすく解説します。
【早見表】SSH鍵認証設定の完全フロー チートシート
SSH鍵認証を導入する際の一連の標準手順と、クライアント側・サーバー側で実行するコマンド一覧です。
| ステップ | 作業内容 | 実行環境 | 主要コマンド / 設定 |
|---|---|---|---|
| Step 1 | 鍵ペアの生成 | クライアントPC | ssh-keygen -t ed25519 -C "comment" |
| Step 2 | 公開鍵の転送・登録 | クライアントPC | ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server |
| Step 3 | パーミッション設定 | サーバー側 | chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys |
| Step 4 | 鍵認証の接続テスト | クライアントPC | ssh -i ~/.ssh/id_ed25519 user@server |
| Step 5 | パスワード認証の無効化 | サーバー側 | /etc/ssh/sshd_config で PasswordAuthentication no |
| Step 6 | 構文チェックとsshd再起動 | サーバー側 | sudo sshd -t && sudo systemctl restart ssh |
SSH鍵認証とは？
SSH鍵認証は、暗号技術における「公開鍵暗号方式」を利用したログイン認証の仕組みです。通常のパスワード認証と異なり、ペアとなる2つの暗号鍵を用いることで、第三者による不正侵入を極めて強固に防ぎます。
パスワード認証の仕組みと課題
従来のパスワード認証では、接続時にクライアントから送信されたユーザー名とパスワードを、サーバー側が保持する認証情報と照合します。手軽に利用できる反面、実務環境では以下のような深刻な課題があります。
- 総当たり攻撃（ブルートフォース攻撃）に弱い：インターネットに公開されているSSHポート（デフォルト22番）は、botによる不正アクセスの試行を常時受けています。
- パスワード漏洩時のリスクが大きい：複数サーバーで同一パスワードを使い回している場合、1箇所が侵害されると他のサーバーも芋づる式に侵入されます。
- スクリプトの自動化に不向き：対話形式でのパスワード入力が求められるため、深夜の自動バックアップやCI/CD等の無人実行が困難になります。
公開鍵と秘密鍵の基本的な役割
SSH鍵認証では、対となる2つの鍵（「秘密鍵」と「公開鍵」）をセットで扱います。
- 秘密鍵（Private Key）：手元のクライアントPCに厳重に保管し、絶対に外部へ公開・送信してはいけない鍵
- 公開鍵（Public Key）：接続先サーバーの
~/.ssh/authorized_keysに事前に登録しておく鍵（第三者に見られても安全な鍵）
接続要求があると、サーバーは公開鍵を使って暗号化したチャレンジデータをクライアントに送信し、クライアントが手元の秘密鍵で正しく復号・署名できるかを検証します。通信経路上にパスワードが一切流れないため、盗聴や辞書攻撃によって認証を破られる心配がありません。
鍵認証を導入するメリット
- セキュリティの飛躍的な向上：総当たり攻撃を完全に無力化でき、不正アクセスの脅威を最小限に抑えられます。
- 日々のログイン作業の効率化：一度設定すれば毎回のパスワード入力が不要となり、作業のテンポが向上します。
- バッチ処理・運用の自動化：定期的なファイル同期（
rsync）やログ収集スクリプトを、非対話形式で安全に自動実行できます。
SSH鍵の作成方法
SSH鍵認証を利用するには、まず手元のクライアントPC（Linux、macOS、WindowsのWSLやPowerShellなど）で鍵ペアを生成します。
鍵アルゴリズムの選び方（Ed25519 vs RSA）
SSH鍵を生成する際は、暗号アルゴリズムの選択が重要です。現在、OpenSSHで強く推奨されている標準アルゴリズムは Ed25519 です。
| アルゴリズム | 推奨状況 | 特徴・安全性 | 主な用途 |
|---|---|---|---|
| Ed25519 | 強く推奨（標準） | 高強度・超高速・鍵長が短く扱いやすい（256bit） | 新規構築、モダンなLinux環境（OpenSSH 6.5以降） |
| RSA (4096bit) | 互換性維持 | 歴史が長く互換性が高いが、計算負荷が高く鍵が長い | 古いOS、Ed25519非対応のレガシー機器 |
| ECDSA | 非推奨 | 乱数生成器の脆弱性リスクが指摘されている | 特段の理由がない限り使用を避ける |
| DSA | 廃止（使用不可） | 暗号強度が不足しており、近年のOpenSSHでは標準で無効化 | 使用禁止 |
レガシー機器への接続など特別な理由がない限り、新規作成時は Ed25519 を選択してください。
ssh-keygen コマンドで鍵を生成
鍵ペアの生成には ssh-keygen コマンドを使用します。
Ed25519 鍵の生成（推奨）：
# クライアントPCで実行
ssh-keygen -t ed25519 -C "your_email@example.com"※ -C オプションには、鍵の識別用コメント（メールアドレスや端末名など）を指定します。
RSA 4096bit 鍵の生成（レガシー環境用）：
# レガシー互換が必要な場合
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"鍵生成時の対話プロンプトの流れ
コマンドを実行すると、対話形式で保存先ファイル名とパスフレーズの設定を求められます。
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/username/.ssh/id_ed25519): [そのままEnter]
Enter passphrase (empty for no passphrase): [パスフレーズを入力]
Enter same passphrase again: [パスフレーズを再入力]
Your identification has been saved in /Users/username/.ssh/id_ed25519
Your public key has been saved in /Users/username/.ssh/id_ed25519.pub- 保存先：通常はデフォルト（
~/.ssh/id_ed25519）のまま Enter を押します。 - パスフレーズ：秘密鍵自体を暗号化して保護するためのパスワードです。万一ノートPCの紛失・盗難が発生しても、パスフレーズがあれば秘密鍵の即時不正利用を防げます。
保存先とファイルの構成
生成されたファイルを ls コマンドで確認します。
ls -la ~/.ssh/id_ed25519*id_ed25519（末尾に.pubがないファイル）… 秘密鍵。手元で厳重に保管し、他人に絶対渡さない。id_ed25519.pub（末尾に.pubがあるファイル）… 公開鍵。サーバーに登録するファイル。
パスフレーズを設定するべきかどうか
パスフレーズの設定方針は、利用用途によって使い分けます。
- 個人利用・開発端末（パスフレーズあり推奨）：秘密鍵の保護レベルを最大化できます。後述の
ssh-agentを利用すれば、接続ごとの入力負担も解消できます。 - CI/CD・完全無人の自動スクリプト（パスフレーズなし）：対話入力ができない無人環境ではパスフレーズなしで運用します。その代わり、秘密鍵ファイルの権限やアクセス元IPの制限を徹底する必要があります。
サーバーに公開鍵を登録する
鍵ペアが完成したら、公開鍵（id_ed25519.pub）の内容をリモートサーバーの ~/.ssh/authorized_keys に登録します。
~/.ssh/authorized_keys の役割
サーバー側の各ユーザーディレクトリ配下にある ~/.ssh/authorized_keys は、「このユーザーへのログインを許可する公開鍵の一覧」を保持するファイルです。ここに登録された公開鍵と一致する秘密鍵を提示したクライアントだけが、認証を通過できます。
ssh-copy-id コマンドの使い方（推奨・最短）
OpenSSHに標準付属する ssh-copy-id コマンド を使用すると、サーバー側の ~/.ssh ディレクトリ作成、パーミッション設定、公開鍵の登録を一発で自動処理できます。
# クライアントPC側で実行（標準ポート22番の場合）
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip
# SSHポートを変更している場合（例: 2222番）
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 user@server_ip初回のみサーバーユーザーのパスワードを入力すると、公開鍵が自動的に転送・追記されます。
手動で authorized_keys に登録する場合の手順
Windowsの標準PowerShell環境などで ssh-copy-id が利用できない場合は、以下のいずれかの方法で手動登録します。
パターン1：SSH経由のワンライナー（クライアント側で実行）
cat ~/.ssh/id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"パターン2：サーバー側で直接ファイルを編集
- クライアントPCで公開鍵の内容を表示してクリップボードにコピー：
cat ~/.ssh/id_ed25519.pub - サーバーにログインし、
~/.ssh/authorized_keysに追記保存：mkdir -p ~/.ssh # 既存の登録鍵を消さないよう、必ず追記（>>）を実行 echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... your_email@example.com" >> ~/.ssh/authorized_keys
サーバー側のパーミッション（権限）を厳格に設定する
SSH鍵認証で初心者が最もつまずきやすいのがパーミッション（ファイル権限）のエラーです。SSHサーバー（sshd）はセキュリティ機構（StrictModes）により、設定ファイルやディレクトリの権限が緩い（他のユーザーが書き込める状態である）場合、認証処理を自動的に拒否します。
| 対象ディレクトリ / ファイル | 適切なパーミッション | 要件と注意点 |
|---|---|---|
ユーザーのホームディレクトリ (~/) | 755 または 700 | グループや他人に書き込み権限（777/775）があると拒否される |
SSHディレクトリ (~/.ssh) | 700 (drwx------) | 所有者のみ読取・書込・実行可能 |
公開鍵登録ファイル (authorized_keys) | 600 (-rw-------) | 所有者のみ読取・書込可能 |
サーバー側で以下のコマンドを実行し、権限と所有権を確実に整えておきましょう。
# サーバー側で実行
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# 所有者がログインユーザー自身になっていることを確認
chown -R $USER:$USER ~/.ssh鍵認証でログインしてみる
サーバー側の準備が整ったら、クライアント側から鍵認証でログインできるかテストします。
実際の接続例
生成した秘密鍵を明示的に指定して接続します。
ssh -i ~/.ssh/id_ed25519 user@server_ipサーバーのログインパスワードを求められず、秘密鍵のパスフレーズを入力（またはパスフレーズなしなら即座）にシェルが開けば、鍵認証の成功です。
~/.ssh/config を設定して接続を効率化する
毎回 -i ~/.ssh/id_ed25519 やユーザー名、ホストIPを入力するのは手間がかかります。SSH configファイル（~/.ssh/config） をクライアント側に作成しておけば、ssh myserver という短いエイリアスだけで瞬時に接続できます。
# クライアントPCの ~/.ssh/config に追記
Host myserver
HostName 203.0.113.10
User ubuntu
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes設定完了後は、以下の短いコマンドだけで接続可能です。
ssh myserverパスワードログインを無効化する
鍵認証でのログインが確認できたら、セキュリティ対策を完成させるためにサーバー側のパスワード認証を完全に無効化します。これにより、総当たり攻撃を根本から遮断できます。
無効化する際の最重要注意事項（締め出し防止）
設定変更作業を行う際は、現在接続しているSSHターミナルセッションを絶対に切断しないでください。万一設定に誤りがあった場合でも、現在のセッションを開いたままにしておくことで、設定ファイルを元の状態に戻す（リカバリする）ことができます。
sshd_config の設定変更手順
まず設定ファイルのバックアップを作成してから編集します。
# バックアップを作成
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# 設定ファイルを編集
sudo nano /etc/ssh/sshd_config
# または sudo vim /etc/ssh/sshd_config以下のディレクティブを確認・修正します（行頭に # がある場合は削除して有効化します）。
# 公開鍵認証を有効化
PubkeyAuthentication yes
# パスワード認証を禁止（最重要）
PasswordAuthentication no
# 空パスワードでのログインを禁止
PermitEmptyPasswords no
# チャレンジレスポンス認証を禁止
KbdInteractiveAuthentication no
# rootユーザーの直接パスワードログインを禁止
PermitRootLogin prohibit-password※ Ubuntu 22.04以降などの環境では、/etc/ssh/sshd_config.d/*.conf 配下に個別設定が配置されている場合があります。その場合は /etc/ssh/sshd_config.d/50-cloud-init.conf 等で PasswordAuthentication yes が上書きされていないかも併せて確認してください。
構文チェックとSSHサービスの再起動
サービスを再起動する前に、必ず sshd -t で設定ファイルの構文エラーを検査します。
sudo sshd -tエラーが出力されずプロンプトが戻れば、構文は正常です。続けてSSHサービスを再起動します。
# Ubuntu / Debian 系の場合
sudo systemctl restart ssh
# RHEL / AlmaLinux / Rocky Linux / CentOS 系の場合
sudo systemctl restart sshd新しいターミナルでの接続確認とパスワード遮断テスト
既存の接続セッションを維持したまま、クライアントPC側で新しいターミナルウィンドウを開き、以下の2つのテストを実施します。
- 鍵認証でのログイン確認：
問題なくログインできることを確認します。ssh -i ~/.ssh/id_ed25519 user@server_ip - パスワード認証が正しく拒否されるかのテスト：
あえて鍵認証を無効化して接続を試みます。
以下のようにssh -o PubkeyAuthentication=no user@server_ipPermission denied (publickey)と表示され、パスワード入力プロンプトすら出ずに接続が遮断されれば成功です。user@server_ip: Permission denied (publickey).
鍵認証を安全に運用するためのポイント
SSH鍵認証は極めて安全な仕組みですが、運用方法を誤ると鍵の漏洩などのリスクが生じます。安全に運用するための基本原則を押さえておきましょう。
秘密鍵の保管とクライアント側の権限設定
秘密鍵は、手元のPC内でも所有者以外のユーザーから読み取られないよう権限を制限しておく必要があります。
# クライアントPC側で権限を確認・設定
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519秘密鍵をクラウドストレージや公開リポジトリ（GitHubなど）、チャットツールで共有することは絶対に避けてください。
複数端末・複数ユーザーでの鍵管理方法
会社PCと自宅PC、あるいはチーム運用など、複数端末・複数人がサーバーに接続する場合は、「1端末（1人）につき1つの鍵ペア」を作成するのが鉄則です。サーバーの ~/.ssh/authorized_keys には複数の公開鍵を行単位で列挙できます。
# ~/.ssh/authorized_keys の例
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... work-pc
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... home-laptop端末ごとに鍵を分けておけば、万が一どれか1台を紛失した場合でも、該当する公開鍵の1行を削除するだけで、他の端末に影響を与えることなくその端末からのアクセスのみを即座に失効させることができます。
ssh-agent でパスフレーズ入力を省略する
秘密鍵に強固なパスフレーズを設定すると安全ですが、接続のたびに入力するのは負担になります。ssh-agent を活用すれば、OSのログインセッション中に一度パスフレーズを入力するだけで、メモリ上に安全にキャッシュして以降の入力を省略できます。
# ssh-agentの起動と鍵の登録
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519不要になった鍵の削除と定期棚卸し
担当者の退職やプロジェクトの終了、端末の破棄に伴い、不要になった公開鍵は速やかに ~/.ssh/authorized_keys から削除してください。定期的にファイルを棚卸しし、誰のどの端末の鍵かが分からない「野良鍵」を残さない運用体制を整えましょう。
よくあるトラブルと解決法
鍵認証の設定中や運用中に発生しやすい代表的なトラブルと、その解決チェックリストです。
「Permission denied (publickey)」が出る場合のチェックリスト
Permission denied エラー でログインできないときは、以下の項目を上から順に確認してください。
- パーミッションの不備：サーバー側で
chmod 700 ~/.sshおよびchmod 600 ~/.ssh/authorized_keysが設定されているか確認します。 - ホームディレクトリの権限が緩すぎる：サーバー側の
/home/usernameの権限が777や775になっていると、sshdの StrictModes により拒否されます（chmod 755 /home/usernameに修正）。 - 公開鍵の内容・改行崩れ：
authorized_keysに貼り付けた際、途中に改行が入って複数行に分裂していないか、末尾の改行が存在するか確認します。 - SELinuxによる遮断（RHEL / AlmaLinux系）：ファイルを手動作成した場合、SELinuxコンテキストがずれてアクセスが拒否されることがあります。
# SELinuxコンテキストの再適用 restorecon -R -v ~/.ssh - 所有権の誤り：
~/.sshディレクトリやauthorized_keysが root 所有になっていないか確認します（chown -R $USER:$USER ~/.ssh）。
ssh -vvv による詳細デバッグログの出力
原因がどうしても特定できない場合は、クライアント側で -vvv オプションを付与してSSHコマンドを実行します。
ssh -vvv user@server_ipどの鍵ファイルが読み込まれたか（Offering public key）、サーバーがそれを受け入れたか（Server accepts key）など、認証のどのフェーズで拒否されたかが明確に出力されます。
別の端末から接続できないとき
新しい端末やPCから接続する場合は、その端末上で新しく ssh-keygen を実行して鍵ペアを生成し、公開鍵をサーバーの ~/.ssh/authorized_keys に追加登録してください。秘密鍵を複数端末間でコピーして使い回すことはセキュリティ上推奨されません。
まとめ
SSH公開鍵認証の導入は、Linuxサーバーのセキュリティ基盤を確立するための必須ステップです。
- 鍵生成：安全性・処理速度に優れた
ssh-keygen -t ed25519を標準として選択する - 公開鍵登録：
ssh-copy-idを使って確実にサーバーのauthorized_keysに配置する - 権限の厳守：
~/.sshは700、authorized_keysは600、ホームディレクトリは755を守る - パスワード無効化：
sshd_configでPasswordAuthentication noを設定し、セッションを維持したまま別ウィンドウで接続確認を行う
鍵認証の設定が完了したら、続けて SSH configファイルの設定 による接続簡略化や、SSHポートの変更（22番からの移行） などのセキュリティ対策も進め、より安全で効率的なインフラ環境を構築しましょう。
コメント