SSH接続とは?仕組みや安全な設定手順・Telnetとの違いを徹底解説
クラウド環境の普及やリモートワークの定着に伴い、インフラエンジニアだけでなく、Webエンジニアやデータアナリストにとっても「リモートサーバーへの接続」は日常業務の必須スキルとなっています。その中核を担う技術が「SSH(Secure Shell)」です。
インターネットを経由して遠隔地にあるサーバーを操作する際、通信経路の安全性をどのように確保するのか。なぜ旧来の通信手段では危険なのか。本稿では、SSH接続の基礎概念から暗号化の仕組み、公開鍵認証の具体的な導入手順、接続トラブル時の原因究明法まで、現場のプロが実践する知見を網羅して分かりやすく解説します。
📌 【この記事の重要ポイントまとめ】
- 要点1:SSH(Secure Shell)は、ネットワーク経由でサーバーを遠隔操作する通信をすべて暗号化し、盗聴や改ざんを防ぐ標準プロトコル。
- 要点2:平文でパスワードを流す危険なTelnetとは異なり、公開鍵暗号方式を採用することで極めて高いセキュリティ強度を実現。
- 要点3:運用の現場では従来のパスワード認証から秘密鍵・公開鍵のペア生成による「公開鍵認証」への移行が鉄則。
【基本解説】SSH接続とは何か?安全にサーバーを遠隔操作できる仕組み
SSH(Secure Shell)とは、ネットワークで接続された機器を遠隔操作するための通信プロトコルです。手元のパソコン(クライアント)からデータセンターやクラウド(AWS、GCP、さくらのVPSなど)上にあるLinuxサーバーにログインし、コマンドラインインターフェース(CLI)経由でファイルの編集や設定変更、プログラムの実行を行います。
最大の特徴は、入力したコマンド、返ってくる出力結果、ログイン用パスワードなど、送受信されるすべてのデータを強力に暗号化する点にあります。これにより、途中の公衆回線や社内ネットワークに悪意ある第三者が潜んでパケットを盗聴(スニッフィング)していても、内容を解読されるリスクを極小化できます。
TelnetとSSHの決定的な違い
SSHが登場する以前、遠隔ログインには「Telnet(テルネット)」や「rlogin」が広く使われていました。しかし、Telnetは通信内容を一切暗号化せず「平文(クリアテキスト)」のまま送信する仕様でした。そのため、Wi-Fi環境などでパケットを傍受されると、IDやパスワード、機密情報がそのまま漏洩する重大な脆弱性を抱えていました。
現在、インターネット経由の通信においてTelnetを利用することはセキュリティ上、完全に非推奨とされています。現代のインフラ構築では、暗号化と堅牢な認証機構を備えたSSHの採用が絶対的な業界標準です。
| 比較項目 | SSH(Secure Shell) | Telnet | セキュリティ評価・見解 |
|---|---|---|---|
| 通信の暗号化 | 完全暗号化(AES、ChaCha20等) | 非暗号化(平文テキスト) | SSH一択(Telnetは傍受リスク大) |
| 標準ポート番号 | SSHポート番号 22 | ポート番号 23 | ポート変更による攻撃軽減も有効 |
| 認証方式 | パスワード / 公開鍵暗号 / 多要素 | 平文パスワード認証のみ | 公開鍵認証で総当たり攻撃を完全防御 |
| データ改ざん検知 | MAC(メッセージ認証コード)で検知 | 検知機能なし | 中間者攻撃(MITM)を強力に防止 |

公開鍵暗号方式の仕組みと「パスワード認証」との違い
SSHの認証方式には、大きく分けて「パスワード認証」と「公開鍵認証」の2種類が存在します。
パスワード認証は、手元のPCからユーザー名とパスワードを入力して照合するシンプルな方法です。しかし、どれほど複雑な文字列にしても「総当たり攻撃(ブルートフォースアタック)」や「辞書攻撃」に晒されるリスクが残ります。
そこでエンタープライズ環境や本番サーバーで必須とされるのが、公開鍵暗号方式の仕組みを利用した認証です。この方式では、対となる2つの暗号鍵(「秘密鍵」と「公開鍵」)を使用します。
- 公開鍵(Public Key):サーバー側に事前に登録しておく鍵。一般に公開されても問題ない。
- 秘密鍵(Private Key):クライアント(手元の端末)にのみ厳重に保管する鍵。絶対に他人に渡してはならない。
接続時、サーバーは公開鍵を使ってランダムな暗号化データを生成し、クライアントに送ります。クライアントは手元の秘密鍵を使ってそれを復号・署名して送り返すことで、「本物の秘密鍵の持ち主である」ことを証明します。通信路上に秘密鍵そのものが流れることは一切ないため、強固な安全性が担保されます。
【実践】秘密鍵・公開鍵の生成からSSH接続までの手順
実際に安全なSSH接続環境を構築する流れをステップ形式で解説します。
ステップ1:鍵ペアの作成(ssh-keygen)
端末(macOSのターミナル、WindowsのPowerShellなど)を開き、以下のSSHコマンドを実行して最新の標準暗号アルゴリズム「Ed25519」または「RSA 4096bit」で鍵を生成します。
ssh-keygen -t ed25519 -C "your_email@example.com"実行すると保存場所の確認と、秘密鍵自体を保護するための「パスフレーズ」の入力が求められます。パスフレーズを設定しておくことで、万一手元のPCが盗難に遭った場合でも秘密鍵の不正利用を防げます。
ステップ2:公開鍵をサーバーへ転送・配置
生成された公開鍵(デフォルトでは ~/.ssh/id_ed25519.pub)の内容を、接続先サーバーの ~/.ssh/authorized_keys に追加します。ssh-copy-id コマンドが利用できる環境なら、以下の1行で自動転送が可能です。
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@example.comステップ3:SSHコマンドによる接続とフィンガープリント確認
サーバーに初めて接続する際、ターミナル上にサーバーの「公開鍵フィンガープリント(指紋)」が表示され、接続を続行するか確認(Are you sure you want to continue connecting (yes/no/[fingerprint])?)されます。
ここで管理者が把握している正規のフィンガープリント確認を行い、問題がなければ「yes」と入力します。これにより、クライアント側の ~/.ssh/known_hosts にサーバー情報が記録され、次回以降の中間者攻撃を警戒できるようになります。
ssh -i ~/.ssh/id_ed25519 user@example.com
業務効率を劇的に上げる「ssh_config」の設定とおすすめクライアント
サーバーごとにIPアドレス、ユーザー名、ポート番号、秘密鍵のパスを指定してコマンドを打つのは煩雑です。これを解決するのが ~/.ssh/config ファイルの活用です。
ssh_config 設定方法
手元のPCの ~/.ssh/config に以下のようなエイリアス(別名)設定を記述します。
Host myserver HostName 192.0.2.1 User developer Port 2222 IdentityFile ~/.ssh/id_ed25519この記述を保存するだけで、次回以降は ssh myserver と入力するだけで指定したポートや秘密鍵を用いた一発接続が可能になります。
おすすめのSSHクライアント
- OpenSSH(標準ターミナル / PowerShell):OS標準で動作が最も軽量。CLI主体の操作に最適。
- Tera Term(テラターム):日本の現場で長年親しまれているWindows向け定番ソフト。Tera Term 接続手順はシンプルで、GUIからホスト名・ポートを入力し、秘密鍵ファイル(.pem / .ppk等)を指定して簡単にログインできます。
- VS Code(Remote - SSH拡張機能):開発現場で圧倒的人気。リモートサーバー上のファイルを直接ローカルのエディタ感覚で編集・デバッグ可能です。
【実態検証】「SSH接続ができない」主な原因と現場の解決チェックリスト
現場で「Connection refused」や「Permission denied」のエラーが出て繋がらない場合、原因の大半は限られたポイントに集約されます。トラブル発生時は以下のチェックリストを順に確認してください。
1. ネットワーク・ファイアウォールの遮断(Connection refused / timed out)
- セキュリティグループ・クラウド側のFW:AWSのセキュリティグループやさくらのパケットフィルタで、クライアントのIPアドレスからのインバウンド通信が許可されているか。
- ポート番号の不一致:セキュリティ向上目的でデフォルトの「22番ポート」から変更されている場合、
-p [ポート番号]を指定しているか。
2. パーミッション(権限)設定の不備(Permission denied)
OpenSSHはセキュリティ保護のため、鍵やディレクトリの権限が緩すぎる(他人が読み取れる状態)と接続を自動拒絶します。
- クライアント側の秘密鍵:
chmod 600 ~/.ssh/id_ed25519 - サーバー側の
.sshディレクトリ:chmod 700 ~/.ssh - サーバー側の
authorized_keys:chmod 600 ~/.ssh/authorized_keys
3. サーバー側設定(sshd_config)の制限
サーバー側の /etc/ssh/sshd_config で PasswordAuthentication no(パスワード認証無効)や PermitRootLogin no(root直接ログイン禁止)が有効になっている場合、要件に沿ったユーザーと公開鍵で接続しているか確認が必要です。

一般に知られていない盲点とネットの誤解
インターネット上の古いチュートリアルには、現代のセキュリティ基準に照らすと危険な情報が散見されます。
誤解1:「RSA 2048bitなら今でも安全」
長年使われてきた暗号方式RSAですが、計算能力の向上に伴い2048bitは移行が推奨されるフェーズに入っています。現在新規に鍵を生成する場合は、処理速度が高速で鍵長が短く、耐タンパー性の高いEd25519、またはRSA 4096bitを選択するのがグローバルスタンダードです。
誤解2:「ポート22のままだと即座にハッキングされる」
「22番ポートのまま運用するのは危険だから必ず変更すべき」という言説があります。ポート番号を変更することでBotによる無作為なスキャンログは劇的に削減(ノイズ軽減)できますが、これは「隠蔽によるセキュリティ(Security through obscurity)」に過ぎず、本質的な暗号強度が上がるわけではありません。重要なのは「パスワード認証を無効化し、公開鍵認証+多要素認証を徹底すること」です。
【プロの結論】安全なサーバー運用の判断基準
安全なインフラを維持するためには、「誰が・どの鍵で・いつアクセスしたか」を把握できる状態を作ることが不可欠です。チーム開発で共有の秘密鍵を使い回す行為は厳禁であり、1人1台(または端末ごと)に固有の鍵ペアを発行し、不要になった公開鍵は即座にサーバーから削除する運用規律を徹底してください。
【ssh 接続 と は】に関するよくある質問(FAQ)
Q1:SSH接続はWindowsからでも利用できますか?
A1:はい、利用可能です。現在のWindows 10/11には標準でOpenSSHクライアントが組み込まれており、PowerShellやコマンドプロンプトから直接 ssh コマンドを実行できます。また、GUIでの操作を好む場合はTera TermやPuTTY、VS Codeの利用が一般的です。
Q2:秘密鍵を紛失したり他人に流出させたりした場合はどうすればいいですか?
A2:秘密鍵が流出した可能性がある場合、ただちに接続先サーバーの authorized_keys から対応する「公開鍵」の行を削除してください。公開鍵を削除すれば、流出した秘密鍵を使った不正ログインを即座に無効化できます。その後、新しい鍵ペアを再生成して再設定を行います。
Q3:パスフレーズを忘れてしまった秘密鍵は復旧できますか?
A3:復旧できません。秘密鍵のパスフレーズは強力な暗号で保護されているため、忘れてしまった場合は鍵ペアを再度生成(ssh-keygen)し、サーバー側の公開鍵を登録し直す必要があります。
まとめ:安全なリモート運用の基盤を整えよう
SSHは、現代のネットワーク環境においてサーバーを安全に遠隔操作するためのインフラ基盤です。暗号化されていないTelnetからの脱却はもちろん、単なるパスワード認証から「Ed25519による公開鍵認証」へとステップアップすることで、サーバーの不正アクセス耐性は飛躍的に向上します。
まずは手元の端末で ssh-keygen を実行し、~/.ssh/config を活用した効率的で安全なリモート接続環境を構築してみてください。 (出典: ssh 接続 と は(Yahoo!ニュース))