Claude/ChatGPT Prompt to Set Up Passwordless SSH Cleanly

What this prompt does

This prompt makes the model a senior Linux engineer and asks for exact commands and config snippets to set up key-only SSH across multiple servers — explicitly keeping you from locking yourself out. You set [server_count], [local_os], [aliases], and [key_identity], and it returns ed25519 key generation, key distribution with ssh-copy-id and verification, a ~/.ssh/config block using your aliases, server-side sshd_config changes to disable password auth, and fail2ban as a safety net.

The structure works because the fastest way to ruin an afternoon is disabling password auth before confirming your key works, so the prompt enforces verify-before-lockdown ordering. [key_identity] becomes the key comment so you can tell keys apart later, [aliases] populate the SSH config with HostName, User, IdentityFile, and IdentitiesOnly entries, [local_os] decides how the key loads into the agent or keychain, and [server_count] scopes the distribution step. Because the output is ordered commands and config snippets in the safe sequence to run them — generate, distribute, verify, then lock down — you can work through it top to bottom without having to reason about which step might strand you. The IdentitiesOnly flag in the config also stops the agent from offering every key and tripping over server limits.

When to use it

• You're moving a fleet of servers from password to key-only SSH.
• You want the verify step to come before the lockdown step, every time.
• You need a clean ~/.ssh/config with friendly host aliases.
• You're generating an ed25519 key and loading it into your OS keychain or agent.
• You want password auth disabled with the reload order that prevents lockout.
• You want fail2ban and a one-line recovery path as safety nets.

Example output

Expect numbered commands and config snippets in fenced blocks, ordered so the safe steps come first: ed25519 key generation with your identity comment, loading it into the agent or keychain for your OS, ssh-copy-id distribution with a login verification before any server change, a ~/.ssh/config block using your aliases, the sshd_config edits plus the reload command in lockout-safe order, and fail2ban setup with a recovery path.

Pro tips

• Set [key_identity] to something meaningful like deploy@laptop so you can identify the key later in authorized_keys.
• List your real [aliases] so the SSH config maps directly to how you refer to each host.
• Match [local_os] to your actual machine; loading a key into the macOS keychain differs from a Linux agent.
• Follow the order exactly — verify key login works before you touch sshd_config, as the prompt enforces.
• Keep one SSH session open while you flip password auth off, so you have a way back in if something's wrong.
• Confirm fail2ban isn't about to ban your own IP before you rely on it as the safety net.
• Use IdentitiesOnly yes in each config block so the agent presents only the right key, avoiding too-many-auth-failures rejections on busy fleets.
• Note the one-line recovery path before you start; knowing how to get back in turns a scary lockdown into a routine change.