12 Agent Prompts Installation

Agent Prompts: Installation

Copy-paste prompts for an AI agent with shell access to a Linux host. Each prompt is self-contained: context, guardrails, steps, verification and the report format to return.

---

How to use

1. Replace every <PLACEHOLDER> (<API_KEY>, <JAILS>, <SERVER_IP>, …).
2. Give the agent shell access to the target host and the repository URL.
3. Paste the universal guardrails first (or as the system preamble), then the task prompt.
4. Require the agent to stop and ask if a check fails — not to "fix it creatively".

Do not paste a real API key into a chat with a cloud model if your policy forbids it. Prefer letting the installer prompt on the host (sudo ./install.sh in an interactive terminal), or put the key into a file first and pass --api-key-file. If a key does end up in a transcript, rotate it afterwards.

Universal guardrails (paste before any prompt)

You are operating on a production Linux server. Follow these rules strictly:

- Work step by step. Before each destructive or irreversible action: state what you will do,
  take a backup, and verify the backup exists.
- Never print, log, commit or send the AbuseIPDB API key. When a command needs it, read it from
  /etc/abuseipdb/.abuseipdb.key or an environment variable; mask it in your report (first 6 and
  last 4 characters only).
- Never test a fail2ban ban with the server's own management IP or with your own SSH source IP.
  Use documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) and unban immediately,
  or queue a real attacker address from the logs.
- Never edit /etc/fail2ban/jail.conf (package-managed). Put overrides in jail.d/99-*.local.
- Always run `fail2ban-client -t` before restarting fail2ban. If it fails, stop and report.
- Do not change authentication hardening (SSH passwords, root login) unless the task explicitly
  asks for it; when it does, keep one session open and verify in a second one.
- Do not delete files or databases. If removal is required, list the exact paths, back them up,
  and ask for confirmation.
- Report facts you verified; mark anything you could not verify as "not verified".

---

Prompt 1 — Fresh installation with verification

Task: install Fail2Ban_AbuseIPDB on this Linux host and prove it works end to end.

Repository: https://github.com/paulmann/Fail2Ban_AbuseIPDB
Jails to attach: <JAILS>            # example: sshd nginx-attack-scan nginx-wp-login
API key: <API_KEY>                  # if empty, use the interactive prompt or --api-key-file
Reporting server label: <SERVER_IP> # optional, shown in the report comment

Constraints:
- The API key must end up ONLY in /etc/abuseipdb/.abuseipdb.key (mode 600), never in the config,
  shell history, logs or your output. Mask it in every message.
- The API key time window: the free AbuseIPDB plan allows 1000 reports+checks per day.
  Use at most 2 check requests during this task.

Steps:
1. Pre-flight: uname -a, cat /etc/os-release, python3 --version, fail2ban-client --version,
   fail2ban-client status, systemctl is-active fail2ban. Stop if Python < 3.9 or fail2ban is absent.
2. Back up fail2ban config: cp -a /etc/fail2ban /root/fail2ban-backup-$(date +%Y%m%d-%H%M%S).
3. Clone the repository to /tmp/Fail2Ban_AbuseIPDB and run:
     sudo ./install.sh --api-key "<API_KEY>" --jails "<JAILS>" --skip-api-check
   (skip the online check now; we will verify the key explicitly in step 5).
4. Verify the installation:
     ls -l /etc/abuseipdb/.abuseipdb.key           # mode 600
     grep -E '^api_key(_file)? =' /etc/abuseipdb/reporter.conf
     /usr/local/sbin/abuseipdb-report --key-status # source = key file, key masked
     for j in <JAILS>; do fail2ban-client get $j actions; done
     systemctl list-timers abuseipdb-report.timer
5. Validate the key online: /usr/local/sbin/abuseipdb-report --check-key   (expect HTTP 200)
6. Queue a REAL attacker address from the logs (not your own IP):
     journalctl -u ssh --since "-24 hours" | grep "Failed password" | tail -1
     /usr/local/sbin/abuseipdb-enqueue --ip <found IP> --jail sshd --bantime 86400 --failures 4
     /usr/local/sbin/abuseipdb-report --dry-run      # inspect payload, no API call
     /usr/local/sbin/abuseipdb-report                # send it (one report)
7. Confirm the log line contains "-> 200" and the queue is empty afterwards
   (/usr/local/sbin/abuseipdb-report --stats).
8. Confirm the attribution footer is in the payload (unless the task disabled it).

Stop immediately and report if: fail2ban-client -t fails, the key file is missing or has wrong
permissions, --check-key is not 200, or a report returns 401/422.

Return: enabled jails, key file path/mode, check-key HTTP code, the dry-run payload (masked),
report result, and anything you could not verify.

---

Prompt 2 — Install on a host with existing fail2ban jails

Task: add Fail2Ban_AbuseIPDB reporting to an existing fail2ban setup without changing its
current thresholds or risking access.

Existing jails to attach: <JAILS>
API key: <API_KEY>

Constraints:
- Do NOT edit /etc/fail2ban/jail.conf or change existing maxretry/findtime/bantime.
- The installed action must be the only addition: /etc/fail2ban/jail.d/50-abuseipdb-reporter.local.
- Keep an SSH session open; never test bans with your own IP.

Steps:
1. Record the current state: fail2ban-client status, fail2ban-client get <jail> actions for every
   jail in <JAILS>, and copy /etc/fail2ban to /root/fail2ban-backup-<timestamp>.
2. Check that your management IP is in ignoreip:
     fail2ban-client get sshd ignoreip
   If it is missing, stop and ask the human to add it (do not add it yourself silently).
3. Clone the repository and run:
     sudo ./install.sh --api-key "<API_KEY>" --jails "<JAILS>" --skip-api-check
   The installer keeps reporter.conf if it exists and preserves an existing key file.
4. Verify:
     fail2ban-client -t
     for j in <JAILS>; do fail2ban-client get $j actions; done   # must include abuseipdb-async
     fail2ban-client status
5. Verify no threshold changed:
     for j in <JAILS>; do fail2ban-client get $j maxretry; fail2ban-client get $j findtime; done
     (compare with the values you recorded in step 1)
6. Validate the key (one request): /usr/local/sbin/abuseipdb-report --check-key
7. Do NOT force a ban. Wait for a real ban, or ask the human for permission to use a
   documentation-IP test ban.

Return: before/after action lists and thresholds, key status (masked), check-key result, and any
jail that could not be attached.

---

Prompt 3 — Upgrade an existing installation with the self-updater

Task: update Fail2Ban_AbuseIPDB to the latest published version and prove that the API key,
configuration, queue and jail list were preserved.

Steps:
1. Record the current state:
     /usr/local/sbin/abuseipdb-report --version
     sha256sum /etc/abuseipdb/.abuseipdb.key
     sha256sum /etc/abuseipdb/reporter.conf
     /usr/local/sbin/abuseipdb-report --stats
     for j in $(fail2ban-client status | sed -n 's/.*Jail list:[[:space:]]*//p' | tr ',' ' '); do
       fail2ban-client get $j actions; done
2. Check for an update: /usr/local/sbin/abuseipdb-upgrade --check
   Expected exit codes: 0 = up to date, 10 = update available, 1 = error.
3. Back up the current installation state:
     mkdir -p /root/pre-update-$(date +%s)
     cp -a /etc/abuseipdb /root/pre-update-*/etc-abuseipdb
     cp -a /var/lib/abuseipdb/abuseipdb.sqlite3 /root/pre-update-*/ 2>/dev/null || true
4. If an update is available: sudo /usr/local/sbin/abuseipdb-upgrade --upgrade --yes
5. Verify after the update:
     /usr/local/sbin/abuseipdb-report --version           # new version
     sha256sum /etc/abuseipdb/.abuseipdb.key              # MUST equal the before value
     sha256sum /etc/abuseipdb/reporter.conf               # ideally unchanged
     /usr/local/sbin/abuseipdb-report --stats             # queue preserved
     fail2ban-client -t && fail2ban-client status
     /usr/local/sbin/abuseipdb-upgrade --check            # exit 0 now
6. Start the worker once to confirm it runs on the new code:
     systemctl start abuseipdb-report; tail -n 20 /var/log/abuseipdb-reporter.log

If the key checksum differs, stop, restore /etc/abuseipdb/.abuseipdb.key from the pre-update
backup, and report an incident. Do not rotate keys without human approval.

Return: before/after versions, key checksum comparison, queue stats, jail action lists,
update-check exit code, and the worker log tail.

---

Prompt 4 — Move the key into .abuseipdb.key and enable update checks

Task: migrate a legacy API key out of reporter.conf into the key file and enable the weekly
check-only update timer.

Steps:
1. Inspect: grep -nE '^api_key(_file)? =' /etc/abuseipdb/reporter.conf
   If api_key is empty and api_key_file is set, the migration is already done — report and stop.
2. Back up: cp -a /etc/abuseipdb/reporter.conf /root/reporter.conf.before-migration
3. Migrate: /usr/local/sbin/abuseipdb-report --migrate-key
4. Verify:
     ls -l /etc/abuseipdb/.abuseipdb.key                 # 600
     grep -nE '^api_key(_file)? =' /etc/abuseipdb/reporter.conf
     /usr/local/sbin/abuseipdb-report --key-status        # source = key file
     /usr/local/sbin/abuseipdb-report --check-key         # HTTP 200 (one request)
5. Enable the weekly check: run the installer with --with-update-check (it preserves everything):
     sudo ./install.sh --with-update-check --skip-api-check
6. Verify: systemctl list-timers abuseipdb-upgrade-check.timer
7. Confirm the plaintext key is gone from the config: grep -c '<first 8 chars of the old key>' \
     /etc/abuseipdb/reporter.conf   # expect 0; do not print the key itself

Return: key file mode, source reported by --key-status, config lines, timer state, and the
check-key result.

---

Prompt 5 — Install with cron instead of systemd

Task: install Fail2Ban_AbuseIPDB on a host where the systemd timer is not wanted.

Steps:
1. Follow Prompt 1, but call:
     sudo ./install.sh --api-key "<API_KEY>" --jails "<JAILS>" --cron --skip-api-check
2. Verify: cat /etc/cron.d/abuseipdb-reporter
3. Run once manually: /usr/local/sbin/abuseipdb-report --stats
4. Confirm the per-IP throttle still applies (min_interval_ip = 1200 in reporter.conf) and note
   that cron */16 fires at :00,:16,:32,:48.

Return: cron file content, key status, first manual run result.

---

Prompt 6 — Safe uninstall or rollback

Task: remove Fail2Ban_AbuseIPDB from this host (or roll back a failed installation) without
breaking fail2ban and without losing the key unless explicitly requested.

Steps:
1. Record state: install state file /var/lib/fail2ban-abuseipdb/install-state, jail actions,
   current bans (fail2ban-client status), fail2ban -t.
2. Back up: /etc/fail2ban, /etc/abuseipdb, /var/lib/abuseipdb/abuseipdb.sqlite3.
3. Uninstall without purge:
     sudo /path/to/Fail2Ban_AbuseIPDB/install.sh --uninstall
   This keeps /etc/abuseipdb/reporter.conf, the queue and the key file.
4. Verify: fail2ban-client -t; fail2ban-client status; fail2ban-client get sshd actions
   (abuseipdb-async must be gone); the key file still exists.
5. Only if the human explicitly asked to destroy data, run --uninstall --purge (this deletes the
   key file, config and queue). Never run --purge on your own initiative.

Return: what was removed, what was kept, fail2ban state before/after, and the location of backups.

---

What to do when the agent gets stuck

Situation	Instruction
install.sh fails on fail2ban-client -t	restore the backup, report the exact error; do not "fix" fail2ban config blindly
no terminal for the key prompt	pass --api-key/--api-key-file, never hang on stdin
package manager / network unavailable	use the release archive already downloaded; the installer needs no package installs
key check fails	stop; do not retry in a loop (each check consumes quota)
agent wants to test a ban with its own IP	refuse; use a documentation IP or a real attacker IP from logs

---

Next: Fail2Ban setup prompts · Operations & audit prompts · Installation