skills/magnus919_agent-skills
1
0
Fork 0
mirror of https://github.com/magnus919/agent-skills.git synced 2026-09-11 19:47:12 +03:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #40 from magnus919/feat/skillopt-remote-systems-administration

Browse Source 
fix: SkillOpt remote systems administration hardening
This commit is contained in:
Magnus Hedemark
2026-07-13 13:36:19 -04:00
committed by GitHub
parent 3c4637c4cf a4233784ef
commit bb5a7d0033
2 changed files with 20 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
remote-systems-administration/SKILL.md
+14 -2
View File
@@ -21,11 +21,21 @@ Use this as an operating decision layer, not a bag of remote commands. Unix-like
4. **Preview, constrain, verify.** Limit the target set; use native validation, dry-run, diff, or a canary when available; then verify the affected service and its user-visible boundary. A zero exit code proves only that command ran.
5. **Report evidence, not a story.** Preserve bounded per-host results: target, command category, before/after evidence, failures, rollback state, and the remaining uncertainty. Never paste secrets, keys, full configuration files, or unbounded logs into the response.
## Read-only discovery handoff
Use this compact format after a preflight. Fill a field only from observed evidence; otherwise write `unknown` or `not supplied`.
- **Target and scope:**
- **Observed platform and control planes:**
- **Bounded evidence:**
- **Unknown or blocked:**
- **Next safe action:**
## First response: classify the job
| Situation | Default path | Do not do |
|---|---|---|
| Diagnose or make one bounded change on one host | Native `ssh` with a read-only preflight | Do not open an interactive shell and make unrecorded edits |
| Diagnose or make one bounded change on one host | Native `ssh` with a read-only preflight and bounded command/range; do not use a live-follow stream such as `tail -f` | Do not open an interactive shell and make unrecorded edits |
| Repeat the same desired state across hosts | Ansible inventory + playbook, canary/serial rollout | Do not loop `ssh` blindly across production hosts |
| Python must coordinate SSH channels, SFTP, or a custom protocol flow | Paramiko with strict host-key verification and explicit timeouts | Do not disable host-key checks or turn a script into ad hoc fleet control |
| The platform/control plane is unknown | Run bounded discovery from `references/portable-operations.md` | Do not use `systemctl`, `apt`, `pfctl`, or `launchctl` based on a guess |
@@ -42,7 +52,9 @@ Before the first state-changing command, confirm:
- intended state, expected blast radius, rollback command or artifact, and stop condition;
- validation at both the component layer and the relevant external boundary.
Read-only discovery may proceed without confirmation. Destructive actions, privilege changes, firewall/remote-access changes, package removals, storage operations, and reboot/shutdown require an explicit directive after this preflight.
> **Connectivity/access pre-execution gate:** explicitly name authorization, retained session, independent recovery path, tested rollback, stop condition, and component plus external-boundary verification. If any is unknown, stop before execution.
Read-only discovery may proceed without confirmation. **Read-only means no persistent state:** do not create rollback scripts or captures, stage update metadata, alter files, or call a state-changing operation `preflight`. Stop once the needed platform and control-plane evidence is established. Destructive actions, privilege changes, firewall/remote-access changes, package removals, storage operations, and reboot/shutdown require an explicit directive after this preflight.
## Routing references
remote-systems-administration/references/linux.md
+6
View File
@@ -54,6 +54,12 @@ Changes to network configuration, DNS, SSH, sudo, PAM, routing, firewall state,
Linux firewall control planes include nftables and systems layered above it, such as firewalld or distribution tooling. Discover which system owns rules before changing anything. Do not mix direct nftables edits with a higher-level manager unless its documentation permits it, and never mechanically translate PF, iptables, or cloud firewall rules.
| Evidence | Decision |
|---|---|
| A firewall binary exists or `firewalld` is active | Ownership is still unknown. Inspect the managed configuration and sanctioned control path; do not select a tool from presence or service state alone, and do not use a trial rule or any other mutation to decide ownership. |
| firewalld is the confirmed policy owner | Use its documented interface; do not add direct nftables rules beside it. |
| Native nftables configuration is the confirmed policy owner | Use nftables only through that configuration's documented management path. |
For nftables, inspect the existing ruleset and ownership before edits. Policy changes can sever the live SSH session. Validate rule syntax where available, retain a recovery path, apply a bounded change, and verify both expected traffic and retained administrative access.
## Reboot and lifecycle