---
description: "Harden a Verda GPU instance with SSH key-only access, firewall rules, user permissions, and patching practices that keep your workloads well protected."
revision_date: 04.08.2026
---

# Securing Your Instance

Depending on your setup, adding basic security to your GPU instance can be an important first step.

We will install and configure `fail2ban` & `ufw`. This guide assumes you are logged in as a non-root user. If logged in as root, you do not need to prepend the commands with `sudo`.

```bash
sudo apt update
sudo apt install fail2ban
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo apt install ufw
sudo ufw allow ssh
sudo ufw enable
```

* Fail2ban will block IP addresses that continuously attempt to connect to your machine in the hopes of finding a weak password, for example. 
* Ufw is a firewall management tool that will block access to all ports unless otherwise specified. 

!!! warning
    `ufw` with default settings [will not block traffic to Docker](https://docs.docker.com/network/packet-filtering-firewalls/#docker-and-ufw). In case you plan to run Docker containers on your instance, please make sure to configure your firewall rules appropriately.


That's all! Your VPS is now equipped with a firewall and basic protection against automated machines trying to break in. Check your firewall status and fail2ban status with respective commands:

```bash
sudo ufw status
sudo fail2ban-client status
sudo fail2ban-client status sshd
```

You might be surprised how many bad actors are trying to obtain access to your server!

## Extra hardening

`fail2ban` and `ufw` cover the basics. If your instance is exposed to the
public internet long-term, a few extra steps meaningfully reduce your attack
surface:

### Enable automatic security updates

```bash
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
```

This installs security patches as they're published, without you having to
log in and run `apt upgrade` yourself.

### Disable SSH password authentication

Only do this once you've confirmed key-based login works — test it in a
**second terminal** before closing your current session, or you may lock
yourself out.

```bash
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload ssh
```

`sudo sshd -t` validates the config before it's applied — if it prints an
error, stop and fix it before reloading.

### Harden `sshd_config` further

```bash
sudo sed -i 's/^#\?MaxAuthTries.*/MaxAuthTries 5/' /etc/ssh/sshd_config
echo "AllowUsers your_username" | sudo tee -a /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload ssh
```

* **`MaxAuthTries 5`** limits how many login attempts a single SSH
  connection gets before being dropped, on top of what `fail2ban` already
  does at the IP level.
* **`AllowUsers`** (or `AllowGroups`, if you manage access by group)
  restricts SSH login to an explicit allowlist of accounts. Replace
  `your_username` with the account(s) that actually need SSH access —
  every other local account is then blocked from logging in over SSH at
  all, existing or future.

### Connecting to JupyterLab securely

If you want to run a service like Jupyter Notebook, you will need to forward a port from your local computer over the SSH for that. The default port for Jupyter Notebook is `8888`

To have the port forward, please add the forwarding options to the SSH command:

```bash
ssh -L 8888:localhost:8888 root@IP_OF_YOUR_INSTANCE
```