Claude Prompt for an SSH Automation Toolkit

What this prompt does

This prompt builds an SSH automation toolkit for managing [server_count] servers across [environment_list]. It generates a ~/.ssh/config from a YAML inventory grouped by environment, rotates Ed25519 keys by distributing new public keys via [current_access_method] and verifying connectivity, provides ssh-batch.sh to run commands in parallel with a [max_parallel] concurrency cap and per-host summary, configures ProxyJump bastion chains for [jump_topology], manages auto-reconnecting tunnels for [tunnel_services], and hardens the SSH client config.

The variables scale the toolkit to your fleet. [server_count] and [environment_list] shape the generated config and grouping, [max_parallel] bounds how aggressively batch commands run, and [jump_topology] plus [tunnel_services] describe how you reach private-subnet hosts. The key-rotation step uses [current_access_method] to push new keys before removing old ones, so you don't lock yourself out mid-rotation. Treating the YAML inventory as the single source of truth is the quiet win here: instead of a hand-edited config that drifts per machine, you regenerate it deterministically, and the same inventory feeds batch execution, bastion chains, and tunnel definitions so everything stays consistent across [environment_list].

When to use it

• You are past a handful of boxes and hand-editing ~/.ssh/config no longer scales
• Generating SSH config from a YAML inventory grouped by environment
• Rotating Ed25519 keys across many servers with connectivity verification
• Running commands on many hosts in parallel with a concurrency cap
• Reaching private-subnet servers through ProxyJump bastion chains
• Maintaining persistent tunnels for [tunnel_services] with auto-reconnect

Example output

Expect a config generator that reads YAML and writes Host aliases grouped by [environment_list], a key-rotation script generating Ed25519 pairs and distributing them, an ssh-batch.sh running with a [max_parallel] cap and a success/failure summary per host, ProxyJump config for [jump_topology], a tunnel manager for [tunnel_services], and hardened client settings. Each is a focused script driven by the inventory.

Pro tips

• Verify connectivity after distributing new keys before removing old ones; the rotation order via [current_access_method] is what prevents a lockout
• Set [max_parallel] sensibly — too high and you hammer a shared bastion or trip rate limits, too low and large fleets crawl
• Keep the YAML inventory as the source of truth so ~/.ssh/config is regenerated, not hand-patched and drifting
• Define [jump_topology] to match reality (office to bastion to private subnet) so ProxyJump chains actually resolve
• For [tunnel_services], confirm the auto-reconnect logic backs off; a tight reconnect loop on a down service just spams connection attempts
• Harden the client config (disable agent forwarding by default, hash known_hosts, strict host key checking) so convenience features do not become a security hole
• Capture per-host success and failure from ssh-batch.sh rather than a single combined exit code; on a fleet of [server_count] machines you need to know exactly which hosts a command failed on, not just that something failed