ssh configの書き方｜踏み台・ポートフォワードの用途別テンプレート

ssh configとは、接続先ごとのホスト名・ユーザー名・ポート・鍵・踏み台などを ~/.ssh/config に書いておき、ssh 名前 だけで接続できるようにする設定ファイルです。長いオプションを毎回打つ必要がなくなり、踏み台サーバー経由の接続やポートフォワード（通信の転送）も1行で使えるようになります。

この記事では、用途別にコピペできるテンプレートをまとめたうえで、1台のLinuxに sshd（SSHサーバー）を3つ立てて「踏み台 → アプリサーバー → 内部サーバー」の構成を作り、ProxyJump・多段接続・-L/-R/-D のポートフォワードを実際に疎通確認しました（OpenSSH 9.6p1 / Ubuntu 24.04）。ssh -G で「最終的にどの設定が使われるか」を確かめる方法、設定は最初に一致した値が使われるという優先順位の実験、よく出るエラー（Bad owner or permissions、Too many authentication failures、Permission denied (publickey)）の再現と対処、Windowsでの設定場所の違いもまとめています。

ssh configの早見表

ssh configの場所と基本の書き方

設定ファイルの場所

自分用の設定は ~/.ssh/config に書きます。ファイルがなければ作り、自分だけが書き込めるようにします。

mkdir -p ~/.ssh && chmod 700 ~/.ssh
touch ~/.ssh/config && chmod 600 ~/.ssh/config

鍵がまだない場合は、ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work で作れます（OpenSSH 10.0 でDSA鍵は廃止されたため、新しく作るなら Ed25519 が標準的です）。

書式のルール

# コメントは # から
Host web                     # ← 呼び出し名。ここから次の Host までがこのホストの設定
    HostName 203.0.113.10    # ← インデントは見やすさのため（なくても動く）
    User deploy
    Port 10022
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Host から次の Host（または Match）までが1つのブロックです。キーワードは大文字・小文字を区別せず、値との間はスペースか = で区切ります。これで ssh web と打つだけで、ssh -p 10022 -i ~/.ssh/id_ed25519_work deploy@203.0.113.10 と同じ接続になります。scp・rsync・git も同じ設定を使うので、scp file web:/tmp/ や git clone web:repo.git のように書けます。

用途別テンプレート集（コピペ用）

1. 全ホスト共通の設定をまとめる

# ~/.ssh/config の「最後」に書く
Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3
    AddKeysToAgent yes
    IdentitiesOnly yes

Host * は全ホストに当たるので、ファイルの最後に置きます。理由は後述の「優先順位」で実験します。ServerAliveInterval 30 と ServerAliveCountMax 3 で、30秒ごとに生存確認をして、3回応答がなければ切断します。無操作で切れる接続を保ちやすくなります。

2. 同じサービスで鍵を使い分ける（複数アカウント）

Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Host github-private
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_private
    IdentitiesOnly yes

git clone github-work:example-org/app.git

IdentitiesOnly yes を付けると、書いた鍵だけが使われます。付けないと、ssh-agent に登録された鍵も順番に試されるため、別アカウントの鍵で認証されてしまうことがあります。

3. ワイルドカードでまとめて設定する

Host web-* !web-test
    User deploy

Host web-??
    Port 10022

Host *.internal.example
    ProxyJump bastion

ssh -G で確かめると、web-01 は User deploy・Port 10022、web-test は除外されて既定値、web-100 は web-??（? は1文字ちょうど）に一致しないため Port が既定の22でした。!web-test で特定のホストだけ外せます。

4. 設定ファイルを分割する（Include）

# ~/.ssh/config の先頭
Include ~/.ssh/conf.d/*.conf

Host *
    ServerAliveInterval 30

# ~/.ssh/conf.d/project-a.conf
Host pa-web
    HostName 192.0.2.10
    User deploy

Include はファイルの先頭に書きます。Host ブロックの途中に書くと、読み込んだ内容がそのブロックの条件の中に入ってしまいます。実際に比べました。

== Include を先頭に書いた場合（ssh -G pa-web）
user deploy
hostname 192.0.2.10

== Host bastion ブロックの後ろに書いた場合
user root
hostname pa-web        ← 読み込んだ設定が使われていない

相対パスで書いた場合は ~/.ssh/ からの相対パスとして扱われます。

5. 踏み台サーバー経由で接続する（ProxyJump）

Host bastion
    HostName bastion.example.com
    User ops
    IdentityFile ~/.ssh/id_ed25519_work

Host app
    HostName 10.0.1.20          # 踏み台から見たアドレス
    User deploy
    ProxyJump bastion

ProxyJump を書くと、ssh app だけで踏み台を経由して接続できます。HostName には「踏み台から見た」アドレス（プライベートIPなど）を書きます。鍵は手元のものが使われるので、踏み台に秘密鍵を置く必要はありません。

6. 多段の踏み台（2段以上）

Host internal
    HostName 10.0.2.30
    User deploy
    ProxyJump bastion,app       # 左から順に経由する

カンマで区切ると、左から順に経由します。app 側にも ProxyJump bastion が書いてある場合は、ProxyJump app だけでも同じ経路になります。

7. 踏み台の先のDBに手元から接続する（LocalForward）

Host db-tunnel
    HostName 10.0.1.20
    User deploy
    ProxyJump bastion
    LocalForward 15432 db.internal:5432   # 手元の15432 → (app から見た) db.internal:5432
    ExitOnForwardFailure yes

ssh -N -f db-tunnel                      # 転送だけしてバックグラウンドへ
psql -h 127.0.0.1 -p 15432 -U app_user appdb

LocalForward 手元のポート 宛先:ポート の「宛先」は、接続先サーバーから見た名前です。手元のツール（psql、DBクライアント、ブラウザ）は 127.0.0.1:15432 に接続すれば、踏み台の先のDBに届きます。

8. 手元の開発サーバーを接続先に見せる（RemoteForward）

Host demo
    HostName 203.0.113.20
    User deploy
    RemoteForward 18080 localhost:8080   # 接続先の18080 → 手元の8080

RemoteForward は向きが逆で、接続先サーバーの 127.0.0.1:18080 への通信が手元の 8080 に届きます。接続先の外から見えるようにするには、サーバー側の sshd で GatewayPorts の設定が必要です。既定では接続先の 127.0.0.1 だけで待ち受けるので、意図せず外部に公開されることはありません。

9. SOCKSプロキシとして使う（DynamicForward）

Host socks
    HostName bastion.example.com
    User ops
    DynamicForward 1080

curl --socks5-hostname 127.0.0.1:1080 http://intranet.internal/

DynamicForward は宛先を決めずに、手元の1080番をSOCKSプロキシにします。ブラウザのプロキシ設定に SOCKS5 127.0.0.1:1080 を指定すると、社内向けの管理画面などを踏み台経由で開けます。--socks5-hostname を使うと、名前解決も踏み台側で行われます。

10. 接続を使い回して速くする（ControlMaster）

Host *
    ControlMaster auto
    ControlPath ~/.ssh/cm/%C
    ControlPersist 10m

mkdir -p ~/.ssh/cm && chmod 700 ~/.ssh/cm

1回目の接続を「親」として残し、2回目以降はその接続を使い回します。%C は接続先・ポート・ユーザーなどから作られるハッシュで、ファイル名を短く一意にできます。ControlPersist 10m で、最後のセッションを閉じてから10分間は親接続を残します。

11. 条件で設定を切り替える（Match）

# 社内ネットワークにいるときは踏み台を使わない
Match host app exec "test -f /tmp/office-network"
    ProxyJump none

Host app
    HostName 10.0.1.20
    ProxyJump bastion

Match は host・user・exec（コマンドが成功したら）などの条件で設定を当てます。OpenSSH 10.0 では Match version・Match sessiontype・Match command も追加されました。

12. エージェント転送（ForwardAgent）は必要なホストだけに

Host *
    ForwardAgent no          # 既定値。明示しておくと安心

Host build-server
    ForwardAgent yes         # どうしても必要なホストだけ

エージェント転送を有効にすると、接続中は、接続先の管理者権限を持つ人があなたのエージェントを使って別のサーバーへ認証できる状態になります（秘密鍵そのものは渡りません）。踏み台を越えるだけなら、エージェント転送ではなく ProxyJump を使うと、鍵の情報を接続先に渡さずに済みます。

検証：ローカルに踏み台構成を作って試す

ここからの実行結果は、1台のLinux上に sshd を3つ立てて確かめたものです。

本来の ~/.ssh/config を変えないよう、検証用の設定ファイルを作って ssh -F config で読み込ませています。sshd も専用の設定ファイルとホスト鍵を作り、/usr/sbin/sshd -f 専用config -D で起動しました。

# ---- 検証用（作業フォルダ内） ----
Host bastion
    HostName 127.0.0.1
    Port 7270
    User root

Host app
    HostName 127.0.0.1
    Port 7271
    User root
    ProxyJump bastion

Host internal
    HostName 127.0.0.1
    Port 7272
    User root
    ProxyJump bastion,app

Host *
    IdentityFile （検証用フォルダ）/id_ed25519
    IdentitiesOnly yes
    StrictHostKeyChecking accept-new
    ServerAliveInterval 30
    ServerAliveCountMax 3
    # ほかに known_hosts も検証用フォルダに向けています

ssh -G で最終的な設定を確認する

ssh -F config -G app | grep -E '^(user|hostname|port|proxyjump|identitiesonly|serveraliveinterval|serveralivecountmax|forwardagent|controlmaster|addkeystoagent) '

user root
hostname 127.0.0.1
port 7271
controlmaster false
identitiesonly yes
serveralivecountmax 3
serveraliveinterval 30
addkeystoagent false
forwardagent no
proxyjump bastion

ssh -G ホスト名 は、実際には接続せずに「すべての設定を当てはめた結果」を表示します。書いた設定が効いているか迷ったら、まずこれで確認します。

多段接続の流れを -v で見る

ssh -F config -v internal true 2>&1 | grep -E 'Applying options|ProxyJump|Executing proxy|Authenticated to'

debug1: config line 13: Applying options for internal
debug1: config line 19: Applying options for *
debug1: Setting implicit ProxyCommand from ProxyJump: ssh -J bastion -F config -v -W '[%h]:%p' app
debug1: Executing proxy command: exec ssh -J bastion -F config -v -W '[127.0.0.1]:7272' app
debug1: config line 7: Applying options for app
debug1: config line 19: Applying options for *
debug1: Setting implicit ProxyCommand from ProxyJump: ssh -F config -v -W '[%h]:%p' bastion
debug1: Executing proxy command: exec ssh -F config -v -W '[127.0.0.1]:7271' bastion
debug1: config line 2: Applying options for bastion
debug1: config line 19: Applying options for *
Authenticated to 127.0.0.1 ([127.0.0.1]:7270) using "publickey".
Authenticated to 127.0.0.1 (via proxy) using "publickey".
Authenticated to 127.0.0.1 (via proxy) using "publickey".

ProxyJump bastion,app が「bastion → app → internal」の順につながり、3回とも手元の鍵で認証されていることがわかります。-W は「受け取った通信を指定の宛先へそのまま流す」オプションで、ProxyJump は内部でこれを使っています。接続時間は、踏み台1段の app が0.53秒、2段の internal が0.68秒でした（同じマシン内なので実際のネットワークよりずっと短い値です）。

設定の優先順位：最初に一致した値が使われる

ssh configは上から順に読まれ、各項目は「最初に決まった値」が使われます。後から同じ項目を書いても上書きされません。次の2つを比べました。

# prio.conf（Host * が途中にある）
Host web01
    User deploy

Host *
    User admin
    Port 2222
    ServerAliveInterval 60

Host web01
    Port 10022
    ServerAliveInterval 15

$ ssh -F prio.conf -G web01 | grep -E '^(user|port|serveraliveinterval) '
user deploy
port 2222                ← 下の Host web01 の 10022 は使われない
serveraliveinterval 60

Host web01 の設定をすべて上にまとめ、Host * を最後に置くと、意図どおりになります。

$ ssh -F prio2.conf -G web01 | grep -E '^(user|port|serveraliveinterval) '
user deploy
port 10022
serveraliveinterval 15

$ ssh -F prio2.conf -G -p 8022 -o User=ops web01 | grep -E '^(user|port) '
user ops
port 8022

覚え方は「具体的なホストを上に、Host * を一番下に」です。

例外として、IdentityFile や LocalForward などは複数書くと「追加」されます。検証では、configの IdentityFile に加えて -o IdentityFile=別の鍵 を指定すると、ssh -v に Will attempt key: が2行出て、両方の鍵が順番に試されました。

ポートフォワード3種類を疎通確認する

flowchart LR
    subgraph L["-L / LocalForward"]
        A1[手元:15432] -->|SSH| B1[接続先] --> C1[宛先 DB:5432]
    end
    subgraph R["-R / RemoteForward"]
        B2[接続先:18080] -->|SSH| A2[手元] --> C2[手元の開発サーバー:8080]
    end
    subgraph D["-D / DynamicForward"]
        A3[手元:1080 SOCKS] -->|SSH| B3[接続先] --> C3[アプリが指定した宛先]
    end

-L：踏み台経由でDBに接続する

アプリサーバー（app）から見た 127.0.0.1:5432 で PostgreSQL 16 が動いている状態で試しました。

$ pg_isready -h 127.0.0.1 -p 7278
127.0.0.1:7278 - no response

$ ssh -F config -f -N -L 7278:127.0.0.1:5432 app

$ pg_isready -h 127.0.0.1 -p 7278
127.0.0.1:7278 - accepting connections

トンネルを張る前は応答がなく、張った後は手元の7278番からDBに届きました。ss -tlnp で見ると、手元の転送ポートを待ち受けているのは ssh プロセスです（下の -D の結果と同じ形になります）。

-R：接続先に手元のサーバーを見せる

手元の 127.0.0.1:7276 で、internal api: ok と返すだけのHTTPサーバー（python3 -m http.server）を動かして試しました。

$ ssh -F config -f -N -R 7279:127.0.0.1:7276 app
$ ss -tlnp | grep ':7279'
LISTEN 0  128  127.0.0.1:7279  0.0.0.0:*  users:(("sshd",pid=19440,fd=5))

$ curl -s http://127.0.0.1:7279/
internal api: ok

-R では、待ち受けているのが接続先の sshd になります。-L との向きの違いがプロセス名からも確認できます。

-D：SOCKSプロキシ

$ ssh -F config -f -N -D 7279 app
$ ss -tlnp | grep ':7279'
LISTEN 0  128  127.0.0.1:7279  0.0.0.0:*  users:(("ssh",pid=19493,fd=3))

$ curl -s --socks5-hostname 127.0.0.1:7279 http://127.0.0.1:7276/
internal api: ok

ポートが使用中のとき（ExitOnForwardFailure）

$ ssh -F config -N -L 7279:127.0.0.1:7276 app
channel_setup_fwd_listener_tcpip: cannot listen to port: 7279
Could not request local forwarding.
（接続自体は続き、転送のないまま待ち続ける）

$ ssh -F config -o ExitOnForwardFailure=yes -N -L 7279:127.0.0.1:7276 app
channel_setup_fwd_listener_tcpip: cannot listen to port: 7279
Could not request local forwarding.
（終了コード 255 ですぐ終了）

ExitOnForwardFailure yes を付けると、転送できなかったときにすぐ終了します。スクリプトや -f でトンネルを張るときに付けておくと、「つながっているのに転送されていない」状態に気づけます。

ControlMaster で2回目以降の接続を速くする

$ time ssh -F cm.conf app-cm true
real    0m0.220s      ← 1回目（新しく接続）

$ time ssh -F cm.conf app-cm true
real    0m0.008s      ← 2回目（親接続を使い回し）

$ ssh -F cm.conf -O check app-cm
Master running (pid=19878)

$ ssh -F cm.conf -O exit app-cm
Exit request sent.

2回目は0.220秒から0.008秒になりました。Ansibleや、scp・rsyncを何度も実行する作業で効果があります。LocalForward を書いたホストでは、-O exit で親接続を閉じると転送も止まることも確認しました。

ControlPath too long

ControlPath を深いフォルダに置いたところ、次のエラーになりました。

ControlPath too long ('（長いフォルダ名）/cm/735909a1579b229deb5d7595789379b7f4eacafa' >= 108 bytes)

ControlPath はUnixドメインソケット（プロセス間通信用のファイル）なので、パスの長さに上限（Linuxで108バイト）があります。~/.ssh/cm/%C のように短い場所に置くと解決します。

よくあるエラーと対処

Bad owner or permissions

$ ls -l ~/.ssh/config
-rw-rw-rw- 1 root root 652 Sep 29 15:08 /root/.ssh/config
$ ssh bastion true
Bad owner or permissions on /root/.ssh/config

~/.ssh/config は、自分以外が書き込めるとsshが読み込みを止めます。所有者が別のユーザーになっている場合も同じエラーでした。chmod 600 ~/.ssh/config で直ります。なお、このチェックは ~/.ssh/config に対して行われ、-F で指定したファイルには行われませんでした。

UNPROTECTED PRIVATE KEY FILE

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '（検証用フォルダ）/loosekey' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

秘密鍵は chmod 600 にします。この鍵は無視され、ほかの鍵で認証が続きます。

Too many authentication failures

ssh-agent に鍵を6本登録した状態で、IdentitiesOnly のあり・なしを比べました。

$ ssh-add -l | wc -l
6
$ ssh -F many.conf bastion-a true          # IdentitiesOnly なし
Received disconnect from 127.0.0.1 port 7270:2: Too many authentication failures
Disconnected from 127.0.0.1 port 7270

$ ssh -F many.conf bastion-b 'echo ok'     # IdentitiesOnly yes
ok

sshd は既定で1接続あたり6回（MaxAuthTries 6）まで認証を試せます。エージェントの鍵が先に試されて上限に達すると、正しい鍵まで届きません。IdentitiesOnly yes で使う鍵を絞ると解決します。

Permission denied (publickey)

$ ssh -F config -o User=nosuchuser bastion true
nosuchuser@127.0.0.1: Permission denied (publickey).

ssh -v で「どの鍵を試したか（Offering public key）」を見ると、原因を絞り込めます。ユーザー名、IdentityFile のパス、サーバー側の ~/.ssh/authorized_keys に公開鍵が登録されているか、の順に確認します。

Windows（OpenSSH）での違い

VS Code の Remote - SSH も同じ ~/.ssh/config を読むので、ここで書いた踏み台の設定がそのまま使えます。

安全に使うためのチェックリスト

よくある質問

Q. ProxyCommand と ProxyJump はどちらを使えばよいですか？ A. OpenSSH 7.3 以降なら ProxyJump がおすすめです。1行で書け、多段もカンマ区切りで書けます。検証でも、内部では ssh -W を使った ProxyCommand に変換されていました。

Q. 設定が効いているか確認する方法は？ A. ssh -G ホスト名 で、実際に使われる値を一覧できます。接続はしないので安全です。接続の流れを見たいときは ssh -v を使います。

Q. 同じ項目を後から書いたのに反映されません。 A. ssh configは最初に決まった値が使われます。具体的なホストを上に、Host * を一番下に書くと意図どおりになります。

まとめ

• ssh configは~/.ssh/config（Windowsは C:\Users\ユーザー名\.ssh\config）に書き、権限は600
• Host に呼び出し名、HostName に実際の接続先。scp・rsync・git も同じ設定を使う
• 設定は最初に一致した値が有効。具体的なホストを上、Host * を最後、Include はファイルの先頭
• 踏み台は ProxyJump bastion、多段は ProxyJump bastion,app。踏み台に鍵を置かずに済む
• -L は手元で待ち受け、-R は接続先で待ち受け、-D はSOCKS。ExitOnForwardFailure yes で失敗に気づける
• ssh -G で最終的な設定、ssh -v で接続の流れを確認する
• 認証エラーは IdentitiesOnly yes と ファイル権限の見直しで多くが解決する

株式会社RJCでは、踏み台やトンネルのような日々の接続の工夫も、実際に試した結果を仲間と共有しています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。