この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
セミナーでこの質問をされると、私はいつも当時の自分を思い出します。SE時代、私もまったく同じように思っていました。ターミナルを2枚開いて、1枚目で踏み台サーバーにSSHログインし、その中からさらに本番サーバーへSSHする——そういう「手順」だけは知っていたのですが、なぜその構成が必要なのか、もっとスマートな方法があることは、恥ずかしながら現場に入るまで知りませんでした。
この記事では、SSH多段接続の仕組みとProxyJumpの設定方法を、20年以上Linuxサーバーを運用してきた経験から解説します。踏み台サーバーが必要な理由から、コマンドライン・設定ファイル両方での接続手順、そして「動かない」ときのトラブル対処まで、実務で使えるレベルで説明します。
この記事のポイント
・踏み台サーバー（Bastion Host）が必要な理由と役割
・ProxyJump（-J オプション）でコマンド1回で多段接続できる
・~/.ssh/config に設定するとホスト名だけで接続できるようになる
・多段接続が「動かない」ときの典型的な原因と対処手順
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
踏み台サーバーを「ターミナル2枚開いてSSHを2回打つもの」と思っていた
2003年頃、私が勤めていたシステム会社では、社内のPCからクライアントの本番サーバーへ直接SSHで接続することができませんでした。インターネットに公開されたジャンプサーバー（当時は「踏み台」「踏み台サーバー」と呼んでいました）を経由しないと、本番サーバーのIPアドレス自体がルーターで弾かれる構成でした。当時の私のやり方は、こうです。
・ターミナルを2枚開く
・1枚目で踏み台サーバーにSSHログイン
・そのターミナルの中からさらに本番サーバーへSSH
これで動くので、ずっとそれが「正解」だと思っていました。先輩から「ProxyJumpって知ってる？」と聞かれたとき、「あ、なんか便利なオプションがあるんですか」と軽く返したのですが、実際に使い方を教えてもらって愕然としました。コマンド1回で、踏み台を経由して本番サーバーまで直接接続できるのです。しかも設定ファイルに書いておけば、ホスト名を打つだけで完了する。
「なんで今まで2枚開いていたんだろう……」と、その日の帰りに深く反省したことをよく覚えています。セミナーで3,100名以上を指導してきた中で、同じ「2回打ちで慣れてしまっている」受講生は非常に多く、この経験はいつも共感を呼びます。
踏み台サーバー（Bastion Host）が必要な理由
なぜ本番サーバーに直接SSHで入らないのでしょうか。セキュリティの基本に立ち返ると、理由は明確です。1. 本番サーバーを外部からの攻撃にさらさないため
本番サーバーを直接インターネットに公開するということは、SSHポート（22番）が全世界からアクセス可能な状態になることを意味します。パスワード認証を有効にしたままにすると、ブルートフォース（総当たり）攻撃の標的になります。私がSE時代に担当していたサーバーのSSHログには、1日に数千件の不正ログイン試行が記録されていたこともありました。踏み台サーバーだけを外部に公開し、本番サーバーはプライベートネットワーク内に閉じる構成にすることで、攻撃対象を絞ることができます。全サーバーを個別に防御するより、踏み台1台を厳密にアクセス制御する方が管理しやすく、実際に現場で広く採用されているパターンです。
2. アクセスログを一元管理できる
誰がいつ本番サーバーに入ったのかを追跡する際、経由する踏み台サーバーのSSHログさえ確認すれば把握できます。セキュリティインシデント発生時の原因調査がはるかに楽になります。20年以上の運用経験の中でも、「踏み台ログが唯一の手がかりになった」という障害対応を何度も経験しています。3. 内部ネットワークの構成を外部から隠せる
外部から見えるのは踏み台サーバーのIPアドレスだけです。本番サーバーが192.168.x.xというプライベートアドレスにいることすら、外部の攻撃者には分かりません。クラウド環境（AWSやAzure）でも、VPCやVNet内のプライベートサブネットに本番サーバーを配置して踏み台（Bastion Host）経由でのみアクセスする構成は、セキュリティのベストプラクティスとして広く推奨されています。ProxyJumpでSSH多段接続を1コマンドで完結させる
OpenSSH 7.3（2016年リリース）以降では、`ProxyJump`（コマンドラインでは `-J` オプション）が利用できます。RHEL 9・Rocky Linux 9・Ubuntu 22.04 LTS以降の環境なら標準で使えます。1. コマンドラインで直接指定する
踏み台サーバー（bastion.example.com）を経由して、本番サーバー（prod-server.local）に接続する場合、以下のように書きます。# -J で踏み台サーバーを指定して本番サーバーへ直接接続する # ssh -J [踏み台ユーザー@踏み台ホスト] [本番ユーザー@本番ホスト] # ssh -J bastion-user@bastion.example.com prod-user@prod-server.local [prod-user@prod-server ~]$ # 接続確認コマンド（ホスト名と日時だけ確認してすぐ切断） # ssh -J bastion-user@bastion.example.com prod-user@prod-server.local "hostname && date" prod-server.local Thu Sep 11 07:00:00 JST 2026
複数の踏み台を経由する場合（3段接続）は、カンマ区切りで指定します。
# 踏み台1 → 踏み台2 → 本番サーバーの3段接続 # ssh -J bastion1@bastion1.example.com,bastion2@bastion2.example.com prod-user@prod-server.local [prod-user@prod-server ~]$
2. ~/.ssh/config に書いておく方法
コマンドラインで毎回オプションを書くのは手間です。`~/.ssh/config` に設定を書いておくと、`ssh prod` と打つだけで完結します。# ~/.ssh/config の設定例（~/.ssh/config をテキストエディタで作成・編集する） # 踏み台サーバーの設定 Host bastion HostName bastion.example.com User bastion-user IdentityFile ~/.ssh/id_rsa_bastion # 本番サーバーの設定（踏み台経由・ProxyJump を指定） Host prod HostName prod-server.local User prod-user ProxyJump bastion IdentityFile ~/.ssh/id_rsa_prod # 設定後はこれだけで接続できる # ssh prod [prod-user@prod-server ~]$
# ~/.ssh/config のパーミッションを確認する # ls -la ~/.ssh/config -rwxrwxrwx 1 user user 256 Sep 11 07:00 /home/user/.ssh/config # 所有者のみ読み書き可（600）に修正する # chmod 600 ~/.ssh/config # ls -la ~/.ssh/config -rw------- 1 user user 256 Sep 11 07:00 /home/user/.ssh/config
SSH多段接続が「動かない」ときのエラー対処
ProxyJumpを設定したのに接続できない、というトラブルは現場でよく発生します。私のセミナーでも「設定した通りにやったのに動かない」という相談は毎回出てきます。典型的なパターンを3つ紹介します。1. 踏み台サーバーでTCPフォワーディングが禁止されている
ProxyJumpは内部的にSSHのポートフォワーディング（TCPフォワーディング）を利用します。踏み台サーバーの `/etc/ssh/sshd_config` で `AllowTcpForwarding no` が設定されていると、ProxyJumpは使えません。# 踏み台サーバーでTCPフォワーディングの設定を確認する # grep AllowTcpForwarding /etc/ssh/sshd_config AllowTcpForwarding no # AllowTcpForwarding が no の場合は yes に変更して sshdを再起動する # （この作業は踏み台サーバーの管理者が行う） # sed -i 's/^AllowTcpForwarding no/AllowTcpForwarding yes/' /etc/ssh/sshd_config # systemctl restart sshd # systemctl status sshd
2. 本番サーバーへの認証に使う秘密鍵が踏み台にない
古い構成では「手元のPCで踏み台サーバーにSSH接続し、踏み台サーバーから本番サーバーへSSH接続する」という2段階のやり方をとっていました。その場合、踏み台サーバーに本番サーバー用の秘密鍵を置いていたケースがあります。ProxyJumpに切り替えると、本番サーバーへの認証は「手元のPCにある秘密鍵」で行われます。踏み台サーバーに秘密鍵を置く必要はなくなりますが、手元のPCに本番サーバー用の秘密鍵があることが前提です。
・確認すること：手元のPCの `~/.ssh/` に本番サーバー用の秘密鍵があるか
・確認コマンド：`ls -la ~/.ssh/` で秘密鍵ファイル（id_rsa, id_ed25519など）の存在と権限を確認する
・権限の修正：秘密鍵は 600（所有者のみ読み取り可）でなければならない
3. 本番サーバーの host key が known_hosts に登録されていない
ProxyJumpを使って初めて本番サーバーへ接続する際、以下のような確認メッセージが出ます。# 初回接続時のhost key確認メッセージ # ssh prod The authenticity of host 'prod-server.local (192.168.1.100)' can't be established. ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Are you sure you want to continue connecting (yes/no/[fingerprint])? # yes と入力すると ~/.ssh/known_hosts に登録されて次回から表示されなくなる yes Warning: Permanently added 'prod-server.local' (ED25519) to the list of known hosts. [prod-user@prod-server ~]$
現場で役立つSSH接続管理のTips
Agent Forwarding（AgentForwarding）の落とし穴
古いドキュメントには「SSH Agent Forwarding（`-A` オプション、または `ForwardAgent yes`）を使って踏み台経由で本番サーバーへの認証を行う」という方法が書かれていることがあります。現在ではこの方法は推奨されていません。踏み台サーバーがroot権限で侵害された場合、攻撃者はそのサーバーで開いているSSH Agentのソケットを悪用して、本番サーバーになりすませる可能性があります。私が担当したセキュリティ診断案件でも、「Agent Forwarding経由の横断移動（Lateral Movement）」は頻出の攻撃パスでした。
ProxyJumpを使うと、秘密鍵は手元のPCから直接本番サーバーの認証に使われます。踏み台サーバーには秘密鍵もAgentのソケットも渡りません。これがProxyJumpが強く推奨される理由のひとつです。
多段接続のタイムアウト対策
本番サーバーへの接続後、しばらく操作しないとSSH接続が切れてしまう問題がよく起きます。踏み台サーバーと本番サーバーの双方でSSHのアイドルタイムアウト設定が効いてくるためです。`~/.ssh/config` に `ServerAliveInterval` を設定することで対処できます。# ~/.ssh/config にタイムアウト対策を追加する # ServerAliveInterval: SSHクライアントが60秒ごとに生存確認パケットを送る # ServerAliveCountMax: 生存確認が3回失敗したら接続を切る Host bastion HostName bastion.example.com User bastion-user IdentityFile ~/.ssh/id_rsa_bastion ServerAliveInterval 60 ServerAliveCountMax 3 Host prod HostName prod-server.local User prod-user ProxyJump bastion IdentityFile ~/.ssh/id_rsa_prod ServerAliveInterval 60 ServerAliveCountMax 3
SSH接続に関連する他のトラブルとして、SSH公開鍵認証そのものの仕組みを理解していないと、接続できない原因の切り分けが難しくなります。鍵の生成から配布・パーミッション設定まで、基礎から確認したい方は「LinuxMaster.JPのLinux学習ガイド」も参照してください。
まとめ
SSH多段接続（踏み台サーバー経由）は、現代のLinuxサーバー運用において標準的な接続方式です。「ターミナルを2枚開いてSSHを2回打つ」やり方から、ProxyJumpを使った1コマンド接続へ移行することで、作業効率だけでなくセキュリティも向上します。`~/.ssh/config` に設定しておくことで、接続作業そのものをほぼ意識しなくて済むようになります。| やりたいこと | コマンド / 設定 |
|---|---|
| 踏み台経由でコマンドラインから接続 | ssh -J bastion-user@bastion.example.com prod-user@prod-server.local |
| 3段接続（踏み台を2つ経由） | ssh -J bastion1@host1,bastion2@host2 prod-user@prod-server.local |
| configに設定して短いコマンドで接続 | ssh prod（~/.ssh/config にProxyJump設定後） |
| ~/.ssh/config の権限を修正する | chmod 600 ~/.ssh/config |
| 踏み台でTCPフォワーディング許可確認 | grep AllowTcpForwarding /etc/ssh/sshd_config |
| known_hostsの古いエントリを削除する | ssh-keygen -R prod-server.local |
| タイムアウト対策（config設定） | ServerAliveInterval 60 を ~/.ssh/config に記載 |
セミナーの詳細を見る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxのkillコマンドを「とりあえずkill -9」で使っていた話｜SIGTERMとSIGKILLの違いを知って変わった障害対応の考え方
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます