SSH接続設定の方法｜公開鍵認証の手順とトラブル対策
※本記事にはプロモーションを含む場合があります。
- 公開鍵認証はパスワード認証より安全性が高く、総当たり攻撃への耐性が強いとされています
- 鍵ペア生成はed25519方式(256ビット)が現在の主流で、互換性重視ならRSA(4096ビット以上)を選びます
- sshd_configでPasswordAuthentication noとPermitRootLogin noを設定すると防御力が底上げされます
- ポート番号を22番から2222番など任意の番号へ変更すると、自動スキャンによる攻撃を大きく減らせるといわれています
- AWS・GCP・Azureいずれも公開鍵認証が標準仕様で、鍵の管理方法にはそれぞれ違いがあります
SSH接続の基礎知識
SSH(Secure Shell)は、暗号化された通信路を介してリモートのコンピューターへ安全にアクセスするためのプロトコルです。ポート22番を標準として動作し、通信内容はすべて暗号化されるため、第三者による傍受や改ざんのリスクを抑えられます。Linuxサーバーの管理はもちろん、AWS・GCP・Azureといったクラウド上の仮想マシン、さらには自宅ネットワーク内のNASやRaspberry Piといった機器へのリモート操作にも幅広く利用されています。
SSHが提供する機能は主に4つに整理できます。1つ目は暗号化通信で、通信内容の盗聴や改ざんを防止します。2つ目は認証機能で、公開鍵認証やパスワード認証によって正規ユーザーのみアクセスを許可します。3つ目はポート転送機能で、ローカルのポートをリモートサーバーへ転送し安全なトンネルを構築できます。4つ目はコマンド実行機能で、リモートサーバー上で直接コマンドを実行し管理作業を効率化できます。
認証方式は大きく分けて2種類あります。パスワード認証はユーザー名とパスワードのみで完結するため設定は数分で終わりますが、総当たり攻撃を受けやすいという弱点があります。一方の公開鍵認証は、秘密鍵と公開鍵という2つの鍵ファイルを組み合わせる方式で、初期設定に10〜15分程度かかるものの、セキュリティレベルは大幅に高まります。実務では公開鍵認証を基本とし、パスワード認証は無効化するのが一般的な運用です。
認証方式を徹底比較
パスワード認証と公開鍵認証、どちらを選ぶべきか迷う方は多いはずです。ここでは実際の運用シーンを想定して両者を比較します。
| 比較項目 | パスワード認証 | 公開鍵認証 |
|---|---|---|
| 設定にかかる時間 | 約1分 | 約10〜15分 |
| 総当たり攻撃への耐性 | 低い | 非常に高い |
| 自動化スクリプトへの適性 | 低い(対話操作が必要) | 高い(パスワードレス実行が可能) |
| 鍵の管理コスト | 不要 | 秘密鍵の保管・ローテーションが必要 |
| 複数サーバーでの使い回し | パスワードの使い回しはリスク大 | 1つの鍵ペアで複数サーバーに対応可能 |
表を見ると分かる通り、初期設定の手間だけを比較すればパスワード認証に軍配が上がりますが、運用フェーズに入るとセキュリティ面・自動化面のどちらでも公開鍵認証が優位です。特に総当たり攻撃は1秒間に数十回から数百回のログイン試行を仕掛けてくるケースが確認されており、パスワードのみでの防御は次第に限界が見えてくるとされています。business用途のサーバーであれば、公開鍵認証を基本方針として設定し、MaxAuthTriesを3回程度に制限しておくと安心です。
接続前の準備手順
SSH接続を始める前に、クライアント側(接続元)とサーバー側(接続先)の環境を整える必要があります。以下の手順に沿って準備を進めてください。
- クライアントにSSHソフトが入っているか確認する(Linux/macOSは標準搭載、Windowsは設定アプリからOpenSSHクライアントを追加)
- ターミナルまたはPowerShellでssh -Vを実行し、バージョンを確認する
- サーバー側にopenssh-serverをインストールする(Debian/Ubuntu系はapt、RHEL/CentOS系はyum、Fedora系はdnfを使用)
- sudo systemctl enable –now sshdでSSHサーバーを起動し、自動起動を有効化する
- sudo systemctl status sshdで稼働状況を確認する(Active: active (running)と表示されればOK)
- ファイアウォールでポート22番(または変更後のポート)を開放する(UFWならsudo ufw allow 22/tcp)
Windows環境の場合は、Windows Terminal+標準OpenSSHクライアント、PuTTY、Git Bashの3種類から選べます。Windows 10のバージョン1809以降とWindows 11ではOpenSSHクライアントが標準搭載されているため、追加インストールなしで利用できるケースがほとんどです。初回接続時にはサーバーのフィンガープリントを確認するプロンプトが表示されるので、内容を確認したうえでyesと入力して続行します。
Linux側では、コマンド一発でインストールが完了する点が扱いやすさに直結します。例えばUbuntu 22.04 LTSではsudo apt update && sudo apt install openssh-serverのコマンドだけで、5秒〜10秒程度でインストールが完了します。インストール後は必ず起動状態を確認し、ポートが開放されているかもあわせてチェックしておくと、後続の接続テストでつまずきにくくなります。
鍵ペアの作り方
公開鍵認証を利用するには、秘密鍵と公開鍵のペアを生成する必要があります。生成にはssh-keygenコマンドを使い、以下の流れで進めます。
- ターミナル(Linux/macOS)またはPowerShell(Windows)を開く
- ssh-keygen -t ed25519 -C “your_email@example.com”を実行する
- 鍵の保存場所を聞かれたらEnterでデフォルト(~/.ssh/id_ed25519)を選択する
- パスフレーズの設定を求められたら、8文字以上の任意の文字列を入力する
- 生成完了後、~/.ssh/id_ed25519(秘密鍵)と~/.ssh/id_ed25519.pub(公開鍵)が作られていることを確認する
古いシステムとの互換性が必要な場合は、ssh-keygen -t rsa -b 4096 -C “your_email@example.com”のようにRSA鍵を4096ビット以上で生成します。鍵の種類ごとの特徴は以下の表の通りです。
| 鍵の種類 | アルゴリズム | 推奨鍵長 | セキュリティレベル | 互換性 |
|---|---|---|---|---|
| ed25519 | EdDSA | 256ビット | 非常に高い | SSH 6.5以降(2014年以降) |
| RSA | RSA | 4096ビット以上 | 高い | 広く普及 |
| ECDSA | Elliptic Curve | 256ビット以上 | 高い | SSH 5.7以降 |
| DSA | DSA | 1024ビット | 低い(非推奨) | 古いシステムのみ |
DSAは鍵長が短く安全性が低いため、新規に選ぶメリットはほぼありません。迷ったらed25519を選び、システムの都合でどうしても対応できない場合のみRSA(4096ビット以上)を検討する、という優先順位で問題ありません。
生成した鍵は保管方法も重要です。~/.sshディレクトリはchmod 700で、秘密鍵ファイルはchmod 600でパーミッションを設定します。秘密鍵はクラウドストレージへのアップロードや他人への共有を避け、外部保管が必要な場合は暗号化したストレージに限定してください。鍵のローテーションは1年に1回程度を目安に行い、古い鍵はサーバーのauthorized_keysから削除して新しい鍵に置き換えます。
公開鍵配布と設定
鍵ペアが生成できたら、公開鍵をサーバーへ配布し、サーバー側の設定ファイルを最適化します。最も手早い方法はssh-copy-idコマンドを使う方法です。
- ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ipを実行する
- サーバーのパスワードを入力し(パスワード認証がまだ有効な状態で1回だけ必要)、公開鍵の配布を完了させる
- ssh-copy-idが使えない環境では、cat ~/.ssh/id_ed25519.pubで公開鍵の内容を表示しコピーする
- サーバー上でmkdir -p ~/.sshとchmod 700 ~/.sshを実行する
- echo “公開鍵の内容” >> ~/.ssh/authorized_keysで追記し、chmod 600 ~/.ssh/authorized_keysでパーミッションを設定する
公開鍵の配布が終わったら、/etc/ssh/sshd_configを編集してサーバー側の挙動を最適化します。編集後はsudo systemctl restart sshdで再起動しないと設定が反映されない点に注意してください。
| 設定項目 | 推奨値 | 説明 |
|---|---|---|
| Port | 2222など任意の番号 | デフォルトの22番から変更し、自動スキャンを回避 |
| PermitRootLogin | no | rootユーザーでの直接ログインを禁止 |
| PasswordAuthentication | no | パスワード認証を無効化し、公開鍵認証のみ許可 |
| PubkeyAuthentication | yes | 公開鍵認証を有効化 |
| ClientAliveInterval | 300 | アイドル状態のクライアントを300秒(5分)で切断 |
| MaxAuthTries | 3 | 認証の試行回数を3回に制限 |
| AllowUsers | 特定のユーザー名 | 接続を許可するユーザーを限定 |
設定が終わったら、ssh -p 2222 user@server_ipのように変更後のポート番号を指定して接続テストを行います。秘密鍵のパスフレーズ入力を求められ、正常にログインできれば設定は完了です。whoami、pwd、ls -lなどのコマンドで接続元の情報を確認しておくと、意図したユーザーでログインできているかを二重にチェックできます。
よくあるエラー対処
SSH接続の設定中や運用中に遭遇しやすいエラーとその対処法を整理しました。エラーメッセージから原因を絞り込み、順番に確認していくと解決までの時間を短縮できます。
Permission denied(publickey)
公開鍵がサーバーのauthorized_keysに正しく登録されていないか、秘密鍵のパーミッションが不適切なケースが大半です。chmod 600 ~/.ssh/id_ed25519でパーミッションを修正し、sshd_configでPubkeyAuthentication yesになっているかを確認したうえで、sudo systemctl restart sshdでサーバーを再起動します。
Connection refused
SSHサーバーが起動していない、ファイアウォールでポートがブロックされている、あるいはポート番号を間違えているケースが考えられます。sudo systemctl status sshdで稼働状況を確認し、停止していればsudo systemctl start sshdで起動します。ポートを2222番などに変更している場合は、sudo ufw allow 2222/tcpで開放を忘れずに行います。
Agent admitted failure to sign
SSHエージェントに秘密鍵が登録されていない状態で発生します。eval “$(ssh-agent -s)”でエージェントを起動し、ssh-add ~/.ssh/id_ed25519で鍵を追加すれば解消します。
Host key verification failed
サーバーの再構築などでホスト鍵が変更された場合に表示されます。ssh-keygen -R server_ipで古い鍵情報をknown_hostsから削除し、再接続時に表示される新しいフィンガープリントを確認したうえで受け入れます。心当たりのない変更であれば、中間者攻撃の可能性も視野に入れてネットワーク経路の安全性を確認してください。
トラブル対応に入る前に、以下のチェックリストで基本項目を洗い出しておくと原因特定が早まります。
- □ ファイアウォールで対象ポートが開放されているか
- □ sshd_configの設定内容と再起動が反映されているか
- □ 公開鍵がauthorized_keysに正しく追記されているか
- □ 秘密鍵のパーミッションがchmod 600になっているか
- □ 接続コマンドのポート番号・ユーザー名・IPアドレスに誤りがないか
セキュリティ強化策
基本設定が完了したあとは、さらに一歩踏み込んだセキュリティ対策を施すことで、不正アクセスのリスクを抑えられます。代表的な対策は3つあります。
1つ目はポート番号の変更です。デフォルトの22番から2222番など任意の番号に変更するだけで、自動スキャンツールによる攻撃対象から外れやすくなります。2つ目はfail2banの導入です。一定回数(例えば5回)以上ログインに失敗したIPアドレスを自動的にブロックする仕組みで、総当たり攻撃を大幅に減らせるといわれています。インストールはsudo apt install fail2banのコマンド1つで完了し、設定ファイル/etc/fail2ban/jail.localでbantimeやmaxretryを調整できます。3つ目は二要素認証の導入です。Google Authenticator PAMモジュールなどを組み合わせることで、秘密鍵に加えてワンタイムパスワードの入力が必要になり、鍵ファイルが漏洩した場合でも侵入を防げる可能性が高まります。
クラウドでの接続設定
AWS・GCP・Azureといった主要クラウドでも、SSH接続の基本は公開鍵認証です。ただしサービスごとに鍵の管理方法やデフォルトユーザー名に違いがあります。
| サービス | デフォルトユーザー例 | 鍵の配布方法 | ポート開放の設定箇所 |
|---|---|---|---|
| AWS EC2 | ec2-user、ubuntuなど | インスタンス作成時にキーペア(.pem)を指定 | セキュリティグループ |
| GCP Compute Engine | OSログイン有効時は自動採番 | メタデータに公開鍵を登録、またはgcloudコマンドで自動配布 | ファイアウォールルール |
| Azure VM | 作成時に指定したユーザー名 | VM作成画面で公開鍵を直接貼り付け | ネットワークセキュリティグループ |
AWSではダウンロードした.pemファイルのパーミッションをchmod 400に設定してから、ssh -i key.pem ec2-user@IPアドレスの形式で接続します。GCPはgcloud compute ssh コマンドを使うと鍵の生成から配布までを自動化でき、初回接続でも数十秒程度で完了します。Azureはポータル画面上で公開鍵の内容を貼り付けるだけで登録が完了するため、CLIに不慣れな方でも扱いやすい設計です。いずれのサービスでも、セキュリティグループやファイアウォールルールでSSHポートを不特定多数に開放しないよう、接続元IPアドレスを絞り込む設定を併用すると安全性が高まります。
よくある質問
Q1. SSH接続でパスワード認証と公開鍵認証、どちらを最初に設定すべきですか?
まずはパスワード認証で1回接続し、その状態でssh-copy-idを使って公開鍵を配布したあとにPasswordAuthentication noへ切り替える流れが安全とされています。いきなり公開鍵認証のみに設定すると、鍵の配布ミスでログインできなくなるリスクがあります。
Q2. 秘密鍵のパスフレーズは必ず設定しないといけませんか?
設定は任意ですが、パスフレーズなしの秘密鍵はファイルが流出した際にそのまま悪用されるリスクがあります。8文字以上のパスフレーズを設定し、ssh-agentと組み合わせて運用する方法が広く採用されています。
Q3. SSHのポート番号は22番のままでも問題ありませんか?
技術的には22番のままでも接続自体は可能ですが、22番は自動スキャンの標的になりやすいポートです。2222番など任意の番号に変更し、ファイアウォールでの開放設定も忘れずに行うと、無差別な接続試行を減らせます。
Q4. 公開鍵認証にしてもログインできない場合、最初に何を確認すればよいですか?
authorized_keysへの公開鍵の登録内容、秘密鍵のパーミッション(chmod 600)、sshd_configのPubkeyAuthentication yes設定の3点を順番に確認すると、原因の8〜9割はここで特定できます。
Q5. クラウドのSSH鍵とオンプレミスサーバーの鍵は使い回してよいですか?
技術的には同じ鍵ペアを複数サーバーで使い回せますが、1台の鍵が流出した際の影響範囲が広がるため、用途や環境ごとに鍵を分ける運用が推奨されています。
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
