SSH Security Audit Prompt
Audit sshd_config, authorized_keys, and SSH client config — flag insecure defaults, weak algorithms, missing controls.
- Target user
- Sysadmins and SREs auditing SSH security on Linux servers
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT
The prompt
You are a senior Linux security engineer with deep experience hardening SSH for production servers and jump hosts. You know which SSH settings actually matter versus which are cargo-culted. Audit the SSH configuration I share. Apply this checklist: ### sshd_config (server-side) 1. **Authentication** - `PermitRootLogin no` (or `prohibit-password` if root-key login is required)? - `PasswordAuthentication no`? - `ChallengeResponseAuthentication no`? - `KbdInteractiveAuthentication no`? - `PubkeyAuthentication yes`? - `PermitEmptyPasswords no`? - `MaxAuthTries 3` or lower? 2. **Crypto** - `Protocol 2` (no SSH1)? - Strong KexAlgorithms? Should explicitly disable `diffie-hellman-group1-sha1`, `diffie-hellman-group14-sha1`. - Strong Ciphers? Prefer `chacha20-poly1305@openssh.com`, `aes256-gcm@openssh.com`, `aes128-gcm@openssh.com`. - Strong MACs? Prefer `hmac-sha2-512-etm@openssh.com`, `hmac-sha2-256-etm@openssh.com`. Disable `hmac-md5*` and any non-ETM variants. - HostKeyAlgorithms: disable ssh-dss, ssh-rsa (SHA1) — prefer ssh-ed25519, rsa-sha2-512/256. 3. **Session & access controls** - `AllowUsers` or `AllowGroups` restricting who can log in? - `ClientAliveInterval 300` and `ClientAliveCountMax 0` (or similar — auto-disconnect idle sessions)? - `LoginGraceTime 60` (no indefinite login attempts)? - `X11Forwarding no` unless needed? - `AllowAgentForwarding no` unless needed? - `AllowTcpForwarding no` unless needed? - `PermitTunnel no` unless needed? 4. **Banners & logging** - `LogLevel VERBOSE` (or INFO minimum)? - `Banner /etc/issue.net` set with legal warning? - `Subsystem sftp internal-sftp -l VERBOSE -f AUTH` for sftp audit logging? ### authorized_keys files - Key types: ed25519 or RSA 4096+, no DSA, no RSA <2048? - Any keys missing `from=`/`command=`/`restrict` options where they should be scoped? - Any forwarded-agent or port-forwarding options that shouldn't be there? - Are old/unused keys still present? ### Client-side ssh_config (optional) - Does `~/.ssh/config` use sane defaults: `HashKnownHosts yes`, no `StrictHostKeyChecking no`? --- For each finding: **severity**, **file:line**, **issue**, **fix command** with rollback. Server context: - Internet-facing? [yes/no] - Bastion / jump host? [yes/no] - Multi-user host? [yes/no] - OS: [Ubuntu / RHEL / etc.] sshd_config: ``` [PASTE — output of `grep -vE "^#|^$" /etc/ssh/sshd_config`] ``` authorized_keys (anonymize comment fields if needed): ``` [PASTE — output of `cat /home/*/.ssh/authorized_keys` or specific accounts] ```
Why this prompt works
SSH misconfigurations cause real breaches and real lockouts in roughly equal measure. This prompt forces the model to check both the obvious settings (PermitRootLogin) and the subtle ones (KexAlgorithms, ETM MACs) that scanners flag in compliance audits.
How to use it
- Run
sudo grep -vE "^#|^$" /etc/ssh/sshd_config | sortand paste the output. - Run
sudo cat /home/*/.ssh/authorized_keys 2>/dev/null(or check specific users) — paste relevant entries. - Specify context: a bastion has different threat model than an internal app server.
- Before applying any change: open a second SSH session, run
sudo sshd -ton the new config, thensudo systemctl reload ssh. Verify in a NEW session before closing your existing ones.
Recommended baseline sshd_config (Ubuntu 24.04 / RHEL 9)
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 0
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
LogLevel VERBOSE
Banner /etc/issue.net
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
Subsystem sftp internal-sftp -l VERBOSE -f AUTH
AllowGroups ssh-users
Pair this with
ssh-audit— automated SSH server auditlynis— broader Linux hardening including SSH- Fail2ban or sshguard — runtime brute-force protection
- A bastion / jump host architecture — don’t let every server be reachable directly
What to do AFTER tightening sshd_config
- Open a NEW SSH session.
sudo sshd -t(test the config).sudo systemctl reload ssh.- In a THIRD session, try to log in fresh.
- Only after step 4 succeeds, close the original session.
Related prompts
-
Linux Server Hardening Prompt
Walk an AI through a CIS-style hardening review of a Linux server — services, users, SSH, kernel parameters, file permissions — with safe, ordered remediation.
-
Linux Server Troubleshooting Prompt
Help diagnose CPU, memory, disk, network, and service issues on Ubuntu or RHEL servers from raw command output.
-
Sudoers & Systemd Services Review Prompt
AI review of /etc/sudoers (and /etc/sudoers.d/*) and systemd service unit files for privilege escalation, unsafe defaults, and hardening gaps.