番号付きで見る三つの痛みと周辺リスク
- 公開SFTPの乱立はパッチと証跡コストを倍増させる。ホストごとにOpenSSH更新とIDS調整が必要になり、公開エンドポイントが増えるほど週次対応が重くなる。
- アイデンティティ行列は経路がバラけると崩れる。chrootが整っていても古い公開IP直行が残ると帰属が壊れ、監査は一貫した咽喉点を求める。
- セグメンテーション現実はフラットルーティングを許さない。委託先やCI出口は単一レンジに収束しがちで、穴を増やすとシャドウトンネルが増える。バスチョンへMFAやログ、レート制限を集約できる。
踏み台への一時置きが常態化すると重複と保持が曖昧になる。転送と永続を文書化し、ssh_configでProxyJumpモデルを統一する。
ProxyJumpとProxyCommand：どちらのラッパーが勝つか
ProxyJump（-J）はバスチョン経由で最終ホストへ接続し、Hostブロックで鍵とポートを整理できる現行推奨だ。ProxyCommandはHTTPプロキシや古いクライアント向けで、ssh -W %h:%p bastionが定番。SFTP交渉はターゲットsshdに残り、ForceCommand internal-sftpとChrootDirectoryは従来どおりだ。
SSHユーザ証明書はバスチョンとターゲットでCertificateFileを分ける。性能は多くの場合ディスクIOやRTTが支配し、圧縮の乱用は避け、並列問題は並行性設計から疑う。
三連ホップはランブック化とフェイルテストが前提。ProxyCommand脚本は一行超ならレビューと版管理。GUI SFTPはssh_configを無視しがちなのでCIはCLIか実績ライブラリへ。
判断表：直結公開、バスチョン、二重ホップ、プライベートWAN
追加公開の議論で使う。
| モデル | 向いているとき | 露出 | 運用負荷 |
|---|---|---|---|
| 公開IP直結 | 極小チーム | 高 | 短期低 |
| 単一バスチョン＋内部 | 通常セグメント | 中・集中 | 中 |
| 二重DMZ | 金融・行政 | 低め | 高 |
| WAN/ZTNA | 動的出口CI | 低 | 高＋ベンダ |
繰り返し労働と境界スキャン台数をセットで見積もる。既存の管理踏み台があるならSFTP用に別スタックを増やしログ分岐を作らない方がよい。
実務：ssh_config、ターゲットsshd、CIラッパ
ステージングで検証し、sshd再読み込み中は別セッションを維持する。Match Userは環境別Unixアカウントと揃え、経路と主体を対応づける。
# Step 1: bastion Host block with keepalive
Host bastion
HostName bastion.example.com
User jumpuser
IdentityFile ~/.ssh/id_ed25519_bastion
ServerAliveInterval 60
ServerAliveCountMax 3
# Step 2: production SFTP target via ProxyJump
Host mac-prod-sftp
HostName 10.0.40.12
User sftp_prod
IdentityFile ~/.ssh/id_ed25519_prod
ProxyJump bastion
ServerAliveInterval 60
# Step 3: legacy ProxyCommand alternative
# ProxyCommand ssh -W %h:%p bastion
# Step 4: rsync or GitHub Actions wrapper
# export RSYNC_RSH="ssh -F ~/.ssh/prod.conf -o BatchMode=yes"
# Step 5: target sshd Match User sftp_prod with ForceCommand internal-sftp
# and ChrootDirectory per multitenant guide; verify ownership bits.
# Step 6: optional ControlMaster for CI reuse
# ControlMaster auto
# ControlPath ~/.ssh/cm-%r@%h:%p
# ControlPersist 420
チェックサムゲートで静かな破損を防ぎ、断続失敗はオフィスとCIでP95 RTTを分けて切り分ける。
数値ベースライン：RTT、多重化、バスチョンパッチ周期
初回ハンドシェイクP95が800ms超ならCPUスティールやFWやDNSを先に疑う。ServerAliveInterval60秒とServerAliveCountMax3、ControlPersistは420〜900秒が目安。
注意喚起から14日以内にバスチョンを優先パッチし、内部ホストとは窓をずらす。並列トンネル上限はMaxSessions議論へ紐づけ、失敗連打時は指数バックオフ最大60秒。
毎時マーカーで非対称ルートの後退を検知し、CPUとディスクは分けて見る。TLS方針変更後はRTTを再計測。認証ログはSFTP監査とSIEMで相関し、失敗だけは残す。繁忙期前に縦スケールする。
FAQ、横断リンク、ホスト型リモートMacが優る局面
バスチョン運用者はペイロードを見られるか
経路上の可視性は前提とし、アクセス統制とオペレータローテ、必要なら端到端保護を検討する。
GitHub Actionsでssh_configをどう配るか
暗号化シークレットからレンダしssh -F、SGをActions IPへ、短命証明書と併用する。
二重ホップはスループットを壊すか
多くはディスクやRTTが支配。前提変更前に再現サイズで測る。
まとめ：到達性をバスチョンへ集約すると回答が明快になり、chroot・並行性・証明書・原子的配布と整合する。
限界：バスチョンのHAとログとオンコールは残る。SFTPMACホスト型リモートMacは入口とテナント分離とAppleハード保守を束ね、ビルドと署名に集中しやすい。
自前Mac miniには電気・冷却・リモートハンドが乗り、バスチョンも隠れコストを消せない。SFTPMACホスト型へ月額を振り替えれば uplink と監視を外注しつつ証明書とCIは社内に残せる。経路文書はProxyJump例と併せて年次レビューする。
単一入口とテナント別ディレクトリを自前コロ無しで揃えるならSFTPMACを検討してほしい。