VPS & Security on Aquasp's blog

How to avoid timeouts while you are logged on SSH

Tue, 09 Dec 2025 01:41:02 +0000

Introduction

One of the most frustrating things when working on a server?

Your SSH session dies because of a brief Wi-Fi hiccup, idle timeout, or flaky connection.

Fix it forever in 30 seconds.

The Universal Fix: Edit Your SSH Config

This works on Linux, macOS, and Windows — and survives network glitches up to ~4–5 minutes.

Step 1: Create or Edit the SSH Config File

On Linux / macOS:

mkdir -p ~/.ssh
nano ~/.ssh/config

On Windows (PowerShell):

# Replace YourUsername with your actual Windows username
mkdir "$HOME\.ssh" -Force
notepad "$HOME\.ssh\config"

Step 2: Add These Lines

sshHost *
 ServerAliveInterval 120
 ServerAliveCountMax 3
 TCPKeepAlive yes

Save and exit.

Done. That’s it.

What This Actually Does

Setting	Meaning
`Host *`	Apply these rules to every SSH connection
`ServerAliveInterval 120`	Every 2 minutes, your computer sends a tiny “I’m still here” packet
`ServerAliveCountMax 3`	If 3 packets in a row fail → only then close the connection (~6 min)
`TCPKeepAlive yes`	Extra OS-level keepalive (helps with some routers/firewalls)

Result: Your SSH session now survives:

Wi-Fi switching
Laptop sleep/wake
Brief internet drops
VPN reconnects

…without freezing or dying.

You’re Now Unbreakable

From now on, when your internet blinks, your SSH session just… waits patiently.

No more “Connection reset by peer” No more lost tmux sessions No more rage

You’ve officially leveled up.

Thank you for reading — stay connected!

How to easily self-host at home and put your projects online under CGNAT

Tue, 09 Dec 2025 01:13:41 +0000

Introduction

Want to run heavy services on a powerful server at home, even though your ISP puts you behind CGNAT? This guide shows you exactly how to put them online — the old-school, bulletproof way using SSH reverse tunnels.

No Cloudflare Tunnel. No Ngrok. Just SSH + systemd.

The Downsides (and Why They’re Manageable)

Home internet isn’t datacenter-grade (outages happen)
Most ISPs use CGNAT → you can’t open ports normally

Solution: Use a cheap VPS as a public “jump box”. Your heavy server stays home. The VPS only forwards ports.

How It Works – The Magic of Reverse SSH Tunnels (-R)

Internet → Cheap VPS (public IP) → SSH reverse tunnel → Your home server (behind CGNAT)

Your home server initiates an outbound SSH connection to the VPS and says: “Anything that hits port 8096 on you → send it to my local Jellyfin on 8096”

Zero ports opened on your home router. Zero exposure.

Step-by-Step Setup

1. On Your Home Server (the powerful one)

# Create folder for tunnel configs
sudo mkdir -p /etc/sshtunnels

# Example: expose Jellyfin (port 8096)
sudo nano /etc/sshtunnels/jellyfin.conf

Content of the file:

8096:8096 # remote_port:local_port
443:8443 # optional: HTTPS reverse proxy on VPS → your local 8443
80:8080

One line per service. First number = port on the VPS, second = port on your home server.

2. Generate an SSH Key (if you don’t have one)

ssh-keygen -t ed25519 -C "home-server-tunnel"

Copy the public key to your VPS:

ssh-copy-id user@your-vps-ip

3. Create the Tunnel Manager Script

sudo nano /usr/local/bin/sshtunnel.sh

#!/bin/bash

# === EDIT THESE ===
REMOTE_USER="root" # or your VPS user
REMOTE_HOST="123.45.67.89" # your VPS public IP
SSH_KEY="/home/youruser/.ssh/id_ed25519"
SSH_PORT="22" # change if you use a non-standard port
# ==================

INSTANCE="$1"
CONFIG_FILE="/etc/sshtunnels/${INSTANCE}.conf"

if [[ ! -f "$CONFIG_FILE" ]]; then
 echo "Error: Config file $CONFIG_FILE not found!"
 exit 1
fi

# Build -R arguments
FORWARD_OPTS=""
while IFS=: read -r remote_port local_port; do
 [[ -z "$remote_port" || "$remote_port" =~ ^# ]] && continue
 # Clean any old process using the remote port
 ssh -p "$SSH_PORT" "$REMOTE_USER@$REMOTE_HOST" \
 "lsof -i :$remote_port -t | xargs -r kill -9" 2>/dev/null
 FORWARD_OPTS="$FORWARD_OPTS -R $remote_port:localhost:$local_port"
done < "$CONFIG_FILE"

echo "Starting tunnel $INSTANCE → $REMOTE_HOST ($FORWARD_OPTS)"

exec ssh -o StrictHostKeyChecking=no \
 -o ServerAliveInterval=30 \
 -o ServerAliveCountThreshold=3 \
 -o ExitOnForwardFailure=yes \
 -o GatewayPorts=yes \
 -N -T \
 -i "$SSH_KEY" \
 -p "$SSH_PORT" \
 $FORWARD_OPTS \
 "$REMOTE_USER@$REMOTE_HOST"

Make it executable:

sudo chmod +x /usr/local/bin/sshtunnel.sh

4. Create a Systemd Service (Auto-Start & Auto-Reconnect)

sudo nano /etc/systemd/system/sshtunnel@.service

[Unit]
Description=SSH Reverse Tunnel for %i
After=network-online.target
Wants=network-online.target

[Service]
User=youruser # ← change to your home user (not root!)
Group=youruser
ExecStart=/usr/local/bin/sshtunnel.sh %i
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Reload and enable:

sudo systemctl daemon-reload

# Start a tunnel (example: jellyfin)
sudo systemctl enable --now sshtunnel@jellyfin.service

Check status:

sudo systemctl status sshtunnel@jellyfin.service

5. On the VPS Side (Optional but Recommended)

Install a tiny web server or Caddy/nginx to terminate TLS and proxy to the forwarded ports.

Example with Caddy (automatic HTTPS):

# On the VPS
apt install caddy

# /etc/caddy/Caddyfile
jellyfin.yourdomain.com {
 reverse_proxy localhost:8096
}

Now jellyfin.yourdomain.com → your home Jellyfin, fully encrypted.

All running on my beast home server behind CGNAT.

Pros of This Setup

Works behind any CGNAT / ISP block
No third-party dependency (no Cloudflare, no Ngrok)
Full encryption possible
Survives reboots (systemd + Restart=always)
Costs almost nothing

Final Words

This is the one really cool way I’ve found to self-host heavy services at home in 2025.

Your powerful hardware stays home. Your $1/month VPS is just a traffic cop.

Thank you for reading — now go build your unstoppable home lab!

How to Make Your VPS Safer Against Accidental Deletions

Tue, 09 Dec 2025 00:31:57 +0000

Introduction

Have you ever deleted a file or a folder by mistake in a VPS? That feeling sucks. Sometimes you are working fast and you delete a really important file/folder. This happened to me previously. Today I want to share an amazing tool with you guys: trash-cli . It adds a trash in the CLI to prevent these human mistakes.

Installing trash-cli

trash-cli is a lightweight, command-line tool available in Debian repositories, making it ideal for VPS environments with limited resources.

Installation Steps

Update your package list:

sudo apt update

Install trash-cli:

sudo apt install trash-cli

Verify the installation:

trash --version

You should see version information if installed correctly.

This process is quick and adds minimal overhead to your VPS.

Using trash-cli for Safer Deletions

Once installed, trash-cli provides commands to manage files safely. It moves items to ~/.local/share/Trash/ instead of deleting them.

Basic Commands

Trash a file or directory: trash file.txt or trash directory.
List trashed items: trash-list (shows files with deletion dates).
Restore items: trash-restore (interactive menu to select and recover files).
Empty the trash: trash-empty (permanently deletes all trashed items).
Empty old items: trash-empty 30 (deletes items older than 30 days).

Example workflow:

trash important_file.txt # Move to trash
trash-list # Check what's there
trash-restore # Recover if needed

This replaces risky rm usage in daily operations.

Aliasing rm to Use trash-cli

To make rm safer by default, alias it to trash in your shell configuration. This ensures most deletions go to the trash bin.

Setting Up the Alias

Edit your ~/.bashrc file:

nano ~/.bashrc

Add this line at the end:

alias rm='trash'

Save and exit (Ctrl+X, Y, Enter).
Reload the configuration:

source ~/.bashrc

Now, rm file.txt will use trash instead of permanent deletion.

Automating Trash Emptying with Cron

To prevent the trash from accumulating indefinitely, automate emptying with a cron job.

Setting Up Weekly Emptying

Edit your crontab:

crontab -e

Add this line for weekly deletion (e.g., every Sunday at 2 AM):

0 2 * * 0 /usr/bin/trash-empty

0 2 * * 0: Sunday at 2:00 AM.
/usr/bin/trash-empty: Clears all trash.

Save and exit.
Verify:

crontab -l

Adjust the schedule as needed (e.g., change 0 to 1-6 for weekdays). For partial emptying, use trash-empty 30 to delete items older than 30 days.

Conclusion

By installing trash-cli, aliasing rm to trash, and setting up automated emptying, you can make your VPS much safer against accidental deletions. This approach adds a recoverable layer without sacrificing performance. Remember to combine it with regular backups and cautious command usage. If you’re new to VPS management, start small and test thoroughly. For more advanced setups, explore integrating with monitoring tools. Stay safe out there!

How to make your VPS secure

Tue, 09 Dec 2025 00:30:29 +0000

Introduction

If you just bought a VPS and are starting to self-host, this is one of the most important security improvements you can make.

By switching to SSH key authentication and disabling password login, your server becomes nearly immune to brute-force attacks — even if someone discovers your password or you’re still using the default port 22.

Step 1: Generate an SSH Key Pair on Your Local Machine

Linux & macOS

Open a terminal and run:

ssh-keygen -t rsa -b 4096

or (newer recommended format):

Bash

ssh-keygen -t ed25519

Press Enter to accept the default file location and leave the passphrase empty (just hit Enter twice).

Your keys will be saved as:

Private key: ~/.ssh/id_rsa or ~/.ssh/id_ed25519
Public key: ~/.ssh/id_rsa.pub or ~/.ssh/id_ed25519.pub

Never share the private key!

Windows (PowerShell)

Open PowerShell and run:

ssh-keygen.exe -t ed25519

(or -t rsa -b 4096 if ed25519 is not supported)

Press Enter through the prompts (no passphrase). Keys will be created in C:\Users\YourUser.ssh\

Step 2: Copy Your Public Key to the VPS

Linux & macOS (Easiest Method)

ssh-copy-id user@your-vps-ip

Replace user and your-vps-ip with your actual username and server IP.

Windows

Paste your public key (it’s one long line starting with ssh-ed25519 or ssh-rsa) → Save with Ctrl+O → Enter → Ctrl+X
Test it: Open a new terminal/PowerShell and try logging in. It should work without asking for a password.

Edit the file:Bash

nano ~/.ssh/authorized_keys

Create the .ssh folder and authorized_keys file (if they don’t exist):Bash

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Log into your VPS normally (with password):PowerShell

ssh user@your-vps-ip

Copy your public key to clipboard:PowerShell

Get-Content $HOME\.ssh\id_ed25519.pub | Set-Clipboard

(or id_rsa.pub if you used RSA)

Step 3: Disable Password Authentication

Now that key login works, disable password login entirely.

Log into your VPS (using your key) and edit the SSH config:

sudo nano /etc/ssh/sshd_config

Find and change (or add) these lines:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PubkeyAuthentication yes

Save and exit.

Restart the SSH service:

sudo systemctl restart sshd

(or sudo service ssh restart on older systems)

Final test: Try logging in from a new terminal. It should only work with your private key — password attempts will be rejected instantly.

Done!

Your VPS is now protected against:

Brute-force attacks
Credential stuffing
Weak or leaked passwords

Even if an attacker knows your username and password, they cannot log in without your private key file.

Pro tip: Back up your private key securely and consider adding a passphrase later using ssh-keygen -p.

Thank you for reading! 😊

Page Cache, Object Cache and CDN cache - Understanding all types of caching

Mon, 08 Dec 2025 23:13:04 +0000

Understanding the Different Types of Caching (Especially for Scaling CMS Sites)

If you’ve ever wondered what people mean when they talk about “page cache,” “object cache,” or “CDN cache,” this post is for you. These are the three main caching layers that make a massive difference when scaling WordPress, WooCommerce, or any other CMS.

What is Page Caching?

Page caching (also called full-page caching or HTML caching) is exactly what it sounds like: the entire rendered HTML page is saved as a static file.

With a truly static site (plain HTML + CSS + JS), there’s no need for page caching because every file is already static. But with a CMS like WordPress, every request normally triggers PHP → theme → plugins → database queries → HTML output. That process eats CPU and takes time.

Full-page caching shortcuts all of that. The first visitor triggers the full PHP+MySQL process, the resulting HTML is saved, and every visitor after that gets served the pre-generated static HTML instantly — no PHP, no database queries, almost zero CPU.

Result: 10–100× lower server load and dramatically faster page loads.

What is Object Caching?

Object caching stores the results of expensive database queries (or any slow computation) in fast memory (usually Redis or Memcached).

Think of it as a super-fast middleman between your PHP code and the database.

Example with WordPress:

WordPress needs the list of published posts → it asks MySQL.
First request: MySQL does the work, returns the data, object cache saves it in RAM.
Next 10 000 requests: object cache instantly returns the same data from memory → MySQL sleeps peacefully.

Object cache is smart — it automatically invalidates itself when data changes (e.g., you publish a new post).

Why you still need it even with full-page caching:

Logged-in users (including the WordPress dashboard, WooCommerce account pages, etc.) can’t be fully cached for everyone.
Those pages still hit PHP and MySQL → object cache makes them tolerable instead of painfully slow.

Object cache + full-page cache together is the classic high-traffic combo.

What is CDN Caching?

A CDN (Content Delivery Network) copies your static assets (CSS, JS, images, fonts) — and optionally your full HTML pages — to “PoP” servers all over the world.

Without a CDN: a visitor in Japan downloads everything from your origin server in, say, Brazil → high latency.

With a CDN:

Static files are served from the closest PoP (often < 30 ms away).
If you also enable full-page caching on the CDN, the entire HTML page is served from that nearby PoP too → the origin server is never touched for cached pages.

This is why some sites load instantly from anywhere on the planet.

Real-World Example: WordPress Traffic Flow

No caching at all

Visitor → Web server → PHP → dozens of plugin files → MySQL queries → HTML → visitor → High CPU, slow TTFB, easily hits resource limits.

With full-page caching only

First visitor: same slow path as above (but the HTML is saved). Next 10 000 visitors: Web server instantly serves the pre-built HTML → almost zero CPU.

With object caching only

Every request still runs PHP + plugins, but database queries are answered from RAM instead of disk → faster than no cache, but still heavy.

With full-page cache + object cache

Anonymous visitors → static HTML (super fast, almost no load)
Logged-in users → PHP runs, but object cache makes DB queries instant → manageable load

Add CDN with full-page caching on top

Even the static HTML is now served from edge locations worldwide. Your origin server can basically take a nap until something actually needs PHP (e.g., form submissions, cache invalidation).

Conclusion

Here’s the hierarchy from most impactful to least (for most CMS sites):

Full-page caching on the CDN → fastest for visitors, scales to millions of hits with almost zero origin load.
Full-page caching on the origin → still massive win if you can’t cache on the CDN.
Object caching (Redis/Memcached) → mandatory for logged-in users, WooCommerce, dashboards, etc.
Everything else (OPcache, browser cache, etc.) → nice to have, usually enabled by default.

If you only do one thing: enable proper full-page caching (and push it to your CDN if possible). If you have logged-in traffic or a shop: add Redis/Memcached object caching.

That’s it — the three caching layers that power basically every high-traffic WordPress site on the planet.

Hope this cleared things up!

Thanks for reading! 😊