DEV Community: Buran Host

How to Secure SSH on a Fresh VPS in 10 Minutes (Keys, Firewall, Fail2ban)

Buran Host — Thu, 29 Oct 2026 18:14:29 +0000

Disclosure: I run Buran.host, a VPS hosting service. The steps below work on any Debian or Ubuntu server, no matter where it is hosted.

A new VPS is scanned by bots within minutes of getting a public IP address. Open the log of a fresh server and you will already see hundreds of failed root logins. None of this is dangerous if you spend ten minutes on setup first. Here is the short checklist I use on every new server.

1. Create a normal user

Do not work as root. Create a user and give it sudo rights:

adduser deploy
usermod -aG sudo deploy

2. Log in with a key, not a password

On your own computer, create a key (skip this if you already have one):

ssh-keygen -t ed25519 -C "my-laptop"
ssh-copy-id deploy@YOUR_SERVER_IP```
{% endraw %}
Open a second terminal and check that {% raw %}`ssh deploy@YOUR_SERVER_IP`{% endraw %} logs you in without asking for the account password. Keep the first session open until this works. It is your safety net.

## 3. Turn off root and password logins

Create the file {% raw %}`/etc/ssh/sshd_config.d/hardening.conf`{% endraw %} with these lines:
{% raw %}

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3


plaintext

Check the config and reload:

sudo sshd -t && sudo systemctl reload ssh


markdown

If `sshd -t` prints nothing, the syntax is fine. Test a new login from a second terminal before closing the first one.

## 4. Enable a firewall

With UFW you allow only what you really need (open 80 and 443 only if you run a website):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable


markdown

## 5. Add Fail2ban

Fail2ban bans IP addresses that keep failing to log in:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban


markdown

The defaults already protect SSH. Check it with `sudo fail2ban-client status sshd`.

## 6. Keep the system updated

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades




Security patches then install by themselves.

## Should you change the SSH port?

Moving SSH from 22 to another port reduces log noise, but it is not real security. Keys and a firewall do the real work. If you change the port, open the new port in the firewall before you reload SSH, otherwise you lock yourself out.

## What if you lock yourself out?

It happens to everyone once. Most providers give you a web console or a rescue mode that does not depend on SSH. Before you start, find where that is in your control panel, so you know it exists.

## Summary

A normal user, key-only login, no root over SSH, a firewall and Fail2ban stop almost all automated attacks. It takes ten minutes, and you only do it once per server.

A longer version with explanations is in our guide: https://buran.host/guides/ssh-hardening

If you are looking for a server to practice on, our plans start here: https://buran.host/vps

Run a Telegram Bot 24/7 on a VPS: Python, systemd and Auto-Restart

Buran Host — Wed, 28 Oct 2026 21:50:38 +0000

Disclosure: I run Buran.host, a small VPS reseller, so that is the example I use. The steps work on any Ubuntu 22.04 or 24.04 VPS.

A Telegram bot that lives on your laptop dies when the laptop sleeps. A small VPS fixes that: it is always on, it has a stable IP, and systemd restarts your bot if it crashes or the server reboots. Here is the whole setup, start to finish.

What you need

A VPS with Ubuntu 22.04 or 24.04 (a bot needs very little, 1 GB of RAM is plenty for most bots)
SSH access
A bot token from @botfather## 1. Create a user for the bot

Do not run the bot as root. If the bot has a bug, you want it to be able to damage as little as possible.

adduser --disabled-password --gecos "" botuser

2. Install Python and create a virtual environment

apt update && apt install -y python3-venv python3-pip git
sudo -u botuser python3 -m venv /home/botuser/venv

Copy your bot code to /home/botuser/bot/ (git clone or scp), then install the dependencies:

sudo -u botuser /home/botuser/venv/bin/pip install python-telegram-bot

Use whatever library your bot already uses. The systemd part is the same for aiogram, telebot or anything else.

3. Keep the token out of the code

Put the token in an environment file that only the bot user can read:

echo 'BOT_TOKEN=123456:your-token-here' > /home/botuser/bot.env
chown botuser:botuser /home/botuser/bot.env
chmod 600 /home/botuser/bot.env

In Python read it with os.environ["BOT_TOKEN"]. Never commit the token to git. If it leaks, revoke it in @botfather with /revoke.

4. Write the systemd unit

Create /etc/systemd/system/tgbot.service:

[Unit]
Description=Telegram bot
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/bot
EnvironmentFile=/home/botuser/bot.env
ExecStart=/home/botuser/venv/bin/python main.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

The two lines that matter are Restart=always and RestartSec=5: if the process dies for any reason, systemd starts it again after five seconds.

5. Start it and enable it on boot

systemctl daemon-reload
systemctl enable --now tgbot
systemctl status tgbot

enable makes the bot start after a reboot. Send your bot a message in Telegram to confirm it answers.

6. Read the logs

journalctl -u tgbot -f

This follows the bot output live. Python errors, restarts and crashes all show up here, so it is the first place to look when something goes wrong.

7. Updating the bot

cd /home/botuser/bot && sudo -u botuser git pull
systemctl restart tgbot

Polling or webhook?

For most small bots, long polling is the simplest choice: no domain, no HTTPS certificate, nothing exposed to the internet. Webhooks make sense when you have many users and want Telegram to push updates to you. Then you need a domain and HTTPS, for example with Caddy in front of the bot.

A few mistakes to avoid

Running as root. Use a separate user, as above.
Hard-coding the token. Use the env file.
No restart policy. Without Restart=always one unhandled exception ends your bot until you notice.
Running two copies of the same bot. Telegram returns a "conflict" error if two processes poll with the same token. Stop the old one first.

Want a longer version?

I wrote a step-by-step guide with the same commands here: https://buran.host/guides/deploy-telegram-bot

If you need a server for it, plans start at €12/month with a dedicated IPv4 address: https://buran.host/vps

Self-Host Your Password Manager on a VPS: Vaultwarden + Caddy in 15 Minutes

Buran Host — Wed, 28 Oct 2026 09:54:59 +0000

Disclosure: I run Buran.host, a small VPS reseller, so I show everything on my own server. The steps work on any Ubuntu 22.04/24.04 VPS with Docker.

Vaultwarden is a lightweight Rust implementation of the Bitwarden server. It works with all the official clients (browser extensions, iOS/Android and desktop apps), and the vault is a single directory with SQLite on your own server. It uses roughly 100–200 MB of RAM, so even the smallest plan is enough.

1. Firewall and directory

apt update && apt install -y ufw
ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp && ufw --force enable
mkdir -p /opt/vaultwarden/data && cd /opt/vaultwarden
echo "ADMIN_TOKEN=$(openssl rand -base64 48)" > .env   # save this token

Docker must be installed (on Ubuntu: curl -fsSL https://get.docker.com | sh).

2. docker-compose.yml

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    env_file: .env
    environment:
      - DOMAIN=https://vault.example.com
      - SIGNUPS_ALLOWED=true
      - WEB_VAULT_ENABLED=true
    ports:
      - "127.0.0.1:8085:80"
    volumes:
      - ./data:/data

The port is bound to 127.0.0.1 only: the service reaches the internet through Caddy. Start it with docker compose up -d.

3. HTTPS with Caddy

Point an A record for vault.example.com at your server's IP first. Then:

apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
vault.example.com {
    reverse_proxy 127.0.0.1:8085
}
EOF
systemctl reload caddy

Caddy obtains and renews the Let's Encrypt certificate by itself.

4. Close registration

Open https://vault.example.com, create your account and immediately change SIGNUPS_ALLOWED=true to false in docker-compose.yml, then run docker compose up -d again. Otherwise anyone who finds the address can create an account on your server.

The admin panel lives at /admin. Here the token is stored in plain form: that is acceptable for a personal server, but the project recommends storing an Argon2 hash in ADMIN_TOKEN (generated with the vaultwarden hash command) if you keep the admin panel enabled.

5. Connect your clients

In any Bitwarden client, choose Self-hosted on the login screen and enter https://vault.example.com. After that, sign in as usual.

6. Backups — do not skip this

The whole vault is the ./data directory. Keep a copy outside this server: for example an encrypted restic repository on a nightly systemd timer. A copy on the same disk will not save you if the server itself is lost. Test the restore: a backup you have never restored is a hope, not a backup.

What you get

Your own password server: your domain, your disk, updates in your hands. The one honest downside: administration is now your job — image updates, backups, monitoring.

A longer version with FAQ: https://buran.host/guides/vaultwarden-vps

How to Pay for a VPS with USDT, BTC or TON — No Card, No KYC

Buran Host — Wed, 28 Oct 2026 09:54:14 +0000

Disclosure: I run Buran.host, a small VPS reseller. The steps below are the same for most crypto-friendly hosts, but I use our own checkout as the example.

If you've ever had a card declined by a hosting provider — or simply don't want to hand over a passport to rent a Linux box — paying in crypto is a practical alternative. Here is how it works end to end, and the mistakes that actually cost people money.

1. Pick a plan and open an invoice

Choose a server, click "Order" and register with an email address you really read: the invoice, the login details and all renewal reminders go there. The invoice shows an exact amount and a payment address.

2. Pick the coin — and the right network

Send the same asset on the same network that the invoice names. USDT in particular exists on several networks (TRC-20, ERC-20, TON and others), and they are not interchangeable. USDT sent on the wrong network usually can't be recovered, because the receiving address doesn't control that chain.

3. Send the exact amount

Copy the address from the invoice, never retype it, and compare the first and last characters after pasting. If you send too little, the invoice stays open; if you send too much, the difference is normally credited to your account balance.

4. Wait for confirmations

TRC-20 and TON usually confirm in under a minute; BTC takes about ten minutes per confirmation. Once the network confirms, the invoice is marked paid and the server is provisioned automatically — typically a few minutes later you receive the IP address, root credentials and a link to the control panel.

Mistakes that cost real money

Wrong network. The classic one. Check twice.
Sending from an exchange and expecting instant arrival. Exchanges batch withdrawals; allow extra time.
Posting screenshots that show your address and balance. Not dangerous, but pointless.

What a legitimate provider never asks for

A seed phrase, a private key, or remote access to your computer. Payment goes to the address on your invoice — nowhere else. If someone claiming to be "support" asks you to send crypto to a different address, it is not the provider.

Do I need ID?

For crypto invoices at our checkout, no documents are required. Card payments go through a payment processor, which may run its own standard checks.

Want the full walkthrough?

A longer step-by-step version, with a short FAQ: https://buran.host/guides/pay-with-crypto

Plans start at €12/month for 4 vCPU, 8 GB RAM and 100 GB SSD with a dedicated IPv4 address: https://buran.host/vps