※本ページにはプロモーション(広告)が含まれています
【2026年最新版】SSHの仕組みと鍵認証の接続設定方法【完全ガイド】
リモートサーバーに接続するとき、「SSHって何?」「鍵認証ってどうやって設定するの?」と悩んだことはありませんか?
特にプログラミングを始めたばかりの方や、初めてVPS(仮想専用サーバー)を契約した方にとって、SSHの仕組みや鍵認証の設定は大きなハードルに感じられるかもしれません。「コマンドを打ってみたけどエラーが出る」「パスワード認証と鍵認証の違いがわからない」という声もよく耳にします。
しかし、SSHの鍵認証は一度正しく設定すれば、パスワード入力なしで安全にサーバーへ接続できる非常に便利な仕組みです。セキュリティ面でもパスワード認証より圧倒的に安全で、GitHubへの接続にも必須の技術です。
この記事では、SSHの基本的な仕組みから鍵ペアの生成方法、サーバーへの接続設定、GitHubでのSSH接続、~/.ssh/configを使った効率的な管理まで、初心者でもわかるようにステップ形式で丁寧に解説します。ぜひ最後まで読んで、SSH鍵認証をマスターしてください。

この記事でわかること
- SSHとは何か?暗号化通信の基本的な仕組み
- パスワード認証と鍵認証の違い(メリット・デメリット比較)
- 公開鍵暗号方式の仕組みをわかりやすく解説
- ssh-keygenコマンドでの鍵ペア生成手順(Ed25519推奨)
- リモートサーバーへのSSH鍵認証接続の設定方法
- GitHubへのSSH接続設定方法
- ~/.ssh/configファイルで複数サーバーを効率管理する方法
- SSH接続のセキュリティ強化テクニック(パスフレーズ・ポート変更など)
- よくあるエラーと解決方法(Permission denied など)
SSHとは?基本の仕組みを理解しよう
SSH(Secure Shell)とは、ネットワークを通じて別のコンピュータに安全に接続するためのプロトコル(通信の約束事)です。主にリモートサーバーの操作やファイル転送に使われています。
SSHが必要な理由
インターネットを通じてサーバーに接続する際、通信内容が暗号化されていないと、第三者に盗み見られる危険があります。SSHが登場する前は「Telnet」というプロトコルが使われていましたが、Telnetは通信内容がすべて平文(暗号化なし)で送受信されるため、パスワードやコマンドが丸見えの状態でした。
SSHはこの問題を解決するために開発されました。SSHを使えば、すべての通信が暗号化されるため、仮に通信を傍受されてもその内容を読み取ることはできません。
SSHでできること
- リモートログイン:自宅のPCからレンタルサーバーやVPSにログインして操作する
- ファイル転送:SCP(Secure Copy)やSFTP(SSH File Transfer Protocol)で安全にファイルを送受信する
- ポートフォワーディング:SSH接続を経由して、通常アクセスできないサービスに安全に接続する
- Git操作:GitHubやGitLabへのプッシュ・プル操作をSSH経由で行う
SSHの暗号化の仕組み(ざっくり解説)
SSHで通信が開始されると、まずクライアント(あなたのPC)とサーバーの間で「セッション鍵」と呼ばれる一時的な暗号鍵が作成されます。この鍵を使って、以降のすべての通信データが暗号化されます。
この暗号鍵の生成には「鍵交換アルゴリズム」(Diffie-Hellman鍵交換など)が使われ、鍵自体がネットワーク上を流れることなく、安全に共有される仕組みになっています。
| 項目 | Telnet | SSH |
|---|---|---|
| 通信の暗号化 | なし(平文) | あり(AES等で暗号化) |
| パスワードの安全性 | 盗み見られる危険あり | 暗号化されて安全 |
| 鍵認証 | 非対応 | 対応 |
| ポートフォワーディング | 非対応 | 対応 |
| 現在の利用状況 | 非推奨(廃止傾向) | 標準的に利用 |
パスワード認証と鍵認証の違い
SSHでサーバーに接続する方法は大きく分けて2つあります。パスワード認証と鍵認証(公開鍵認証)です。それぞれの特徴と違いを詳しく見ていきましょう。
パスワード認証とは
パスワード認証は、接続のたびにユーザー名とパスワードを入力してログインする方式です。最もシンプルでわかりやすい方法ですが、セキュリティ面ではいくつかの弱点があります。
- パスワードが推測されやすい場合、ブルートフォース攻撃(総当たり攻撃)で突破される危険がある
- 毎回パスワードを入力する手間がかかる
- 自動化スクリプトにパスワードを埋め込むのはセキュリティリスクが高い
鍵認証(公開鍵認証)とは
鍵認証は、「公開鍵」と「秘密鍵」のペアを使ってログインする方式です。パスワードを送信する代わりに、数学的な仕組みを使って本人確認を行います。
鍵認証の最大のメリットは、パスワードがネットワーク上を流れないため、盗聴されてもログイン情報が漏れないという点です。
| 比較項目 | パスワード認証 | 鍵認証(公開鍵認証) |
|---|---|---|
| セキュリティ | △ ブルートフォース攻撃のリスクあり | ◎ 秘密鍵がなければ認証不可 |
| 利便性 | △ 毎回パスワード入力が必要 | ◎ パスワード入力不要(パスフレーズ設定時を除く) |
| 初期設定の手間 | ◎ 設定不要ですぐ使える | △ 鍵生成・配置の初期設定が必要 |
| 自動化との相性 | × パスワード埋め込みはリスク大 | ◎ スクリプトからの自動接続に最適 |
| ブルートフォース耐性 | × 短いパスワードは危険 | ◎ 鍵の推測は実質不可能 |
| 推奨度 | 初心者の一時的な利用向け | すべての環境で推奨 |
結論として、SSH接続では鍵認証を使うことが強く推奨されます。この記事では、鍵認証の設定方法を中心に詳しく解説していきます。
公開鍵暗号方式の仕組み
鍵認証を正しく理解するために、公開鍵暗号方式の仕組みを知っておきましょう。難しそうに聞こえるかもしれませんが、基本的な考え方はシンプルです。
「公開鍵」と「秘密鍵」の関係
公開鍵暗号方式では、2つの鍵(キーペア)を使います。
- 公開鍵(Public Key):誰に見られてもOK。サーバー側に設置する鍵
- 秘密鍵(Private Key):絶対に他人に見せてはいけない。あなたのPC内に厳重に保管する鍵
この2つの鍵は数学的に対になっており、公開鍵で暗号化したデータは、対応する秘密鍵でしか復号できません。逆に、秘密鍵で署名(サイン)したデータは、対応する公開鍵で検証できます。
SSH鍵認証の流れ(わかりやすく解説)
SSH鍵認証でサーバーに接続する際、実際には以下のようなやりとりが行われています。
ステップ1:あなたのPCがサーバーに「接続したい」とリクエストを送る
ステップ2:サーバーは登録されている公開鍵を使って、ランダムなデータ(チャレンジ)を暗号化し、あなたのPCに送る
ステップ3:あなたのPCは秘密鍵を使ってチャレンジを復号し、正しい答えをサーバーに返す
ステップ4:サーバーは答えが正しいことを確認し、接続を許可する
このプロセスでは、秘密鍵の情報がネットワーク上を一切流れません。秘密鍵はあなたのPC内で復号処理に使われるだけです。これがパスワード認証よりも安全な理由です。

鍵のたとえ話:南京錠と鍵
公開鍵暗号を日常生活でたとえると、次のようなイメージです。
- 公開鍵 = 開いた南京錠:相手に渡して「この錠前で箱を閉じてね」と言える。誰にあげてもOK
- 秘密鍵 = 南京錠を開ける鍵:自分だけが持っている。この鍵がないと箱は開けられない
サーバーに公開鍵(南京錠)を置いておき、サーバーはその南京錠で暗号化したチャレンジを送ってきます。あなたは秘密鍵(鍵)でそれを開けて、正しい答えを返す。これがSSH鍵認証の本質です。
鍵の種類と選び方(Ed25519を推奨)
SSHの鍵にはいくつかの種類(アルゴリズム)があります。2026年現在、Ed25519が最もおすすめです。
| アルゴリズム | 鍵長 | セキュリティ | 速度 | 推奨度 |
|---|---|---|---|---|
| Ed25519 | 256ビット | ◎ 非常に高い | ◎ 高速 | ◎ 最推奨 |
| RSA | 2048〜4096ビット | ○ 高い(4096bit推奨) | △ やや遅い | ○ 互換性重視なら |
| ECDSA | 256〜521ビット | ○ 高い | ○ 速い | △ Ed25519で十分 |
| DSA | 1024ビット | × 脆弱 | ○ 速い | × 使用禁止 |
Ed25519を推奨する理由
- 短い鍵長で高いセキュリティ:256ビットでRSA 3072ビット相当のセキュリティ
- 処理が高速:鍵の生成・認証ともに高速
- 鍵のサイズがコンパクト:公開鍵が1行で収まる
- サイドチャネル攻撃に強い:実装上の脆弱性が少ない設計
- 主要サービスがすべて対応:GitHub、GitLab、AWS、Azure、GCPなど
特別な理由がない限り、Ed25519を選んでおけば間違いありません。古いサーバーでEd25519が使えない場合のみ、RSA 4096ビットを選択しましょう。
SSH鍵ペアの生成方法(ステップ形式)
ここからは実際にSSH鍵ペアを生成する手順を解説します。Windows・Mac・Linuxそれぞれの環境で実行できます。
事前準備:ターミナル(コマンドラインツール)を開く
| OS | ターミナルの開き方 |
|---|---|
| Windows 10/11 | スタートメニューで「PowerShell」を検索して開く。またはWindows Terminal を使用 |
| Mac | 「アプリケーション」→「ユーティリティ」→「ターミナル」を開く |
| Linux | Ctrl + Alt + T でターミナルを起動 |
ステップ1:ssh-keygenコマンドで鍵を生成する
ターミナルに以下のコマンドを入力してEnterキーを押します。
ssh-keygen -t ed25519 -C "your_email@example.com"
各オプションの意味:
-t ed25519:鍵の種類(アルゴリズム)をEd25519に指定-C "your_email@example.com":コメント(メールアドレスを入れておくと鍵の識別に便利)
※ your_email@example.com の部分は、ご自身のメールアドレスに置き換えてください。
ステップ2:鍵の保存場所を指定する
コマンドを実行すると、以下のようなメッセージが表示されます。
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/username/.ssh/id_ed25519):
特に変更する必要がなければ、そのままEnterキーを押してください。デフォルトの保存場所(~/.ssh/id_ed25519)に保存されます。
もし複数の鍵を使い分けたい場合は、別の名前を指定できます。例えば:
/Users/username/.ssh/id_ed25519_github
ステップ3:パスフレーズを設定する
次に、パスフレーズの入力を求められます。
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
パスフレーズは強く推奨します。パスフレーズとは、秘密鍵を使用するたびに入力するパスワードのようなものです。万が一、秘密鍵ファイルが流出しても、パスフレーズがなければ使えません。
パスフレーズのポイント:
- 10文字以上を推奨(英字・数字・記号を混ぜると強い)
- 覚えやすい文章(フレーズ)にするのがおすすめ(例:
MyS3cureK3y!2026) - 毎回入力が面倒な場合は ssh-agent を使うと省略できる(後述)
ステップ4:生成完了の確認
パスフレーズの入力が完了すると、以下のようなメッセージが表示されます。
Your identification has been saved in /Users/username/.ssh/id_ed25519
Your public key has been saved in /Users/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
| .o=+. |
| . o+o. |
| o..+. |
| . .= . |
| . oS.o . |
| +.o+ o |
| ..oo.= . |
| .+.+= o |
| .oE=++ |
+----[SHA256]------+
これで鍵ペアの生成が完了しました。以下の2つのファイルが作成されています。
~/.ssh/id_ed25519:秘密鍵(絶対に他人に共有しない!)~/.ssh/id_ed25519.pub:公開鍵(サーバーに配置するファイル)
ステップ5:生成された鍵を確認する
公開鍵の内容を表示するには、以下のコマンドを実行します。
cat ~/.ssh/id_ed25519.pub
以下のような1行のテキストが表示されます。
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG... your_email@example.com
このテキストが「公開鍵」です。サーバーに設置する際にこれをコピーして使います。
リモートサーバーへのSSH鍵認証接続を設定する
鍵ペアが生成できたら、次はサーバー側に公開鍵を配置して、鍵認証で接続できるようにしましょう。
方法1:ssh-copy-idコマンドを使う(推奨・最も簡単)
ssh-copy-idコマンドを使えば、公開鍵をサーバーに自動でコピーできます。
ステップ1:以下のコマンドを実行します。
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip
username:サーバーのユーザー名server_ip:サーバーのIPアドレスまたはホスト名
ステップ2:パスワードの入力を求められるので、サーバーのパスワードを入力します(これが最後のパスワード入力です)。
ステップ3:成功すると以下のメッセージが表示されます。
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip'"
and check to make sure that only the key(s) you wanted were added.
ステップ4:鍵認証で接続できるかテストします。
ssh username@server_ip
パスワードを聞かれずにログインできれば成功です!(パスフレーズを設定した場合はパスフレーズの入力が求められます。)
方法2:手動で公開鍵を設置する
ssh-copy-idが使えない環境(Windowsなど)では、手動で公開鍵を配置します。
ステップ1:公開鍵の内容をコピーします。
cat ~/.ssh/id_ed25519.pub
表示されたテキストをすべてコピーしてください。
ステップ2:サーバーにパスワード認証でログインします。
ssh username@server_ip
ステップ3:サーバー上で以下のコマンドを順番に実行します。
# .sshディレクトリがなければ作成
mkdir -p ~/.ssh
# パーミッションを設定
chmod 700 ~/.ssh
# 公開鍵をauthorized_keysファイルに追記
echo "ここに公開鍵のテキストを貼り付ける" >> ~/.ssh/authorized_keys
# パーミッションを設定
chmod 600 ~/.ssh/authorized_keys
重要:パーミッション(権限設定)が正しくないと鍵認証が動作しません。以下の設定を必ず守ってください。
| 対象 | パーミッション | コマンド |
|---|---|---|
| ~/.ssh/ ディレクトリ | 700(所有者のみ読み書き実行) | chmod 700 ~/.ssh |
| ~/.ssh/authorized_keys | 600(所有者のみ読み書き) | chmod 600 ~/.ssh/authorized_keys |
| 秘密鍵ファイル(ローカル) | 600(所有者のみ読み書き) | chmod 600 ~/.ssh/id_ed25519 |
| 公開鍵ファイル(ローカル) | 644(所有者が読み書き、他は読み取りのみ) | chmod 644 ~/.ssh/id_ed25519.pub |
GitHubへのSSH接続を設定する
GitHubでコードをプッシュ・プルする際にも、SSH接続は非常に便利です。HTTPS接続ではトークンの管理が面倒ですが、SSH接続なら一度設定すればスムーズに操作できます。
ステップ1:SSH鍵がまだなければ生成する
先ほどの手順で鍵を生成済みであれば、そのまま使えます。GitHub専用の鍵を作りたい場合は以下のようにファイル名を変えて生成します。
ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_github
ステップ2:公開鍵をクリップボードにコピーする
| OS | コマンド |
|---|---|
| Mac | pbcopy < ~/.ssh/id_ed25519.pub |
| Windows(PowerShell) | Get-Content ~/.ssh/id_ed25519.pub | Set-Clipboard |
| Linux(xclip導入済み) | xclip -selection clipboard < ~/.ssh/id_ed25519.pub |
ステップ3:GitHubに公開鍵を登録する
- GitHubにログインする
- 右上のプロフィールアイコンをクリック →「Settings」を選択
- 左メニューの「SSH and GPG keys」をクリック
- 「New SSH key」ボタンをクリック
- 以下の情報を入力する:
- Title:わかりやすい名前(例:「My MacBook Pro 2026」)
- Key type:「Authentication Key」を選択
- Key:先ほどコピーした公開鍵をペースト
- 「Add SSH key」をクリック
- GitHubのパスワードの確認が求められたら入力する
ステップ4:接続テストを実施する
以下のコマンドでGitHubへのSSH接続をテストします。
ssh -T git@github.com
初回接続時は以下のような確認メッセージが表示されます。
The authenticity of host 'github.com (20.27.177.113)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes と入力してEnterキーを押すと、以下のメッセージが表示されれば成功です。
Hi username! You've been authenticated, but GitHub does not provide shell access.
ステップ5:既存リポジトリのURLをSSHに変更する(任意)
すでにHTTPSでクローンしたリポジトリがある場合、SSH接続に切り替えることができます。
# 現在のリモートURLを確認
git remote -v
# SSHのURLに変更
git remote set-url origin git@github.com:username/repository.git

~/.ssh/configで複数サーバーを効率的に管理する
複数のサーバーやGitHubアカウントに接続する場合、~/.ssh/configファイルを設定すると、接続がとても楽になります。
configファイルとは
~/.ssh/configは、SSH接続の設定を事前に記述しておくファイルです。これを使うと、長いコマンドを毎回打つ代わりに、短いホスト名だけで接続できるようになります。
例えば、以下のような長いコマンド:
ssh -i ~/.ssh/id_ed25519_myserver -p 2222 admin@192.168.1.100
を、configファイルの設定後は:
ssh myserver
と入力するだけで接続できます。
configファイルの作成方法
ステップ1:configファイルを作成(存在しない場合)
touch ~/.ssh/config
chmod 600 ~/.ssh/config
ステップ2:テキストエディタで開いて設定を記述
# テキストエディタで開く(nanoの場合)
nano ~/.ssh/config
configファイルの書き方(基本構文)
# === 基本的な設定例 ===
# VPSサーバー
Host myserver
HostName 192.168.1.100
User admin
Port 2222
IdentityFile ~/.ssh/id_ed25519_myserver
IdentitiesOnly yes
# 本番サーバー
Host production
HostName example.com
User deploy
Port 22
IdentityFile ~/.ssh/id_ed25519_production
IdentitiesOnly yes
# GitHub(個人アカウント)
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
IdentitiesOnly yes
# GitHub(仕事用アカウント)
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
IdentitiesOnly yes
各項目の意味
| 項目 | 説明 | 例 |
|---|---|---|
| Host | 接続時に使うエイリアス(好きな名前) | myserver |
| HostName | 実際のIPアドレスまたはドメイン名 | 192.168.1.100 |
| User | ログインするユーザー名 | admin |
| Port | SSHのポート番号(デフォルトは22) | 2222 |
| IdentityFile | 使用する秘密鍵のパス | ~/.ssh/id_ed25519_myserver |
| IdentitiesOnly | 指定した鍵のみ使用する(yes推奨) | yes |
便利なワイルドカード設定
すべてのホストに共通する設定は、Host * で一括指定できます。
# すべての接続に共通する設定
Host *
AddKeysToAgent yes
ServerAliveInterval 60
ServerAliveCountMax 3
TCPKeepAlive yes
AddKeysToAgent yes:ssh-agentに自動で鍵を追加ServerAliveInterval 60:60秒ごとに接続維持のための信号を送信ServerAliveCountMax 3:3回応答がなければ切断TCPKeepAlive yes:TCP接続を維持
これにより、SSH接続が無操作で切断される問題を防ぐことができます。
ssh-agentでパスフレーズ入力を省略する
パスフレーズを設定した鍵を使っていると、接続のたびにパスフレーズの入力を求められます。ssh-agentを使えば、パスフレーズを一度入力するだけで、以降の接続ではパスフレーズの入力を省略できます。
ssh-agentの起動と鍵の登録
Mac・Linuxの場合:
# ssh-agentをバックグラウンドで起動
eval "$(ssh-agent -s)"
# 秘密鍵を登録(パスフレーズの入力が求められる)
ssh-add ~/.ssh/id_ed25519
Macの場合(Keychainとの連携):
macOSではKeychainと連携できるため、再起動後も鍵が自動で読み込まれます。~/.ssh/configに以下を追記してください。
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519
Windowsの場合(OpenSSH Agent):
Windows 10/11にはOpenSSH Agentが標準搭載されています。PowerShellを管理者として開き、以下を実行します。
# OpenSSH Agentサービスを自動起動に設定
Set-Service ssh-agent -StartupType Automatic
# サービスを起動
Start-Service ssh-agent
# 鍵を登録
ssh-add ~\.ssh\id_ed25519
登録されている鍵の確認
ssh-add -l
登録されている鍵のフィンガープリント(指紋)が表示されます。
SSHのセキュリティ強化テクニック
SSH鍵認証を設定したら、さらにセキュリティを強化する設定を行いましょう。特に公開サーバー(インターネットからアクセスできるサーバー)を運用している場合、これらの設定は必須です。
対策1:パスワード認証を無効化する
鍵認証が正常に動作することを確認したら、パスワード認証を無効化しましょう。これにより、ブルートフォース攻撃を完全に防げます。
サーバー側の設定(/etc/ssh/sshd_config):
# パスワード認証を無効化
PasswordAuthentication no
# チャレンジレスポンス認証も無効化
ChallengeResponseAuthentication no
# 公開鍵認証を有効化(通常はデフォルトでyes)
PubkeyAuthentication yes
設定変更後、SSHサービスを再起動します。
sudo systemctl restart sshd
注意:パスワード認証を無効化する前に、必ず鍵認証でログインできることを確認してください。鍵認証が動かない状態でパスワード認証を無効化すると、サーバーにログインできなくなります。
対策2:SSHのポート番号を変更する
SSHのデフォルトポートは22番です。攻撃者は22番ポートを狙って自動的にスキャンするため、ポートを変更するだけで攻撃を受ける回数を大幅に減らせます。
# /etc/ssh/sshd_config
Port 2222
ポート番号は1024〜65535の範囲で、他のサービスと重複しない番号を選びましょう。変更後はSSHサービスを再起動し、ファイアウォールで新しいポートを開放することを忘れないでください。
# ファイアウォール設定例(ufw)
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
対策3:rootログインを禁止する
root(管理者)アカウントへの直接SSHログインを禁止し、一般ユーザーでログインしてからsudoで管理者権限を使う運用にしましょう。
# /etc/ssh/sshd_config
PermitRootLogin no
対策4:接続元IPアドレスを制限する
特定のIPアドレスからのみSSH接続を許可することで、不正アクセスのリスクを最小限にできます。
# /etc/ssh/sshd_config
AllowUsers admin@192.168.1.0/24
対策5:ログイン試行回数を制限する
# /etc/ssh/sshd_config
MaxAuthTries 3
LoginGraceTime 30
MaxAuthTries 3:認証を3回失敗したら切断LoginGraceTime 30:30秒以内にログインしなければ切断
対策6:Fail2Banで不正アクセスを自動ブロック
Fail2Banは、ログイン失敗が一定回数を超えたIPアドレスを自動的にブロックするツールです。
# インストール(Ubuntu/Debian)
sudo apt install fail2ban
# 設定ファイルを作成
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
/etc/fail2ban/jail.localに以下を追記します。
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600
maxretry = 5:5回失敗でブロックbantime = 3600:1時間ブロックfindtime = 600:10分間で5回失敗したらブロック
セキュリティ設定のまとめ
| 対策 | 効果 | 難易度 | 優先度 |
|---|---|---|---|
| 鍵認証の導入 | ブルートフォース攻撃を防止 | ★★☆ | 必須 |
| パスワード認証の無効化 | パスワード攻撃を完全遮断 | ★☆☆ | 必須 |
| ポート番号の変更 | 自動スキャン攻撃を回避 | ★☆☆ | 推奨 |
| rootログイン禁止 | 権限昇格攻撃を防止 | ★☆☆ | 必須 |
| IP制限 | 接続元を限定し不正アクセスを防止 | ★★☆ | 推奨 |
| Fail2Ban導入 | ブルートフォースを自動ブロック | ★★☆ | 推奨 |
よくあるSSH接続エラーと解決方法
SSH接続を設定する際にエラーが出ることがあります。ここでは、よく遭遇するエラーとその解決方法を紹介します。
エラー1:Permission denied (publickey)
表示されるメッセージ:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
原因と対処法:
- 原因1:サーバーに公開鍵が正しく設置されていない →
authorized_keysファイルの内容を確認する - 原因2:パーミッションが正しくない →
chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keysを実行 - 原因3:間違った秘密鍵を使っている →
ssh -v(詳細モード)で使用されている鍵を確認
デバッグ方法:以下のコマンドで詳細なログを確認できます。
ssh -vvv username@server_ip
-vvvは最も詳細なデバッグレベルで、認証の各ステップが表示されます。
エラー2:Connection refused
表示されるメッセージ:
ssh: connect to host 192.168.1.100 port 22: Connection refused
原因と対処法:
- SSHサーバー(sshd)が起動していない →
sudo systemctl start sshdで起動 - ファイアウォールでSSHポートがブロックされている → ファイアウォールのルールを確認
- ポート番号が変更されている → 正しいポート番号を
-pオプションで指定
エラー3:WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
表示されるメッセージ:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
原因:サーバーのホスト鍵が以前の接続時と異なっています。サーバーを再インストールした場合などに表示されます。
対処法:サーバーが正規のものであることを確認した上で、以下のコマンドで古いホスト鍵を削除します。
ssh-keygen -R server_ip
注意:身に覚えのないホスト鍵の変更は、中間者攻撃(MITM攻撃)の可能性があります。安易に鍵を削除せず、サーバー管理者に確認してください。
エラー4:WARNING: UNPROTECTED PRIVATE KEY FILE!
表示されるメッセージ:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
原因:秘密鍵ファイルのパーミッションが緩すぎます。
対処法:
chmod 600 ~/.ssh/id_ed25519
エラー5:Connection timed out
原因と対処法:
- ネットワーク接続に問題がある →
ping server_ipで疎通確認 - サーバーがダウンしている → サーバーの管理画面で状態を確認
- ファイアウォールでブロックされている → セキュリティグループやiptablesを確認
実践的な活用例
活用例1:SCPでファイルを安全に転送する
# ローカルからサーバーへファイルを送る
scp localfile.txt username@server_ip:/home/username/
# サーバーからローカルへファイルを取得する
scp username@server_ip:/home/username/remotefile.txt ./
# ディレクトリごと転送する
scp -r ./myproject username@server_ip:/home/username/
活用例2:ポートフォワーディングでローカルからリモートサービスにアクセス
# ローカルの8080ポートをリモートの80ポートに転送
ssh -L 8080:localhost:80 username@server_ip
これにより、ブラウザでhttp://localhost:8080を開くと、リモートサーバーの80番ポートのサービスにアクセスできます。データベースの管理画面など、外部に公開していないサービスに安全にアクセスする際に便利です。
活用例3:複数のGitHubアカウントを使い分ける
個人用と仕事用でGitHubアカウントが異なる場合、~/.ssh/configで使い分けられます。
# ~/.ssh/config
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
IdentitiesOnly yes
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
IdentitiesOnly yes
リポジトリのクローン時にホスト名を使い分けます。
# 個人アカウントのリポジトリ
git clone git@github-personal:personal-user/repo.git
# 仕事用アカウントのリポジトリ
git clone git@github-work:work-user/repo.git
よくある質問(FAQ)
Q1. SSH鍵を紛失した場合はどうすればよいですか?
秘密鍵を紛失した場合は、新しい鍵ペアを生成し直す必要があります。古い公開鍵をサーバーのauthorized_keysから削除し、新しい公開鍵を登録してください。パスワード認証が有効であれば、パスワードでログインして鍵を入れ替えられます。パスワード認証も無効の場合は、サーバーのコンソール(管理画面)から直接操作する必要があります。
Q2. 秘密鍵が漏洩した可能性がある場合はどうすべきですか?
即座に以下の対応を行ってください。
- 漏洩した可能性のある公開鍵をすべてのサーバー・サービスから削除する
- 新しい鍵ペアを生成する
- 新しい公開鍵を各サーバー・サービスに再登録する
- サーバーのログを確認し、不正アクセスがなかったかチェックする
パスフレーズを設定していれば、秘密鍵ファイルが流出しても即座に悪用されるリスクは低減されます。
Q3. Ed25519に対応していない古いサーバーではどうすればよいですか?
Ed25519に対応していない場合は、RSA 4096ビットを使用してください。
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
RSA 2048ビットでも現時点では十分なセキュリティがありますが、将来性を考えて4096ビットを推奨します。
Q4. Windows環境でSSHを使うにはどうすればよいですか?
Windows 10以降であれば、OpenSSHクライアントが標準搭載されています。PowerShellまたはWindows Terminalからそのままsshコマンドを使えます。インストールされていない場合は、「設定」→「アプリ」→「オプション機能」→「OpenSSHクライアント」で追加できます。
Q5. パスフレーズを後から変更できますか?
はい、以下のコマンドで既存の鍵のパスフレーズを変更できます。
ssh-keygen -p -f ~/.ssh/id_ed25519
現在のパスフレーズを入力した後、新しいパスフレーズを設定できます。鍵自体は変更されないため、サーバー側の設定を変更する必要はありません。
Q6. 1つの鍵を複数のサーバーで使い回してもよいですか?
技術的には可能ですが、セキュリティ上はサーバーごとに異なる鍵を使うことを推奨します。1つの鍵が漏洩した場合、その鍵でアクセスできるすべてのサーバーが危険にさらされるためです。~/.ssh/configで鍵を使い分ける設定をすれば、管理の手間もさほどかかりません。
Q7. SSH接続が頻繁に切断される場合はどうすればよいですか?
~/.ssh/configに以下の設定を追加することで、接続を維持できます。
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
これにより、60秒ごとにキープアライブ信号が送信され、無操作による切断を防げます。
Q8. GitHubに複数の公開鍵を登録できますか?
はい、GitHubには複数のSSH鍵を登録できます。自宅のPC、会社のPC、ノートPCなど、デバイスごとに異なる鍵を登録するのが一般的です。不要になった鍵はGitHubの設定画面から削除してください。
Q9. ssh-agentとは何ですか?必ず使う必要がありますか?
ssh-agentは、秘密鍵のパスフレーズをメモリ上にキャッシュしてくれるプログラムです。パスフレーズを設定している場合に、接続のたびに入力する手間を省けます。パスフレーズを設定していない場合は不要ですが、セキュリティの観点からパスフレーズ+ssh-agentの組み合わせがベストプラクティスです。
Q10. SSH鍵認証とHTTPS認証(トークン認証)はどちらがよいですか?
用途によりますが、日常的な開発作業にはSSH鍵認証がおすすめです。一度設定すればトークンの更新や管理が不要で、複数サービスとの接続も~/.ssh/configで一元管理できます。CI/CDパイプラインなど、サーバー間の自動連携にはトークン認証が便利な場合もあります。
まとめ
この記事では、SSHの基本的な仕組みから鍵認証の設定方法、セキュリティ強化まで幅広く解説しました。最後に重要なポイントを振り返りましょう。
| ポイント | 内容 |
|---|---|
| SSHとは | 暗号化された安全なリモート接続プロトコル |
| 鍵認証の仕組み | 公開鍵と秘密鍵のペアで本人確認(パスワード不要) |
| 推奨アルゴリズム | Ed25519(高速・安全・コンパクト) |
| 鍵の生成 | ssh-keygen -t ed25519 で生成 |
| サーバー設定 | 公開鍵を ~/.ssh/authorized_keys に配置 |
| 便利な管理 | ~/.ssh/config で接続先を一元管理 |
| セキュリティ強化 | パスワード認証無効化・ポート変更・rootログイン禁止 |
SSH鍵認証は、最初の設定さえ乗り越えれば、日々の作業を安全かつ快適にしてくれる強力なツールです。まだ設定していない方は、ぜひこの記事を参考にして、今日から鍵認証を導入してみてください。
設定でつまずいた場合は、ssh -vvvコマンドで詳細ログを確認することで、多くの問題を特定できます。わからないことがあれば、この記事のFAQやエラー解決セクションも参考にしてください。
minto.tech スマホ(Android/iPhone)・PC(Mac/Windows)の便利情報をお届け! 月間アクセス160万PV!スマートフォン、タブレット、パソコン、地デジに関する素朴な疑問や、困ったこと、ノウハウ、コツなどが満載のお助け記事サイトはこちら!