SSH config 実践リファレンス（AWS）｜EC2・踏み台・SSMアクセスを楽に安全に

未経験〜駆け出しエンジニア向けに、AWSでEC2・踏み台・SSMへ「楽に・安全に」入るための ~/.ssh/config をユースケース中心にまとめました。長いコマンドを卒業し、ProxyJumpで踏み台を透過し、Session Managerで22番を開けない接続まで、コピペで動く設定断片つきで解説します。

01なぜ ~/.ssh/config を書くのか

サーバに入るたびに ssh -i ~/.ssh/emw-dev.pem ec2-user@203.0.113.10 -p 22 のような長いコマンドを打っていませんか。ホスト名・ユーザ・鍵・ポート・踏み台……接続先が増えるほど、この「毎回の手打ち」は事故とストレスの温床になります。

~/.ssh/config は、こうした接続情報をあらかじめ名前を付けて登録しておくファイルです。一度書けば ssh myec2 だけで入れるようになり、踏み台の多段接続や鍵の使い分けも自動化できます。

• 長いコマンドを毎回書かない：エイリアス1語で接続。オプションの打ち間違いも減る
• 踏み台を透過する：ProxyJump で「手前を経由して奥へ」を1コマンドに
• 鍵を明示する：ホストごとに使う鍵を固定でき、「どの鍵だっけ」を無くせる

本記事は man page 的な全項目網羅ではなく、AWS で EC2・踏み台・SSM を触るときに「実際にやりたいこと」から逆引きできるユースケース中心の構成です。各節にコピペで動く ~/.ssh/config の断片を置き、最後に1画面で見返せる早見表を付けます。

02基本の Host ブロック

~/.ssh/config の最小単位は Host ブロックです。まずは1台のEC2に名前を付けてみます。

# ~/.ssh/config
Host myec2
    HostName 203.0.113.10
    User ec2-user
    IdentityFile ~/.ssh/emw-dev.pem
    Port 22

これで ssh myec2 と打つだけで、ec2-user@203.0.113.10 に emw-dev.pem の鍵で接続できます。scp や rsync、VS Code の Remote-SSH でも同じエイリアスがそのまま使えます。

03ユースケース：EC2 にスッと入る

EC2 に入るときの最初のつまずきは「ログインユーザ名」です。パスワードではなく鍵で入り、ユーザ名は AMI（OSイメージ）ごとに決まっています。よく使うものを挙げます。

ユーザ名さえ分かれば、02 の Host ブロックに User と IdentityFile を書くだけです。開発用に複数台あるなら、エイリアスを分かりやすく付けておきます。

Host web01
    HostName 203.0.113.10
    User ec2-user
    IdentityFile ~/.ssh/emw-dev.pem

Host batch01
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/emw-dev.pem

04ユースケース：踏み台を越えて Private subnet の EC2 へ

本番の EC2 は Private subnet に置き、直接インターネットからは入れないのが基本設計です。手前の踏み台（bastion）を経由して奥へ入るとき、便利なのが ProxyJump です。

# ~/.ssh/config
Host bastion
    HostName 203.0.113.10
    User ec2-user
    IdentityFile ~/.ssh/bastion.pem

Host app01
    HostName 10.0.1.20
    User ec2-user
    IdentityFile ~/.ssh/app.pem
    ProxyJump bastion

これで ssh app01 と打つと、SSH が自動で bastion を経由して 10.0.1.20（Private IP）へ接続します。踏み台に一度入って、そこからまた ssh を打ち直す、という二度手間が消えます。1回きりなら設定を書かずに ssh -J bastion ec2-user@10.0.1.20 のようにコマンドで指定することもできます。

多段（踏み台の先にさらに踏み台）も、カンマ区切りで書けます。

Host deep-app
    HostName 10.0.2.30
    User ec2-user
    ProxyJump bastion,app01

05ユースケース：SSM で鍵レス／踏み台レスに近づける

踏み台そのものを運用したくない、22 番ポートをどこにも開けたくない——そんなときは AWS Systems Manager の Session Manager が有力です。SSH の接続経路を、インバウンドポートを開けずに SSM のトンネル（TLS/WebSocket）で作ります。

~/.ssh/config にはインスタンスID をワイルドカードで受ける形で、次のように書きます（この ProxyCommand の書式は AWS 公式ドキュメントの現行手順です）。

# ~/.ssh/config — SSH over Session Manager
Host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
    User ec2-user
    IdentityFile ~/.ssh/emw-dev.pem

これで ssh i-0123456789abcdef0 のようにインスタンスID を直接指定して接続できます。IP や DNS を気にせず、Private subnet の EC2 にも 22 番を開けずに入れます。覚えやすい別名を付けたい場合は、HostName にインスタンスID を書きます。

Host app-ssm
    HostName i-0123456789abcdef0
    User ec2-user
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
    IdentityFile ~/.ssh/emw-dev.pem

• 手元に Session Manager プラグイン（v1.1.23.0 以降）と AWS CLI、接続用の IAM 権限が必要です。プラグインが無いと ProxyCommand が起動しません。
• 対象の EC2 には SSM Agent（v2.3.672.0 以降）と、SSM を許可した IAM ロール（インスタンスプロファイル）が要ります。
• この方式でも SSH 自体の認証は鍵で行うため、対象ホストに登録済みの鍵を IdentityFile に指定します。完全な鍵レスにしたいなら、SSH を介さず aws ssm start-session --target i-xxxx の対話シェルを使う手もあります。

06ユースケース：便利設定で「速く・崩れにくく」

接続が安定し、2回目以降が速くなる設定をまとめて入れておくと快適です。次の Host * ブロックは全ホスト共通の既定として、ファイルの末尾に置きます。

# ~/.ssh/config （末尾に置く共通設定）
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m
    IdentitiesOnly yes

Include ~/.ssh/config.d/*

• ServerAliveInterval：無通信でも一定間隔で生存確認を送り、NAT やロードバランサに切られる「固まったまま切断」を防ぎます。
• ControlMaster / ControlPersist：最初の接続を再利用（多重化）し、2回目以降の ssh・scp を一瞬で開きます。多段や MFA 環境で特に効きます。
• Include：巨大な1ファイルにせず、案件ごと（config.d/projectA など）に分割して読み込めます。
• IdentitiesOnly yes：指定した鍵だけを提示します。手元に鍵が多いと SSH が片っ端から試して Too many authentication failures になりがちなので、その予防になります。

07セキュリティ：事故らないための最低限

SSH は便利な反面、鍵や設定の緩みがそのまま侵入経路になります。難しいことの前に、まず土台を固めます。

• 秘密鍵のパーミッションは 600：chmod 600 ~/.ssh/*.pem。緩いと SSH が読み込みを拒否しますし、他ユーザから読めるのは論外です。
• 鍵にはパスフレーズを付ける：万一鍵ファイルが漏れても、即座に使われるのを防げます。都度の入力は ssh-agent でキャッシュすれば負担は最小限です。
• 鍵の棚卸し：使っていない鍵、退場した人の鍵、いつ作ったか分からない鍵は消します。「鍵は増やしたら減らす」を運用に組み込みます。
• StrictHostKeyChecking は既定（ask）のまま：接続先のホスト鍵を検証する仕組みです。警告を消したいからと no にすると、中間者攻撃に気づけなくなります。安易に無効化しないでください。
• 秘密鍵を Git にコミットしない：.gitignore に鍵・*.pem を入れ、誤コミットを止めます。履歴に入った鍵は「消したつもり」でも残ります。

ここまでの内容と地続きで学ぶなら、サーバ側の操作は Linux 実践コマンドリファレンス、AWS 側の操作は AWS CLI 実践リファレンスが近い距離にあります。あわせてどうぞ。

08早見表：config 項目 × 用途

迷ったときに1画面で見返せるよう、よく使う ~/.ssh/config の項目と用途をまとめます。

もっと踏み込んだ設計や、自社の環境に合わせた運用の相談は EMW までお気軽にどうぞ。基礎から一緒に積み上げる仲間も探しています。採用情報・カジュアル面談はこちら。

09よくある質問（FAQ）