Skip to content
DevOps AI ToolKit
Newsletter
All prompts
AI for DevOps Security & Hardening Difficulty: Beginner ClaudeChatGPT

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]
```

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

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

  1. Run sudo grep -vE "^#|^$" /etc/ssh/sshd_config | sort and paste the output.
  2. Run sudo cat /home/*/.ssh/authorized_keys 2>/dev/null (or check specific users) — paste relevant entries.
  3. Specify context: a bastion has different threat model than an internal app server.
  4. Before applying any change: open a second SSH session, run sudo sshd -t on the new config, then sudo systemctl reload ssh. Verify in a NEW session before closing your existing ones.
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 audit
  • lynis — 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

  1. Open a NEW SSH session.
  2. sudo sshd -t (test the config).
  3. sudo systemctl reload ssh.
  4. In a THIRD session, try to log in fresh.
  5. Only after step 4 succeeds, close the original session.

Related prompts

More DevOps Security & Hardening prompts & error guides

Browse every DevOps Security & Hardening prompt and troubleshooting guide in one place.

Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.