Securing your AI agent server: firewall, SSH, and SSL hardening

Why security matters for a personal AI agent

Your AI agent server holds something uniquely sensitive: the full history of your conversations with an AI. Health questions, business decisions, personal concerns — all stored in one place. A compromised VPS doesn't just expose a website; it exposes your private context.

The good news is that basic hardening covers the vast majority of real-world attack vectors. The k-claw installer handles most of this automatically, but understanding what it does — and what to do next — is valuable.

Step 1: SSH key authentication

Password-based SSH is the most common entry point for compromised servers. Switch to key-based authentication immediately.

On your local machine, generate an SSH key pair if you don't have one:

ssh-keygen -t ed25519 -C "your-email@example.com"

Copy your public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@YOUR_SERVER_IP

Then disable password authentication in /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Restart SSH: systemctl restart sshd

Important: Test a new SSH session before closing your current one, to ensure you haven't locked yourself out.

Step 2: UFW firewall configuration

UFW (Uncomplicated Firewall) is the standard tool on Ubuntu. The goal is to allow only what you explicitly need and block everything else.

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80/tcp    # HTTP (for Let's Encrypt challenges)
ufw allow 443/tcp   # HTTPS
ufw enable

The k-claw installer configures UFW automatically. Verify the rules are active:

ufw status verbose

If you run a Telegram bot, note that OpenClaw polls the Telegram API (outbound) rather than requiring an inbound webhook port. No additional ports are needed for standard operation.

Step 3: Fail2Ban for brute-force protection

Even with key-based SSH, bots will still attempt connections and fill your logs. Fail2Ban automatically bans IPs that trigger too many failed attempts.

apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

Create a local configuration to survive package updates:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true

The k-claw installer configures Fail2Ban as part of the setup process.

Step 4: SSL certificates with Let's Encrypt

If you expose any part of your agent via HTTPS (an admin panel, webhook endpoint, or API), use a proper TLS certificate from Let's Encrypt — never self-signed certificates in production.

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourdomain.com

Let's Encrypt certificates auto-renew via a systemd timer that Certbot installs automatically. Verify:

systemctl status certbot.timer

Step 5: keep the system updated

Enable automatic security updates so critical patches apply without manual intervention:

apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

This applies security updates automatically while holding back non-security package upgrades, reducing risk of breaking changes.

Step 6: create a non-root user

The k-claw installer creates a dedicated system user (openclaw) with restricted permissions to run the agent process. This is critical: even if someone exploits a vulnerability in the agent, they gain access to that restricted account — not root.

For your own SSH access, create a non-root sudo user and disable root SSH login once you've verified it works:

adduser yourname
usermod -aG sudo yourname

Then set PermitRootLogin no in sshd_config.

Ongoing monitoring

After initial hardening, periodic checks keep you aware of the server's state:

• last — Review recent login history
• fail2ban-client status sshd — See active bans and recent activity
• journalctl -u kclaw-* --since today — Review agent logs
• apt list --upgradable — Check for pending updates

A properly hardened VPS running OpenClaw is about as secure as any internet-connected Linux server can be. The attack surface is small by design — no database ports exposed, no web interface by default, and all sensitive data encrypted at rest.