踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】

踏み台サーバー（ジャンプサーバー、Bastion）は、外部から直接触れさせたくない内部サーバーへ、中継地点を1つ挟んでSSH接続するための入口です。本稿ではネットワーク構成から、OpenSSHのProxyJumpによる多段接続、AWSでの構築とauthorized_keysの絞り込み、Session Manager・EC2 Instance Connect Endpoint・IAP・Azure Bastionとの使い分けまでを実装者の目線で整理し、「踏み台を建てるか、マネージドに寄せるか」の境界線まで踏み込みます。

まとめ：踏み台サーバー導入の結論と代替サービスへ移行する判断基準

踏み台サーバーの目的は、内部サーバーへのSSH到達経路を1点に集約し、接続元IP・認証・操作ログをその1点で締めることにあります。プライベートサブネットの資産は直接見えない状態に保ち、運用者は踏み台を経由してのみ入る。この二段構えが設計の核です。

実装では、踏み台に手でログインしてから再度SSHする運用を捨て、OpenSSHのProxyJump（ssh -J）で1コマンドに畳みます。ProxyJumpは2016年8月1日公開のOpenSSH 7.3で追加された機能で、踏み台に秘密鍵を置かずに多段接続を成立させられる点が効きます。踏み台側の鍵はauthorized_keysのrestrictとfromで縛り、転送先を内部ホストのポート22だけに限定しておく。

判断の分かれ目はこうです。オンプレや複数クラウドにまたがる資産を同じ入口で扱うなら、踏み台は今も妥当な選択。対象がAWSのEC2に閉じた新規設計なら、インバウンドポートを開けずに済むSession ManagerかEC2 Instance Connect Endpointを先に置き、踏み台は互換性が要る箇所へ限定するほうが運用は軽くなります。

踏み台サーバー（踏み台サーバ）とジャンプサーバーの定義と構成

踏み台サーバーは、目的のサーバーへ到達するために間に立てる中継ホストです。呼び名が複数あり、実装上は同じものを指します。

踏み台・ジャンプサーバー・Bastionという3つの呼称が指す同一の実体

踏み台サーバー、ジャンプサーバー（jump server／jump host）、Bastion（要塞）ホストは、いずれも「外部境界に置き、内部への唯一の入口として使う中継サーバー」を指します。日本語圏では「踏み台サーバー」と長音を省いた「踏み台サーバ」が混在し、クラウドの文脈では「bastion host」が使われる、という表記差にすぎません。

OpenSSH側も同じ語彙です。ProxyJumpを追加したOpenSSH 7.3のリリースノートには「one or more SSH bastions or “jump hosts”」と明記されており、踏み台とjump hostは公式ドキュメント上でも同義に扱われます。攻撃の中継に悪用される側の「踏み台」とは正反対の、意図的に守りを固めた入口だと捉えてください。

パブリックとプライベートのサブネットを分ける二段接続の通信経路

典型構成では、踏み台をインターネットから到達できるパブリックサブネットに置き、守りたいアプリケーションサーバーやデータベースをプライベートサブネットに置きます。運用者はまず踏み台へSSHし、そこから内部サーバーへ再度SSHする二段のステップを踏む。SSHそのものの仕組みや公開鍵認証・安全なsshd_configの設定はSSH接続の仕組みと公開鍵認証・安全な設定の詳しい解説で押さえられます。

内部サーバー側のセキュリティグループ（またはファイアウォール）は、SSHの受信を踏み台からのみ許可します。これで到達経路が踏み台1点に固定され、接続元の制限・認証・ログ取得をその1台に集められる。踏み台自身の受信も、運用者オフィスやVPNの固定IPに絞るのが前提です。サブネットとセキュリティグループの切り分けに不安があるなら、AWS環境構築の手順（VPC・EC2・IAM・セキュリティグループの初期設計）を先に通しておいてください。

OpenSSHのProxyJumpで踏み台を経由するSSH多段接続の設定手順

踏み台の価値は構成だけでなく接続の実装で決まります。手作業の多段ログインは事故と手間の温床になるため、SSHクライアント側で経由を自動化します。

ssh -J と設定ファイルで多段接続を1コマンドに畳む記述例

OpenSSHには、踏み台を経由して最終ホストへ抜けるProxyJumpがあります。コマンドならssh -J bastion internal-hostの形で、踏み台へのログインと内部ホストへの接続を1回に畳める。ssh_config(5)のProxyJumpの項には「Multiple proxies may be separated by comma characters and will be visited sequentially」とあり、カンマ区切りで三段以上も順に経由できます。常用する接続はSSH設定ファイルに書いておきます。

# ~/.ssh/config
Host bastion
    HostName 203.0.113.10
    User ops
    IdentityFile ~/.ssh/id_ed25519_bastion
    IdentitiesOnly yes

Host app-01
    HostName 10.0.2.21
    User deploy
    IdentityFile ~/.ssh/id_ed25519_app
    ProxyJump bastion
    ForwardAgent no

これでssh app-01だけで踏み台を自動的に経由します。同じマニュアルには「not generally applied to jump hosts」（最終ホスト向けの設定は踏み台には適用されない）という注記があるため、鍵やユーザーが違う場合は上の例のようにホストごとにIdentityFileとUserを分けて宣言してください。クライアント側の版と設定はOpenSSHの最新バージョンの確認方法とアップデート手順で確認しておくと、古い鍵アルゴリズムの拒否設定と合わせて安全側に倒せます。

秘密鍵を踏み台に置かずProxyJumpで認証を手元に残す実装判断

やってはいけないのは、内部ホスト用の秘密鍵を踏み台サーバー上に置くことです。踏み台の侵害がそのまま内部への鍵の流出になる。ProxyJumpは接続を踏み台で中継するだけで、認証はクライアント手元の鍵で行うため、踏み台に鍵を配置せずに多段接続が成立します。

SSHエージェント転送（ForwardAgent）での代用は既定で避けます。理由は権限論だけではありません。2026年8月11日公開のOpenSSH 10.5では、エージェントのロックと転送エージェント識別用の[email protected]拡張の相互作用が修正され、それ以前はローカル限定のはずの操作（PKCS#11トークンの追加など）が遠隔から実行できたと記載されています。転送エージェントを踏み台に差し出す構成は、この種の穴の影響を受ける側に回る。踏み台経由のデプロイをプログラムから叩くなら、PythonのSSHライブラリParamikoの使い方を押さえておくと、多段接続や鍵認証をコードから制御できます。

AWSでの踏み台サーバー構築とauthorized_keysで権限を絞る手順

AWSで踏み台を建てる作業は、インスタンスを起こす手順よりも、受信の絞り込みと鍵の縛りのほうが本体です。順に組みます。

セキュリティグループとサブネットを分けるAWS側の構築作業手順

作業は4つに分かれます。第一に、VPCにパブリックサブネットとプライベートサブネットを用意し、パブリック側にだけインターネットゲートウェイへの経路を引く。第二に、パブリックサブネットへ小さめのLinuxインスタンスを踏み台として起動する。第三に、踏み台用セキュリティグループでポート22の受信を運用者拠点の固定IP（例：198.51.100.0/24）だけに限る。第四に、内部サーバー側のセキュリティグループで、踏み台のセキュリティグループIDを送信元に指定してポート22を開けます。

第四の「送信元にIPではなくセキュリティグループIDを書く」が効きます。踏み台を作り直してプライベートIPが変わっても、内部側のルールを直す必要がありません。なおポート22を公開する以上、総当たりのログイン試行は前提として入ってくる。遮断はFail2banでSSH総当たり攻撃を自動遮断する設定で自動化しておきます。

authorized_keysのrestrictとfromで踏み台の鍵を縛る設定例

踏み台のアカウントは、ログインして作業する場所ではなく「中継だけさせる場所」として構成します。sshd(8)のAUTHORIZED_KEYS FILE FORMATによれば、restrictは「Enable all restrictions」として、ポート・エージェント・X11の各転送とPTY割り当て、~/.ssh/rcの実行をまとめて落とす指定。そのうえで必要な機能だけを個別に戻します。

# /home/ops/.ssh/authorized_keys （踏み台側）
restrict,port-forwarding,permitopen="10.0.2.21:22",from="198.51.100.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... ops-nanaza

ここが実装の要点です。ProxyJumpは踏み台上でTCP転送を張って内部ホストへ抜けるため、restrictだけを付けると多段接続そのものが通らなくなる。port-forwardingで転送だけを戻し、同マニュアルが「may only connect to the specified host and port」と説明するpermitopenで行き先を内部ホストのポート22に固定します。fromはCIDR表記で接続元を縛れるため、セキュリティグループと二重に掛けておく。この書き方なら踏み台上でシェルを取ることも、別ポートへ転送を張り直すこともできません。

踏み台のsshdは版にも注意が要ります。前述のOpenSSH 10.5では「make the authorized_keys “restrict” keyword apply correctly to tunnel forwarding too」という修正が入っており、それ以前はrestrictを書いてもトンネル転送に効いていませんでした。踏み台のようにrestrictを前提に権限を組む用途では、10.5系以降へ上げる価値が実際にあります（2026年9月時点）。反対に、開発者が踏み台経由で検証環境の管理画面をブラウザから見る用途では、ダイナミック転送（ssh -D）を許可する側の設計になります。ブラウザの通信だけをこのトンネルに流す設定は、SwitchyOmegaの後継ZeroOmegaでSOCKS5プロファイルを設定する手順で扱っています。

踏み台サーバー運用の3大リスクと証跡・鍵の棚卸しという実務対策

踏み台は導入すれば安全になる装置ではありません。運用で崩れる典型を先に潰しておきます。

ポート22開放・単一障害点・鍵管理という3つの弱点と対処の順序

踏み台の弱点は3つに集約できます。第一はポート開放です。踏み台はSSH（既定でポート22）を開ける前提のため、それ自体が攻撃対象になる。接続元IPの制限を外した瞬間、総当たりの標的です。第二は単一障害点で、踏み台が落ちると内部への正規の入口が塞がります。第三は鍵とアカウントの棚卸しで、利用者が増えるほど追いつかず、退職者の鍵が残る事故につながる。

実務でまず効くのは接続元IPの厳格な制限です。ここを固定IPやVPN経由に絞れば、ポート22開放の危険の大半は下がる。冗長化はその次、鍵の定期棚卸しは運用ルールとして回します。IP制限を緩いまま冗長化から手を付ける構成は、攻撃対象を2台に増やしただけで終わります。

操作ログとセッション証跡の取得・多要素認証を重ねる運用上の対策

踏み台を置く動機の半分は「誰がいつどの内部サーバーへ入ったか」の証跡です。ログインを集約すると、認証ログ（auth.logなど）とセッション記録をその1台で取れます。監査要件があるなら、コマンド履歴や録画・再生できる証跡ツールを踏み台に併設。証跡が取れていない踏み台は、監査の観点では「無いのと同じ」に近い扱いです。

認証は鍵だけに頼らず、多要素認証（MFA）を踏み台のログインに重ねます。鍵が漏れても、もう1要素で内部到達を止められる二重化が、踏み台という単一入口の価値を成立させる条件。SSH鍵にFIDOトークンを紐づける方式なら物理的な所持要素を足せます。実装方式の選び分けは多要素認証（MFA）の3要素と耐フィッシングMFAの解説にまとめてあります。

踏み台サーバーとSSM・EICE・IAP・Azure Bastionの機能比較

「そもそも踏み台を建てない」選択肢が実用段階にあります。ポートを開けずに内部へ到達するマネージドサービス群です。

Session ManagerとEICEで踏み台を建てずに接続する2経路

AWSには、踏み台を建てずに済む経路が2つあります。AWS Systems Manager Session Managerの公式ドキュメントは「without the need to open inbound ports, maintain bastion hosts, or manage SSH keys」と明記しており、対象ノードに入れたSSM Agentが内側からAWS側へ通信を張る方式。導入可否はSSM Agentのインストールと踏み台不要のSession Manager接続で確認できます。

見落とされがちな制約が1つあります。同ドキュメントには「Logging isn’t available for Session Manager sessions that connect through port forwarding or SSH」と書かれており、ポート転送やSSH経由のセッションはログが残りません。証跡が導入理由なら、SSHトンネルとして使わず、Session Managerのシェルセッションとして使う設計にしてください。もう1つの経路がEC2 Instance Connect Endpoint（EICE）で、SSM Agentを入れられないAMIでも、VPCにエンドポイントを1つ置けばプライベートIPのインスタンスへSSHで抜けられます。

# SSM Agent あり: Session Manager でシェルを開く
aws ssm start-session --target i-1234567890abcdef0

# SSM Agent なし: EICE 経由で SSH（踏み台インスタンス不要）
aws ec2-instance-connect ssh --instance-id i-1234567890abcdef0 \
    --os-user ec2-user --connection-type eice

どちらを選ぶ場合も、VPCのサブネット設計とIAM権限の切り方を先に決めないと、接続方式だけ差し替えても運用は軽くなりません。この種の接続設計からサブネット構成・移行までは、一創のクラウドインフラ構築（AWS・Google Cloud・Azure）で要件に合わせて設計から支援しています。

GCPのIAPとAzure Bastion・Teleportなどマネージド代替の比較

踏み台の代替は各クラウド・OSSに存在します。用途が近いものを整理します。

Google CloudのIAP（Identity-Aware Proxy）はTCP転送でVMへ抜けます。公式ドキュメントでは、ファイアウォールでIAPの送信元レンジ（IPv4は35.235.240.0/20、IPv6は2600:2d00:1:7::/64）からのポート22を許可し、roles/iap.tunnelResourceAccessorを付与したうえでgcloud compute sshに--tunnel-through-iapを付ける流れが示されています。VMに外部IPを付けずに済む点が踏み台との差です。

Azureは踏み台そのものをマネージドで提供します。公式ドキュメントによれば、SKUはDeveloper・Basic・Standard・Premiumの4段階。セッション録画はPremium、ネイティブSSH／RDPクライアント接続はStandard以上、専用サブネットAzureBastionSubnetはBasic以上で必須という切り分けで、機能差と料金はAzure Bastionの4つのSKUと接続方式・料金の解説に整理しています。TeleportのようなOSS・製品は、マルチクラウドやKubernetesをまたいでアクセス制御と録画を掛けたい規模で強みが出る。単一クラウドに閉じるならクラウド純正、環境が混在するなら製品、という切り分けが実務的です。

踏み台サーバーを採用すべき要件とマネージド移行が過剰になる境界

ここは玉虫色にせず言い切ります。踏み台を建てるか、マネージドへ寄せるかは、環境と要件でほぼ決まります。

踏み台サーバーが妥当な要件とマネージド移行が過剰になる境界線

踏み台サーバーが依然として妥当なのは、オンプレミスや特定クラウドに依存しない構成が要る、複数のOSやレガシー機器へ同じ入口で入りたい、あるいはSSM Agent等を入れられない資産が対象に混じる場合です。ここではクラウド純正の代替が届かず、自前の踏み台が中継として効きます。

逆に、対象がAWSのEC2に閉じていて新規に設計できるなら、踏み台を建てるのは過剰です。ポート22開放・パブリックサブネット・鍵配布・冗長化という運用一式を、Session Managerなら丸ごと省ける。SSM Agentを入れられないAMIでも、EICEなら踏み台インスタンスは要りません。「単一クラウド・新規・エージェントまたはVPCエンドポイントが置ける」の3条件がそろう環境で自前の踏み台を選ぶのは、守るべき攻撃対象と運用工数を自分で増やす判断です。

失敗パターン：共有鍵の踏み台放置と証跡欠如という2つの典型例

踏み台運用でよく壊れるのは2点です。1つ目は、チームで同じ秘密鍵を使い回し、その鍵や内部ホスト用の鍵を踏み台上に置きっぱなしにするパターン。踏み台が破られれば内部が丸ごと抜かれ、しかも「誰が入ったか」を鍵から特定できません。利用者ごとに鍵とアカウントを分け、鍵は踏み台に置かないのが最低条件です。

2つ目は、踏み台を建てただけで満足し、証跡もMFAも入れないパターン。これでは接続元を1点に寄せただけで、監査にも侵害対応にも使えません。前述のとおりSession ManagerをSSHトンネルとして使った場合も同じ穴が開きます。証跡取得・MFA・接続元IP制限・authorized_keysの絞り込みは、踏み台の導入判断とセットで初期構築に含めてください。

よくある質問

踏み台サーバーの実装・運用でよく寄せられる疑問に、判断の目安とあわせて答えます。

踏み台サーバーとVPNやゼロトラストはどう違いますか？

踏み台サーバーは「特定の中継ホストを1つ挟んでSSHする」経路の集約で、VPNは「社内ネットワークそのものへ接続元を引き込む」仕組みです。ゼロトラスト系（IAPやSession Manager等）は、ネットワーク境界ではなく認証・認可を都度チェックし、ポート開放や踏み台自体を不要にする方向へ進みます。守りたい対象が単一クラウドに閉じるなら、踏み台やVPNより、ポートを開けない方式のほうが運用は軽くなります。

踏み台サーバーはAWSでどう構築しますか？

パブリックサブネットに小さめのLinuxインスタンスを踏み台として立て、そのセキュリティグループでSSHの受信を運用者の固定IPに限定します。内部サーバーはプライベートサブネットに置き、SSH受信を踏み台のセキュリティグループIDからのみ許可。接続はクライアント側のProxyJumpで経由させ、踏み台のauthorized_keysはrestrict,port-forwarding,permitopenで中継だけに絞ります。新規設計ならSession ManagerとEICEも同時に比較してください。

ProxyCommandとProxyJumpのどちらを使うべきですか？

OpenSSH 7.3系（2016年8月1日公開）以降が使える環境なら、記述が簡潔でミスの少ないProxyJump（-JまたはProxyJump）を選びます。ssh_config(5)には両者が併存すると先に指定したほうが優先される旨の注記があるため、同じホストに両方を書く構成は避けてください。ProxyCommandは独自コマンドを挟む特殊なケースに限って使えば足ります。

踏み台サーバに秘密鍵を置いても問題ないですか？

置くべきではありません。踏み台サーバ（踏み台サーバー）は最も攻撃にさらされる位置にあり、そこに内部ホスト用の秘密鍵が残ると、踏み台の侵害が内部への鍵流出に直結します。ProxyJumpを使えば認証はクライアント手元の鍵で行われ、踏み台に鍵を置かずに多段接続が成立する仕組み。エージェント転送も既定では無効にし、ForwardAgent noを明示しておきます。

踏み台サーバーはもう不要になったのですか？

単一クラウドで新規に設計でき、SSM AgentやVPCエンドポイントを置ける環境なら、Session Manager・EICE・IAPで踏み台を建てずに済むケースが増えました。一方、オンプレやマルチクラウド、エージェントを入れられないレガシー資産が対象なら、踏み台は今も中継として有効です。「不要」は環境依存の結論であり、要件次第でマネージドへ寄せるかを判断します。

関連記事

• SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで：踏み台と内部ホストの両方で前提になるSSHそのものの設定。
• SSM Agentとは？踏み台不要のSession Manager接続まで：踏み台を廃止する側の実装手順と前提条件。
• Azure Bastionとは？4つのSKUと接続方式・料金：マネージド踏み台をAzureで使う場合のSKU選び。
• Fail2banとは？SSH総当たり攻撃を自動遮断する仕組みと設定：ポート22を開ける踏み台で先に入れておく遮断設定。
• クラウドインフラ構築（AWS・Google Cloud・Azure）：踏み台の要否判断からサブネット設計・移行までの構築支援。