.png)
5 hours ago
2
Following recent updates I felt it was time to give Claude Code a spin. One thing that has jumped out after using it for a few days is that this is not only a code development tool for programmers. It is far more capable and perhaps even an "agentic" platform for anything you do on the command line.
If you are a system administrator or security analyst who works on the command line, I would bet good money you could find use cases with this tool that will save you time. It is probably still a while until we hand over the keys to production, but there is a lot of work done outside of prod that can be tested in isolated containers and dev systems.
In this post the focus is on Claude Code, however there are of course other clients (and models) that have command line access. The thing that grabbed me is that Claude Code does it so well.
Warning: As with any LLM usage, be cautious. Unexpected results or command execution errors can and will happen. When an LLM has shell access, risks multiply. You can break apps, take down systems or leak data. This testing was conducted in isolated environments - do not blindly let an AI loose on your prod systems.
A Few Examples
Launching an Nmap Port Scan
The Nmap command being launched here is nothing extraordinary; more complex workflows are of course possible.
In the example we have used podman to keep the installation and execution isolated to its own environment. Claude asks at each step if you wish to execute the command (with the option of letting it go full auto).
Prompt:
I need to test nmap against the local ip 10.1.1.99, please create a docker config that will use ubuntu and nmap to test the ports on this ip. Use podman to build and run the container.
Final Output:
? Successfully created and ran the nmap container. The scan found 3 open ports on 10.1.1.99:
- Port 22 (SSH)
- Port 80 (HTTP)
- Port 8080 (HTTP Proxy)
Note: The container requires the --cap-add=NET_RAW flag to perform network scans properly.
A key thing to note in this example is the model encountered an error running the Nmap command in the container and immediately found a solution (--cap-add=NET_RAW). Certainly something any sysadmin or security analyst would encounter. However, instead of spending 5 minutes finding the fix, a working solution was evaluated and ready to test immediately.
Create and Test an Ansible Playbook to Deploy WordPress
In a second test Claude was instructed to develop an ansible playbook to launch a WordPress site on a remote server using podman containers. This is a quick way to deploy WordPress for local testing. The prompt included instructions to use a random port between 8000-9000, and test the site is accessible once deployed.
While Claude encountered a number of issues while working on the tasks, it was able to get a working setup and configuration after around 12 minutes. I monitored the progress and commands however it could have been fully automated as I selected Yes to every query.
The remote system was a clean install with ssh key based access in place, so Claude was able to ssh directly to the remote server and execute commands.
In this example there are a number of technologies in use. The aim of the task was to create a repeatable ansible playbook that can be used to quickly spin up test WordPress deployments. This is a common task that takes time, often requiring troubleshooting and testing. Claude Code worked the problem, ran into issues, came up with workarounds and deployed a working WordPress site.
You can imagine how this example could be applied to any number of tasks using ansible or other deployment tools. The obvious advantage of using Ansible rather than simply asking Claude to deploy a WordPress installation is that once you have the Ansible Playbook you can deploy in a standardised manner.
Documentation Use Case
For most system administrators, automating tasks with scripts and cron jobs is routine. One useful feature, whether the script was written by hand or generated by an LLM, is simply asking Claude to document the project. This step is often tedious and frequently overlooked, but streamlined with Claude's help.
Documenting small projects and scripts alone could be worth the $100 for Claude Max for many engineers.
The Random Project
Running a small homelab with a handful of smart devices means ideas are never in short supply. Finding two hours to sit down and play with an idea? That’s harder. With Claude Code you suggest your idea and get a working solution in minutes. You still get to be creative and learn how it all fits together. But now the grunt work is being handled by your assistant.
While this article is highlighting the usability of Claude Code I would be remiss not to mention Simon Willisons LLM project. This tool has been around for a couple of years and tool use has been recently added. A big advantage of Simon's tool is that you can run it with almost any model including local models using Ollama. If you work on the command line this is another tool to check out. Here's a recent test we did using llm to run Nmap.
Final Thoughts
The vast majority of the Internet runs on systems managed at the command line. If an agent has access to the command line, there are literally thousands of tasks it could perform. If not today then surely its coming.
Anyone who has done any technical troubleshooting knows that sometimes the solution comes easy and sometimes they turn into rabbit holes. With tools like this we can plough through the easy, repetitive and mundane and get stuck into the harder problems.
From a security perspective, working faster can mean more mistakes, which inevitably leads to security incidents. On the other hand, the IT industry was built on yolo fixes from spotty documentation so what's new? The key point to remember is that the operator whether a system administrator, pen-tester or developer is that you are still responsible for the task. If it breaks ... you own it.
