SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで実装者向けに解説

SSH（Secure Shell）は、離れた場所にあるサーバーへログインしてコマンド操作やファイル転送を行うためのプロトコルで、通信経路をまるごと暗号化して盗聴と改ざんを防ぎます。既定ではTCPの22番ポートを使い、サーバー側のsshdというデーモンと、手元のsshクライアントがやり取りします。認証にはパスワード認証と公開鍵認証があり、本番運用では鍵ペアを使う公開鍵認証が標準です。本記事では、SSH接続の仕組みと鍵交換の流れ、TCP22番ポートとsshd・sshクライアントの役割、公開鍵認証の設定手順、sshd_configによる安全化の要点、そしてSSHを直接運用すべき条件と、マネージドや踏み台に寄せるべき見送り場面までを実装者の視点で整理します。

まとめ：SSH接続とは何かと安全に運用するための要点

SSH接続とは、暗号化された通信路の上で遠隔のサーバーを操作する仕組みです。接続時にクライアントとサーバーが鍵交換でセッション鍵を共有し、以降のコマンドや応答はすべて暗号化されて流れます。同じ暗号でも、SSLやTLSがWebサイトの通信を守るのに対し、SSHはサーバーへの遠隔ログインとファイル転送を守るという役割の違いがあります。

安全に運用する要点は3つに絞れます。第一に、総当たり攻撃に弱いパスワード認証を無効化し、鍵ペアによる公開鍵認証へ寄せること。第二に、rootでの直接ログインを禁止し、必要ならポート番号や接続元を絞ってsshdの露出を減らすこと。第三に、OpenSSHのバージョンを追い、廃止された弱い暗号方式を使い続けないこと。加えて、鍵が増えて棚卸しが回らなくなる規模では、SSHを素で公開し続けず踏み台やマネージド接続へ寄せる判断も要ります。各章で、設定と判断の基準を条件付きに示します。

SSH接続とは何かと暗号化で遠隔操作を守るプロトコルの基本構造

まず押さえるべきは、SSHが「暗号化された通信路の上で遠隔のシェルを操作する」ためのプロトコルだという点です。ここでは、何を守るのか、どう暗号化するのか、どのポートで何と何がやり取りするのかを順に整理します。

遠隔操作の通信を暗号化して盗聴と改ざんから守るSSHの位置づけ

SSHが登場する前に使われていたTelnetやrloginは、ログインのパスワードもコマンドも平文でネットワークに流していました。経路のどこかで盗聴されれば認証情報がそのまま漏れる構造です。SSHはこの弱点を、通信全体の暗号化と接続先サーバーの正当性確認で解決しました。現在広く使われているのはプロトコルとしてはSSH-2で、脆弱性が指摘された初期のSSH-1は既定で無効化されました。用途は遠隔ログインだけでなく、SCPやSFTPによるファイル転送、ポートフォワーディング（トンネリング）による別サービスの中継まで及びます。つまりSSHは「安全な遠隔操作の土台」であり、サーバー運用のほぼ全工程がこの上で動きます。

鍵交換とセッション鍵の生成で通信路を暗号化するハンドシェイクの流れ

SSHの暗号化は、接続の最初に行うハンドシェイクで組み上がります。ポイントは、公開鍵暗号で「共通のセッション鍵」を安全に共有し、実際の通信はその共通鍵による対称暗号で高速に暗号化する、という二段構えです。おおまかな流れは次のとおりです。

1. クライアントがサーバーの22番ポートへTCP接続を張る
2. 両者がプロトコルバージョンと使用する暗号アルゴリズムを擦り合わせる
3. Diffie-Hellman鍵交換で、盗聴されても復元できない形でセッション鍵を共有する
4. サーバーのホスト鍵で接続先の正当性を検証し、クライアントのknown_hostsと照合する
5. ユーザー認証（公開鍵またはパスワード）を行う
6. 以降のコマンドと応答をセッション鍵で暗号化して対話する

4番目のホスト鍵照合が中間者攻撃への歯止めです。初回接続でフィンガープリントの確認を求められ、2回目以降にホスト鍵が変わっていれば警告が出ます。この警告を安易に無視して上書きすると、なりすましサーバーへ接続してしまう入口になります。

デフォルトのTCP22番ポートとsshd・sshクライアントの役割分担

SSHはクライアント・サーバー型で動きます。接続を待ち受ける側がサーバーで、その常駐プロセスがsshd（SSHデーモン）です。接続しにいく側がクライアントで、ssh user@hostのように相手とユーザーを指定して呼び出します。待ち受けポートは既定でTCPの22番、いわゆるウェルノウンポートです。sshdは設定ファイルsshd_config（/etc/ssh/ に置かれます）で挙動が決まり、どのポートで待つか、どの認証方式を許すか、rootのログインを許すかをここで制御します。ファイル転送のscpやsftp、鍵を生成するssh-keygenも同じOpenSSHの一式に含まれ、これらが揃って「SSHで運用する」環境になります。

パスワード認証と公開鍵認証で分かれるSSHの認証方式と実装手順

「ssh 公開鍵認証」とよく検索されるとおり、SSHの認証には性質の異なる2方式があります。どちらを使うかで、サーバーの安全性は大きく変わります。

総当たり攻撃に弱いパスワード認証と鍵ペアで守る公開鍵認証の違い

パスワード認証は、ユーザー名とパスワードを送って照合する素朴な方式です。設定は手軽ですが、22番ポートを公開したサーバーには世界中から総当たりのログイン試行が飛んでくるため、弱いパスワードだと突破されます。公開鍵認証は、手元で生成した秘密鍵と、サーバーに預けた公開鍵のペアで認証します。秘密鍵はネットワークに流れず、サーバーは公開鍵で作った暗号文を秘密鍵で復号できるかどうかだけを確認するため、総当たりが実質的に効きません。両者の性質を整理します。

本番サーバーでは、パスワード認証を止めて公開鍵認証だけに寄せるのが実務の定石です。手軽さと引き換えに攻撃面を広げるパスワード認証を、公開されたサーバーで有効なまま放置しない、という一線を最初に引きます。

ssh-keygenでの鍵生成とauthorized_keysへの公開鍵登録の手順

公開鍵認証は、鍵ペアの生成とサーバーへの公開鍵登録で使い始められます。鍵の種類はEd25519が既定の推奨で、RSAを使う場合は3072ビット以上を選びます。手順は次のとおりです。

1. ssh-keygen -t ed25519で鍵ペアを生成する（秘密鍵にパスフレーズを設定する）
2. 秘密鍵（id_ed25519）は手元に厳重に保管し、公開鍵（id_ed25519.pub）だけを取り出す
3. ssh-copy-id user@hostで、または手動でサーバーの ~/.ssh/ にあるauthorized_keysへ公開鍵を追記する
4. ssh user@hostで接続し、パスワードなしでログインできることを確認する

秘密鍵はそのマシンの本人性そのものなので、共有ストレージに置いたり複数人で使い回したりしないのが原則です。パスフレーズを付けておけば、秘密鍵ファイルが漏れても即座には悪用されにくくなります。誰のどの鍵をどのサーバーに登録したかを台帳で管理しておくと、退職や端末交換のときに公開鍵を確実に取り消せます。

本番のSSHサーバー運用で残るポート・鍵・アクセス制御の設定要点

ここが本記事の実務の核で、接続できたあとに残るサーバー側の守りを扱います。SSHは既定のままでも動きますが、公開サーバーではsshd_configを締めておかないと攻撃面が広いままになります。

ポート番号変更とパスワード認証無効化とroot直接ログイン禁止の要点

sshdの守りは、設定ファイルsshd_configの数行で大きく変わります。まずPasswordAuthentication noでパスワード認証を止め、公開鍵認証だけに寄せるのが起点です。次にPermitRootLogin noでrootの直接ログインを禁止し、一般ユーザーでログインしてから権限昇格する運用にします。ポート番号を22から別の番号に変える手も併用されますが、これは総当たりのノイズを減らす効果にとどまり、それ自体は本質的な防御ではありません。ポート変更を「対策済み」と誤認せず、認証方式の締めと接続元の制限を主軸に置きます。設定を変えたらsshd -tで構文を検証し、既存の接続を維持したまま別セッションで再ログインを確認してから反映すると、締め出し事故を避けられます。

踏み台サーバー経由の多段SSH接続と鍵の使い回しを避ける運用

本番のデータベースやアプリサーバーを直接インターネットに晒さず、入口を1台の踏み台（バスティオン）に集約する構成が定番です。運用者はまず踏み台へSSHでログインし、そこから内部のサーバーへ再度SSHでつなぐ多段接続になります。SSHはこの多段接続の中核プロトコルで、ProxyJump（ssh -J）を使えば踏み台を経由した接続を1コマンドで書けるのが利点です。踏み台の設計・多段接続・クラウドでの構築判断は踏み台サーバーの仕組みとAWS構築の実装解説で押さえると、SSHをどこに置くかの全体像がつかめます。注意点は鍵の使い回しです。踏み台に秘密鍵を置いて内部へ入る運用は、踏み台が破られたときに内部の鍵ごと奪われます。秘密鍵は手元に残し、エージェント転送や踏み台経由の接続で内部へ抜ける設計にして、鍵そのものを中継サーバーに残さないのが安全側です。

OpenSSHのバージョン追従と弱い暗号方式の廃止による堅牢化

実務で使うSSH実装は、事実上OpenSSHです。OpenSSHはバージョンが上がるたびに、危殆化した暗号方式や鍵形式を既定から外していきます。たとえば古いssh-rsa（SHA-1署名）は新しめのバージョンで既定無効になり、そのままでは旧環境へつながらないことがあります。OpenSSHは10系（2026年時点）まで版を重ねており、サーバー・クライアントの双方を追従させ、弱い暗号を有効に戻して延命しないのが原則です。導入済みバージョンの確認方法や更新手順はOpenSSHの最新バージョン確認と更新手順の解説にまとめており、版が古いまま放置されたサーバーの棚卸しに使えます。暗号方式の廃止は不便の押し付けではなく、破られる前に閉じるための版管理として扱います。

SSHを直接使うべき場面とマネージド接続に寄せる採用判断の分岐

ここまでの仕組みと守りを踏まえ、どんな条件ならSSHを直接運用し、どんな場合は別の方式へ寄せるべきかを言い切ります。「暗号化されているから安全」で止めず、鍵と露出を運用で管理できるかで判断してください。

SSHの直接運用が適合する管理規模と鍵の棚卸し体制の判断条件

次のいずれにも当てはまるなら、SSHを直接運用する形が素直に噛み合います。

• 対象サーバーと接続する人が数えられる規模で、誰のどの鍵がどこに登録されているかを把握できる
• 公開鍵認証に寄せ、パスワード認証とrootログインを止める設定を全台で徹底できる
• 入口を踏み台に集約し、接続元IPやセキュリティグループで待ち受けを絞れる
• 退職・端末交換のたびにauthorized_keysから公開鍵を取り消す運用を回せる

とくに、少数の運用者が明確な入口経由でサーバーを触る構成では、SSHの直接運用が軽くて確実です。鍵の棚卸しと踏み台への集約という2点を回せているかが、この判断の分水嶺になります。

SSHを素で公開し続ける失敗場面とマネージド接続へ寄せる判断

逆に、次の状況ではSSHを素でインターネットに公開し続けるのを避け、マネージドな接続経路へ寄せたほうが安全と運用の両面で楽になります。鍵と露出を人手で追い切れなくなるのが失敗の典型です。

• サーバーと利用者が増え続け、authorized_keysに死んだ鍵が積もって棚卸しが回らない
• 22番ポートを固定IPなしで広く公開し、総当たり試行のログが常態化している
• 誰がいつどのサーバーへ入ったかの接続監査を、SSHのログだけでは追えない
• 秘密鍵が各所の端末や共有ストレージに散在し、漏洩時の影響範囲を特定できない

この段階では、AWS Systems Manager Session Managerのように鍵とポート開放を前提としない接続や、IAMと連動した認証・監査の仕組みへ寄せると、鍵の棚卸しと接続監査の負担が構造的に下がります。踏み台の設計を含めたクラウド上のセキュアな接続経路を外部と詰めたい場合は、クラウドインフラ構築の相談から具体的な構成を検討できます。「とりあえずSSHを開けておく」を続けず、規模に応じて接続方式を切り替えるのが実務的な判断です。

SSH接続とは何かや仕組み・公開鍵認証・SSLとの違いに関するよくある質問

SSHの検討でよく挙がる質問に、仕組みと運用の観点から簡潔に答えます。

SSH接続とは何ですか？

離れた場所のサーバーへ安全にログインしてコマンド操作やファイル転送を行うためのプロトコル、およびその通信のことです。通信経路をまるごと暗号化するため、経路上で盗聴・改ざんされてもログイン情報や操作内容が漏れません。既定でTCPの22番ポートを使い、サーバー側のsshdと手元のsshクライアントがやり取りします。

SSHとSSL/TLSは何が違いますか？

どちらも通信を暗号化する技術ですが、守る対象が違います。SSL/TLSは主にWebサイトやメールなどアプリケーション通信の暗号化に使われ、ブラウザとサーバーの間などで働きます。SSHはサーバーへの遠隔ログインとファイル転送、ポート中継に特化したプロトコルです。暗号技術としては近い要素を使いますが、用途と接続の作法が異なります。

SSHのポート番号は22から変更すべきですか？

変更は総当たり試行のノイズを減らす補助策にはなりますが、それ自体は本質的な防御ではありません。優先すべきは、パスワード認証の無効化・公開鍵認証への統一・rootログインの禁止・接続元の制限です。これらを固めたうえで、ログを静かにする目的でポート変更を併用する順序が現実的です。ポート変更だけで対策済みと考えないでください。

公開鍵認証とパスワード認証はどちらが安全ですか？

公開鍵認証のほうが安全です。パスワード認証は総当たり試行に晒され、弱いパスワードだと突破されます。公開鍵認証は秘密鍵がネットワークに流れず、鍵ペアがないと認証が通らないため総当たりが効きません。本番の公開サーバーでは、パスワード認証を無効化し公開鍵認証だけに寄せるのが定石です。秘密鍵にはパスフレーズを付けて保護します。

SSHで安全にサーバーを運用するには何を設定すべきですか？

sshd_configで、パスワード認証の無効化（PasswordAuthentication no）とroot直接ログインの禁止（PermitRootLogin no）をまず設定します。加えて、公開鍵はEd25519で生成し、接続元IPを絞り、入口を踏み台に集約するのが基本です。OpenSSHのバージョンを追って弱い暗号方式を使い続けないこと、退職や端末交換のたびに公開鍵を棚卸しすることも運用に組み込みます。

関連記事

• 踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】：SSHの多段接続で入口を集約する踏み台の設計を、本記事の運用判断と補完します。
• OpenSSHとは？最新バージョンの確認方法とアップデート手順【2026年版】：SSHの実装であるOpenSSHの版確認と更新を、弱い暗号の廃止と合わせて押さえられます。
• グローバルIPとは？プライベートIPとの違い・確認方法・仕組みを実装者向けに解説：SSHの接続先を指定するIPアドレスの位置づけを、接続元制限の判断とあわせて確認できます。
• FQDNとは？ドメイン名・ホスト名との違いと書き方・確認方法を実装者向けに解説：SSHでホスト名指定して接続する際の名前解決の前提を整理できます。