Teaching Claude to Check Its Own Access

If we want Claude to work on our servers, it needs to have access to it. We wrote a skill that runs through a number of checks to ensure Claude has everything it needs to work.

Imagine asking a mechanic to fix your vehicle only to find they do not have the keys to start it up to test it. This checklist is that test for Claude.

The Fertile Soil runs its websites, email and other technology on a number of rented servers. When something breaks, we work with the AI Claude to fix it. Claude needs access to our servers. Claude now runs a short check at the beginning of every work session . It confirms it can reach each server, that the passwords and keys it relies on still work, and that it is signed in to the dashboards it requires.

If something is missing, Claude does not guess or work around it. It tells you exactly which piece is missing and what you must do to fix the issue. 

Why we built this skill

We built this Claude skill because we asked Claud to check something on one of our servers and it replied that it could not access the server. Running this skill ensures Claude cess to everything we need.

The cloud workspace that Claude runs in had no login key for the servers and no private network connection to them. The Mac connection looked like a way in, but its shell is a sandboxed virtual machine with no keys either. Computer control of the Terminal app can click but not type, by design. Each path failed for a different reason, and each failure looked like “it should work” from the outside.

The lesson was that access needs to be a checked fact, not an assumption. A short test at the start of every session turns a long afternoon of guessing into a one line answer: which system, what failed, and what to do about it.

The same checklist now also holds the one-time setup. When a key or token is missing, Claude hands you the exact steps to fix it instead of attempting to working around the gap. This gives us a set environment that works every time.

What the check covers

Every run ends with one table: system, works or fails, and what is needed. These are the systems it tests.

System	How Claude tests it	If it fails
Servers	Logs in over SSH and reads the hostname and clock	Shows which key or host fingerprint is wrong and the one command to fix it
Private network	Checks that the servers and your devices are visible on the Tailscale network	Says whether the auth key or the network allowlist is the problem
API tokens	Calls Cloudflare, Hetzner and Brevo from the server and reads the status code	Names the token to replace; you create the new one
Mailbox	Confirms the password file exists and the mail reader finishes cleanly	Gives you a command that lets you type the password into the file yourself
Web consoles	Opens Cloudflare, Hetzner and the hosting panel in your signed-in Chrome	Asks you to sign in; Claude never types passwords
WordPress	Reads the site URL with the command line tool	Reports the account or path that failed

How the access works

Claude gets root through one dedicated SSH key, reached over a Tailscale network running in userspace mode, with both pieces supplied as environment secrets when a session starts.

• A dedicated key. One ed25519 key, commented claude-cloud, appended to /root/.ssh/authorized_keys on each server. Revoking Claude is deleting one line.
• Tailscale in userspace mode. The cloud workspace usually cannot open outbound port 22 and cannot create a tun device. Running tailscaled --tun=userspace-networking --socks5-server=localhost:1055 and pointing a ProxyCommand nc -X 5 -x localhost:1055 %h %p at it gives SSH to tailnet addresses without either.
• Secrets in the environment. The private key and a reusable, tagged Tailscale auth key (90 day expiry) are stored as environment secrets. They load only at session start, so after you change them you start a new session.
• Pinned host keys. The skill records each server’s ed25519 fingerprint. Claude scans the key over the tailnet and adds it to known_hosts only if the fingerprints match. Host key checking is never turned off.
• API tokens stay on the server. Cloudflare, Hetzner and Brevo tokens live in /root/.secrets/ with mode 600 and are used from the server, so they never travel to the workspace.
• Consoles through your own browser. Dashboards are driven through your signed-in Chrome. Claude does not type or store passwords.

One-time setup

You do these steps once. Claude never creates keys or tokens for you.

1. On the first server, as root, make the key and authorize it: ssh-keygen -t ed25519 -N "" -C claude-cloud -f /root/claude_key, then cat /root/claude_key.pub >> /root/.ssh/authorized_keys.
2. On every other server, append the same public line to /root/.ssh/authorized_keys. One key works for all of them.
3. Save the full private key block (cat /root/claude_key) as an environment secret named CLAUDE_SSH_KEY. Do not paste it into chat. Then delete it from the server with shred -u /root/claude_key /root/claude_key.pub.
4. Create a reusable, tagged Tailscale auth key that expires in 90 days in the Tailscale admin console and save it as TS_AUTHKEY.
5. Allow the workspace to reach Tailscale: login.tailscale.com, controlplane.tailscale.com, pkgs.tailscale.com and the relay servers. A blocked allowlist is the most common reason the network never comes up.
6. On each server run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub and give Claude the fingerprint. It is public, so sharing it is safe.
7. Start a new session in the same environment and ask Claude to run the access check.

After that, a session that starts with the secrets present installs Tailscale, writes the SSH config, pins the host keys and reports what works.

Safeguards and pitfalls

Root access should be easy to grant, easy to audit and easy to remove. These are the rules the checklist follows and the traps we hit.

Safeguards

• One revocable key. To cut Claude off, delete the claude-cloud line on each server, or remove its Tailscale node.
• Before pruning authorized_keys, Claude compares each key’s fingerprint with recent Accepted publickey lines in the auth log. It removes only keys with no recent use, never all keys at once, and tells you what it kept and removed.
• Host fingerprints are pinned. A mismatch stops the run and asks you to compare fingerprints on the server itself.
• Claude does not enter passwords, create accounts or create tokens. When one is needed, you make it and save it.
• Tailscale node keys expire after 180 days unless you disable expiry, and the auth key after 90. The check warns 30 days ahead.

Pitfalls we hit

• Secrets load at session start. Saving them mid-session changes nothing until you open a new session in the same environment.
• The Mac connection is not a route to your servers. Its shell runs in a sandboxed virtual machine with your files mounted and no SSH keys.
• Computer control of Terminal is click only. It can look but cannot type, so plan on a real SSH path instead.
• Port 22 often fails from the cloud even when the server is fine. Test port 443 as well to tell a network block from a dead server.
• A mail server logging queued does not mean the message was delivered. When a relay sits in the middle, read the relay’s own log before declaring a send successful.

The checklist lives in one place as a skill, so the next admin to inherit the servers gets the same first ten minutes you did.