Running AI tools on your servers safely: dedicated SSH keys, no root logins

By Noiz / 19th October 2026 | 6 min

AI coding agents can now sign in to a server over SSH and run commands for you. Whatever account the agent uses, it can do everything that account can do, so the safe set-up is the one you would give a new contractor: its own user, its own SSH key, never root, only the access the job needs, a human approving anything that changes the server, and a backup taken first. Each of those steps also makes it easy to see what the tool did and to cut it off in one move.

Why an AI agent needs its own front door

An agent such as Anthropic's Claude Code or OpenAI's Codex works by running commands. On your own laptop, both tools can ask before each command and run inside a sandbox. Once the agent connects to a server over SSH, what it may do there is decided by the server: by the account it signs in as and the key it uses.

Two risks are specific to AI:

  • Too much power. The Open Worldwide Application Security Project (OWASP) lists "excessive agency" as a top risk for AI applications: giving a model more functions, permissions or autonomy than its task needs. Its advice is to keep a human approving high-impact actions.
  • Instructions from the wrong place. An agent that reads a web page, a log file or an issue can meet text written to look like an instruction. OpenAI's Codex documentation warns that prompt injection can make the agent fetch and follow untrusted instructions, and the UK National Cyber Security Centre (NCSC) says the problem may never be fully fixed, so what the model is allowed to do must be limited.

Neither risk is solved by a cleverer prompt. Both are solved by what the account is allowed to do.

1. Stop root signing in

OpenSSH, the SSH server on almost every Linux system, allows root to sign in with a key by default, and allows password sign-ins by default. Once your own key-based login works, set these in the SSH server's configuration and restart it:

PermitRootLogin no
PasswordAuthentication no

No person and no tool then signs in as root. Administrative work goes through sudo from a named account, where it is logged.

Our help article How to set up SSH key-based authentication on a Linux server covers the key set-up first.

2. Give each tool its own user and its own key

Create a separate user for the agent, and a key pair used for nothing else:

ssh-keygen -t ed25519 -C "ai-agent laptop 2026-10"

The comment after -C is only a label for you, so you can tell keys apart later. One key per tool per machine means that removing the tool's access is deleting one line from the user's authorized_keys file, without touching anyone else's.

Where SSH keys are stored in Linux explains the files involved.

3. Limit what the key may do

Each line in authorized_keys can carry its own restrictions, documented in OpenSSH's manual:

Option What it does
from="203.0.113.10" The key works only from that address
restrict Turns off port forwarding, agent forwarding and other extras
command="..." The key can run only that one command
expiry-time="20261231" The key stops working after that date

For example:

restrict,from="203.0.113.10",expiry-time="20261231" ssh-ed25519 AAAA... ai-agent laptop 2026-10

An expiry date is a good habit for any key given to a tool: access lapses on its own if you forget.

4. Grant sudo narrowly, or not at all

If the agent needs administrative commands, give it only the specific ones. The sudo manual warns that granting ALL lets a user run anything, that "everything except" rules rarely hold, and that a program run with sudo can start other programs. Narrow is safe; clever exclusions are not. sudo logs every use, which gives you a record of what the agent did.

5. Keep a human in the loop

Use the agent's approval settings. Claude Code asks before edits and commands in its default mode, and Anthropic says its mode that skips approvals should be used only in isolated containers or virtual machines. Codex runs in a sandbox with network access off by default.

Read each proposed command before you approve it, especially anything that deletes, overwrites, restarts or changes permissions.

6. Back up first, and log everything

Anthropic notes that Claude Code's checkpoints undo file edits it made, not changes made by shell commands. On a server, a backup is the only undo.

  • Take a backup or snapshot before letting any tool change a server.
  • Keep logs. On Debian 12 and later, sign-ins and sudo use are in the systemd journal, read with journalctl.
  • Review the session afterwards: what was signed in, what was run, what changed.

On Noiz hosting

  • Noiz Cloud servers give you full root over SSH, so every step above is in your hands. Set up SSH keys, a non-root user and a firewall before anything else.
  • Noiz Premium shared hosting includes SSH access to your own hosting account.
  • Back up before you start. The Backup add-on is a managed backup for servers, with restore terms agreed before you buy.

If you want a server set up for AI tools without handing any of them the keys to everything, ask Noiz for a Linux administration quote.

Sources

  • OpenSSH, sshd_config(5): https://man.openbsd.org/sshd_config
  • OpenSSH, sshd(8), authorized_keys format: https://man.openbsd.org/sshd.8
  • OpenSSH, ssh-keygen(1): https://man.openbsd.org/ssh-keygen
  • sudoers(5) manual: https://www.sudo.ws/docs/man/sudoers.man/
  • Claude Code, security: https://code.claude.com/docs/en/security
  • Claude Code, permissions: https://code.claude.com/docs/en/permissions
  • Claude Code, checkpointing: https://code.claude.com/docs/en/checkpointing
  • OpenAI Codex, approvals and security: https://learn.chatgpt.com/docs/agent-approvals-security
  • OWASP, LLM06 excessive agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
  • OWASP, LLM01 prompt injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
  • NCSC, prompt injection is not SQL injection (8 December 2025): https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
  • Debian 12 release notes: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
  • Plesk, SSH access options: https://support.plesk.com/hc/en-us/articles/12377741369495-What-is-the-difference-between-options-Access-to-the-server-over-SSH-parameter-in-Plesk

Note: while some of this content was produced with the help of AI, the final editing has been done by a real human being.