Skip to content
CloudOps
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]
```

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

Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.