You Put OpenClaw on a VPS. It Has Access to Everything. You Secured None of It. Let's Fix That in 30 Minutes.
This guide was written for the brave souls who saw the OpenClaw hype train, jumped aboard, spun up their first VPS, and then had the terrifying realization that they now need to learn Linux security. You're going to be fine. Probably.
Look, I get it. You saw the hype. You saw the tweets. You saw some guy on Reddit say OpenClaw changed his life, and now you're sitting there at 2 AM with your very first VPS, a fresh install of OpenClaw, and the sudden realization that you just handed an AI assistant the keys to your email, your calendar, your Google Drive, your private documents, and basically your entire digital soul - all running on a server you've never secured before because, well, this is your first server.
Now, let's be fair: a fresh Ubuntu installation isn't actually a house with no doors. Ubuntu ships with sensible defaults - no unnecessary open ports, no sketchy services running, SSH with reasonable settings. Credit where credit is due. But here's the problem: you're not running a fresh Ubuntu installation anymore. You're running OpenClaw on top of it. With plugins. And skills. And extensions. And API keys to everything you own.
Here's a fun fact to help you sleep tonight: every VPS that connects to the internet gets fully port-scanned by automated bots within 10 to 20 minutes. Not hours. Not days. Minutes.
But with OpenClaw and its ecosystem of plugins exposing additional services and APIs? Now you're interesting. And on the internet, you do not want to be interesting.
And look - I'm not here to trash OpenClaw. It's genuinely cool. The AI-assistant-on-your-own-server dream is alive and well. But let's be honest with ourselves for a moment: OpenClaw, plus all of its plugins, skills, and extensions, is not exactly what security researchers would call "airtight." It's more what they'd call "a fun afternoon." The platform is young, moving fast, and the attack surface grows with every skill you install. The real risk isn't Ubuntu's defaults - it's everything you're bolting on top of them.
So since we can't fix OpenClaw's security overnight, let's make damn sure that the server underneath it is locked down tight, so that even if someone finds a vulnerability in a plugin, they hit a brick wall instead of a buffet.
The good news? I recommend Ubuntu for your VPS, and I'm going to walk you through this whole thing step by step.
Why Ubuntu? Because it has a massive community, a mountain of security tools, and - this is the important part - any non-technical noob can harden it in about 30 minutes with proper guidance.
Let's go. And please, for the love of everything, don't close your terminal until I tell you to.
Step 0 - Non-root user
Before we do anything else - if you're still logged in as root like some kind of digital cowboy, we need to fix that immediately. Root is the god account. It can do anything, break anything, and delete anything, including itself.
So let's create a proper user and give it sudo powers:
adduser ubuntu
usermod -aG sudo ubuntu
Now, because typing your password every time you run sudo gets old approximately 4 seconds after the first time, let's set up passwordless sudo. Run visudo and add this line at the very bottom:
ubuntu ALL=(ALL) NOPASSWD:ALL
From this point on, you do everything as ubuntu and use sudo when you need elevated privileges. Think of root as the emergency fire axe behind glass - it's there if you need it, but you shouldn't be casually swinging it around on a Tuesday afternoon.
Now copy your SSH key to the new user (ssh-copy-id or manually paste it into /home/ubuntu/.ssh/authorized_keys), log in as ubuntu in a new terminal to make sure it works, and never log in as root again.
Step 1: Set Your Timezone
Before we do anything dramatic, let's make sure your server knows what time it is. This sounds trivial, but accurate timestamps in your logs are the difference between "I can see exactly when someone broke in" and "something happened... at some point...
dpkg-reconfigure tzdata
Pick your timezone from the menu. It's interactive.
Step 2: Update Everything
Your server shipped with software that was already outdated by the time you clicked "Deploy." Let's fix that.
apt update && apt upgrade -y
This updates all your packages to their latest versions, patching known vulnerabilities. Think of it as putting on pants before leaving the house. Bare minimum.
Now, because we both know you're going to forget to do this regularly (I know you, and I love you, but I know you), let's set up automatic security updates:
apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
This configures your server to automatically install critical security patches without you having to remember. It's like hiring a tiny robot butler whose only job is to lock the doors you keep leaving open.
Step 3: Set Up Ubuntu Pro
Ubuntu Pro gives you expanded security maintenance, kernel live patching, and compliance tools. And here's the kicker - it's free for up to 5 machines.
Go to ubuntu.com/pro, grab your token, and attach it:
pro attach YOUR_TOKEN_HERE
This extends your security coverage and covers thousands of additional packages. It's like getting the extended warranty, except it actually does something.
Step 4: Lock Down SSH
SSH is how you talk to your server. It's also how everyone else tries to talk to your server. By default, it's running on port 22, which is the first port every bot on the internet checks. That's like hiding your house key under the doormat - the one place literally everyone looks first.
Edit your SSH config:
nano /etc/ssh/sshd_config
Here's what your config should look like. I'll explain each line, because I respect you and your journey:
Port 55222 # Move SSH off the default port. Not foolproof, but stops 90% of really lazy scanners.
LoginGraceTime 2m # You get 2 minutes to authenticate. After that, goodbye.
PermitRootLogin no # NOBODY logs in as root. Ever. Not even you. Especially you.
MaxAuthTries 5 # 5 wrong passwords and we hang up on you. Rude? Maybe. Secure? Yes.
PasswordAuthentication no # No passwords. Period. Keys only. Passwords are the cargo shorts of security.
PermitEmptyPasswords no # Just... no. Come on.
AllowUsers ubuntu # Only the 'ubuntu' user can log in. Everyone else can go home.
X11Forwarding no # No graphical forwarding. This is a server, not a gaming PC.
PermitUserEnvironment no # Don't let users set environment variables through SSH. Trust issues? You bet.
AllowAgentForwarding no # No SSH agent forwarding. Reduces the risk of key theft.
AllowTcpForwarding no # No TCP tunneling through your server. It's not a VPN.
PermitTunnel no # Same energy as above. No tunnels.
KbdInteractiveAuthentication yes # Needed for 2FA (we'll get there, be patient).
ChallengeResponseAuthentication yes # Also needed for 2FA. The dynamic duo.
AuthenticationMethods publickey,keyboard-interactive # Key first, then 2FA code. Belt AND suspenders.
UsePAM yes # Use PAM for authentication. Required for Google Authenticator.
The key takeaways: We moved the SSH port (so bots can't find it easily), disabled root login (so even if someone gets in, they're not god), killed password authentication (keys only, like a VIP club), and set up the groundwork for two-factor authentication.
Now reload SSH so it actually pays attention to what we just told it:
sshd -t && systemctl reload ssh.service
The sshd -t part tests your config first. If there's a typo, it'll tell you before you lock yourself out. Because locking yourself out of your own server is a very special kind of pain.
⚠️ CRITICAL: Do NOT close your current terminal session yet. Open a NEW terminal and test that you can still connect with your new settings before closing anything.
ssh -i /path/to/your-key -p 55222 ubuntu@your-server-ip
Step 5: Install Fail2Ban
Fail2Ban watches your authentication logs and automatically bans IP addresses that fail to log in too many times. It's basically a nightclub bouncer for your server.
apt install fail2ban -y
Out of the box, Fail2Ban will monitor SSH and ban anyone who fails authentication repeatedly. You can customize the jail settings later, but the defaults are already pretty solid for keeping the riff-raff out.
Think of it this way: Step 4 made it harder to get in. Step 5 makes sure that anyone who keeps trying gets permanently shown the door.
Step 6: Set Up Two-Factor Authentication
This is the big one. This is where we go from "pretty secure" to "okay, now I can actually sleep at night."
Two-factor authentication means that even if someone somehow gets your SSH key (it happens - laptops get stolen, backups get leaked, your cat walks across your keyboard and emails it to someone), they STILL can't get in without the 6-digit code from your phone.
Install Google Authenticator:
apt install libpam-google-authenticator -y
Switch to your ubuntu user and run the setup:
su - ubuntu
google-authenticator
It'll ask you some questions. Here are the correct answers (you're welcome):
| Prompt | Answer | Why |
|---|---|---|
| Time-based tokens? | y | Time-based is more secure than counter-based |
| Update .google_authenticator file? | y | This saves your config |
| Disallow multiple uses? | y | Each code works exactly once |
| Increase time window? | n | Keep it tight |
| Rate limiting? | y | Slows down brute-force attempts |
It'll show you a QR code. Scan it with Google Authenticator, Authy, or whatever TOTP app you prefer. And for the love of all that is holy, SAVE THE EMERGENCY SCRATCH CODES.
Put them in a password manager (important!). They're your "break glass in case of emergency" codes if you lose your phone.
Configure PAM (this tells SSH to actually use the authenticator):
sudo nano /etc/pam.d/sshd
Add this line at the very top:
auth required pam_google_authenticator.so
And comment out this line (to prevent a double password prompt, which is annoying and unnecessary):
# @include common-auth
Make sure your SSH config has these lines set correctly (most of them should already be right from Step 4):
KbdInteractiveAuthentication yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
UsePAM yes
PasswordAuthentication no
Test the config and restart SSH:
sshd -t && systemctl restart ssh
Now test in a NEW terminal (seriously, keep your current session open - are you sensing a pattern here?):
ssh -i /path/to/your-key -p 55222 ubuntu@your-server-ip
Your login flow should now be: SSH key → TOTP verification code → you're in. No password involved. Just your key and your phone. It's like a secret handshake, but actually secure.
Step 7: Monitor Your Logs
Congratulations, your server is now significantly more secure than it was 20 minutes ago. But you need to actually check on things occasionally.
Check your SSH authentication logs:
sudo cat /var/log/auth.log | grep sshd
For live monitoring (great for watching scans/attacks happen in real-time, which is weirdly entertaining):
sudo tail -f /var/log/auth.log
What to look for:
- Repeated failed login attempts - Fail2Ban should catch these, but check anyway
- Login attempts from unfamiliar IP addresses - If you see IPs you don't recognize, investigate
- Unknown usernames - If someone's trying to log in as "admin" or "test," that's a bot
- Successful logins at weird hours - If you logged in at 3 AM and you were asleep at 3 AM, we have a problem
Bonus Round: For the Ambitious
If you've made it this far and you're feeling confident (possibly too confident, but I respect the energy), here are two next-level options:
Tailscale
Tailscale creates a private mesh VPN between your devices. Once set up, you can access your server through a private network that isn't exposed to the public internet at all. It's like having a secret tunnel to your server that only you know about. The setup is shockingly simple for something this powerful.
Cloudflare Tunnel
Cloudflare Tunnel lets you expose your OpenClaw instance to the internet without opening ANY inbound ports on your server. Zero. None. The server reaches out to Cloudflare, and Cloudflare handles all incoming traffic. It's like having a P.O. Box for your server - people can send you mail, but they don't know where you live.
Both of these are excellent options if you want to take your security from "solid" to "paranoid, but like, in a healthy way."
Final Thoughts
If you're running OpenClaw on a VPS, you've put your most private digital life on a server connected to the open internet. Your emails. Your calendar. Your documents. Your credentials. All of it sitting there, protected by whatever security you bothered to set up.
Is your server now impenetrable? No. Nothing is impenetrable. But you've gone from being a soft, delicious target to being the server that's maybe not worth the effort today when there are millions of easier ones to hit.
You've got this. Probably. I believe in you. Mostly.
Top comments (0)