通过SSH批量连接VSTS仓库及会话超18个时出现启动失败错误

I've run into this exact issue before when dealing with bulk operations against Azure DevOps (formerly VSTS) via SSH. Let's break down what's happening and how to fix it:

Root Cause #

Azure DevOps enforces a default limit of 18 concurrent SSH sessions per user. When you exceed this threshold—whether by trying to connect to multiple repos simultaneously or running a bulk clone with more than 18 parallel processes—the server will reset the connection, leading to the errors you're seeing:

• ssh_exchange_identification: read: Connection reset by peer
• ERROR -> Failed to start SSH session: Failed getting banner
• Exit code 128 during bulk clones

Fixes & Workarounds #

1. Limit Concurrent Operations

The simplest fix is to cap the number of parallel SSH-based tasks (like clones, pulls, etc.) at 17 or fewer to stay under the session limit. For example:

• If using xargs to run bulk clones, specify the parallelism flag:

  cat repo-list.txt | xargs -P 15 git clone
  

  The -P 15 ensures only 15 clones run at once, well under the 18 limit.
• In custom scripts, use process control logic to restrict parallel execution counts.

2. Enable SSH Connection Reuse

Instead of creating a new SSH session for every repo operation, configure SSH to reuse existing connections. This drastically reduces the number of active sessions:

1. Edit your SSH config file (~/.ssh/config—create it if it doesn't exist)
2. Add these lines for Azure DevOps:

   Host dev.azure.com
     ControlMaster auto
     ControlPath ~/.ssh/sockets/%r@%h-%p
     ControlPersist 600s
   

   • ControlMaster auto: Automatically creates a master connection for subsequent requests
   • ControlPath: Defines where to store the connection socket file
   • ControlPersist: Keeps the master connection alive for 10 minutes (adjust the value as needed)
3. Create the sockets directory if it doesn't exist:

   mkdir -p ~/.ssh/sockets
   

With this setup, all your SSH operations against Azure DevOps will share a single master session, so even 100+ clone tasks won't hit the 18-session limit.

3. Clean Up Idle Sessions

If you have lingering idle SSH sessions taking up slots, you can manually close them:

ssh -O exit dev.azure.com

This terminates the master control connection and frees up the session slot.

Verification #

After applying either of these fixes, try your bulk operation again—you should no longer see the "Failed to start SSH session" errors or exit code 128.

内容的提问来源于stack exchange，提问作者Anudeep