2026 クラウド Mac SSH MaxStartups とソース別スロットリング：共有 Apple Silicon を守り、チームを締め出さない

1 台のレンタル Apple Silicon クラウド Mac に多数の請負者と自動化が乗ると、「接続リセット」チケットの多くはネット障害ではなく sshd の准入制御が強すぎるか、逆に無防備な状態です。本手順書の結論：同時接続ピークを測り、MaxStartups と PerSourceMaxStartups に明示的な数値目標を置き、sudo sshd -t で検証し、ロールバック用ハッシュを CMDB のリース ID と同じチケットに残す。ディレクティブ比較表、例となる基線（10:30:100 形式の MaxStartups 曲線）、macOS launchd 向け 9 ステップ、CI/NAT の注意、香港・東京・ソウル・シンガポール・米国の MacLogin リージョンに沿った FAQ をまとめました。スロットリングは観測可能な指標とセットで初めて運用に耐えます。

アイドルセッションを嵐と見なさないよう keepalive・切断のトラブルシュート と併用し、引き継ぎは 共有 SSH セッションのガバナンス で整理、ブルートフォース雑音は 鍵ローテーションと 2FA で先に下げます。接続の基本は MacLogin ヘルプ、プラン比較は 料金ページ を参照してください。オフィス NAT とセルフホスト Runner が同一出口を共有する構成では、PerSource を人員ベースだけで決めるとリリース週に行列ジョブだけが落ちるパターンが出やすい点に注意してください。

信頼できる CI 出口 CIDR が分かっている場合は、グローバル既定より前に Match Address で寛容な PerSource を置くと、セキュリティ監査でも「意図した例外」と説明しやすくなります。逆にグローバルだけ広げてソース制限がないと、単一 IP からの未認証握手で CPU とログパイプラインが圧迫されます。本稿はそのバランスを数値と手順で固定することを目的としています。

レンタルクラウド Mac で MaxStartups を文書化すべきチーム

1 つのパブリック IPv4 のビルドホストを人間と自動化が共有するなら、准入の上限は運用資産にすべきです。目標がないと、攻撃者の並列パスワード試行で CPU が飽和するか、善意のプラットフォーム担当が PerSource を厳しすぎて企業 NAT 越しの CI だけが黙って失敗します。

• 請負者の多い iOS 組織：リリース週に ssh / scp / rsync が同時に走る。
• SecOps レビュー：接続洪水時の公平性をどう証明するか——スロットル設定とログが物語を裏付けます。
• FinOps：未認証握手の山で steal time が跳ねると、失敗した認証でもコストと体感が悪化します。

Wi-Fi のせいにする前に MaxStartups を疑う兆候

1. 営業時間帯にランダムな「リモートホストが接続を閉じた」：RTT は安定しているのに新規 TCP だけが捨てられる典型例です。
2. 負荷のスパイク：認証済みセッションは少ないのに sshd が上位——握手ストームが CPU を消費しています。
3. CI の不安定さ：同一出口 IP のジョブだけ失敗し、ノートユーザーは成功——PerSource の見積もり不足の可能性があります。
4. 監査の「並列 SSH に上限は？」：コンプライアンスは感覚ではなく数値を求めます。

ディレクティブ比較：各つまみが何を制限するか

ディレクティブ	制限対象	典型ミス	相性の良い対策
MaxStartups	グローバルな未認証 SSH 接続（握手キュー）	グローバル最大だけ設定し IP ごとの公平性を忘れる	PerSourceMaxStartups と FW レート制限
PerSourceMaxStartups	同一クライアント IP からの並列握手	オフィス NAT 前提の値を CI バーストに流用	信頼 CIDR には Match で別上限
MaxSessions	1 TCP 接続あたりの多重化セッション	全クライアントの総セッションと混同	内部 Wiki に ControlMaster 方針を明記
MaxAuthTries	接続あたりのパスワード試行	分散スプレーまで止まると期待する	鍵のみポリシーと SIEM への集約ログ

小規模共有リース向けの例示基準（助言であり法的助言ではありません）

表は 10〜25 名規模のエンジニア と軽量 CI を想定しています。必ず自社ヒストグラムで検証してください。

プロファイル	MaxStartups	PerSourceMaxStartups	MaxSessions	要約
人間のみ	10:30:60	8	10	VPN 再接続の握手バーストを平準化
人間 + CI NAT	20:50:200	32	20	マトリックス Runner を許容しつつ単一 IP 洪水にはペナルティ
高セキュリティ	5:15:40	4	6	誤検知増——バスチオンとセットで

MacLogin クラウド Mac 向け 9 ステップ

1. スナップショット：/etc/ssh/sshd_config と sshd_config.d/*.conf を設定リポジトリへ。チケット SSH-THROTTLE-2026。
2. 計測：営業日 15 分 ごとに ps -ax | grep sshd | wc -l をサンプリング。
3. Match 草案：CI 出口 CIDR が分かれば、グローバル既定より前に Match Address で寛容な PerSource を配置。
4. 編集：MaxStartups / PerSourceMaxStartups / MaxSessions を変更し、旧値は監査用にコメントで残す。
5. 構文：sudo sshd -t の終了コード 0 を確認。
6. カナリア：リロード中も予備の認証済みセッションを 1 本維持——単一ウィンドウだけに頼らない。
7. リロード：告知済みウィンドウで sudo launchctl kickstart -k system/com.openssh.sshd。
8. ソーク：ノートと CI の 2 IP から各 20 並列接続を投げ、TCP 握手が 3 秒 を超えて停滞しないことを確認。
9. クローズ：変更前後のスタンザ、UTC タイムスタンプ、保存 tarball へのワンライナーロールバックを添付。

単純な PerSource 上限を破る CI・バスチオン・NAT

GitHub ホスト Runner の IP は変わりやすい一方、企業 NAT 背後のセルフホスト Runner は 50 並列ジョブでも外向きは 1 アドレスに見えることがあります。グローバル MaxStartups を厳しく保つなら、自動化専用バスチオンに独自の Match を置くか、MacLogin リースを 2 台に分けて握手予算を足し算してください。

エンジニアが VNC で GUI デバッグする場合も、画面共有は sshd 准入ログの代替になりません——sshd の切断理由は SIEM で引き続き解析すべきです。

FAQ

sshd の各行を顧客ポータルに載せるべき？ IaC で管理し、顧客には遅延と可用性など結果指標を見せるのが現実的です。

WAF の代わりになる？いいえ。SSH スロットリングはデーモン層、WAF は別レイヤの HTTP フロントを守ります。

見直し頻度は？四半期ごと、または請負者が 30% を超える増員があった直後。

MaxStartups を下げればパスワードブルートフォースは止まる？緩和にはなりますが鍵認証・FW・fail2ban 型ポリシーの代替にはなりません。MaxAuthTries と承認済みロック方針と併用してください。

PerSource が低すぎると CI は？同一 NAT からのマトリックスが 1 ソースに見えることがあります。Runner サブネットのピーク同時接続を先に測ってください。

sshd_config の場所は？多くの場合 /etc/ssh/sshd_config と /etc/ssh/sshd_config.d/。リロード前に sudo sshd -t、macOS では launchctl を優先。

MacLogin 上の Mac mini M4 ならスロットル検証が「再現しやすい」わけ

Apple Silicon Mac mini はコアあたりの暗号握手性能が予測しやすく、MaxStartups の実験グラフが x86 のターボ揺らぎに汚されにくいです。香港・東京・ソウル・シンガポール・米国都市圏に展開する MacLogin では、リースを CI 出口に近いリージョンへ置けば RTT 分散が小さくなり、本当の原因が PerSource の厳しさなのにタイムアウトを WAN のせいにする誤診を減らせます。レンタルなら sshd テンプレを地域横断で複製し、リロード順をリハーサルし、握手の上限が「チケット付きの設計」だったことを監査に示しやすく、デスク下の一時マシン頼みになりません。

攻めたスロットル検証用に隔離境界が欲しければ 料金ページ からノードを追加し、指標が 14 日 連続安定してから本番クラスへ昇格してください。