Skip to main content
Securing a Hetzner Server: Stop SSH Brute Force, Control Logs and Keep Snapshots Small

Securing a Hetzner Server: Stop SSH Brute Force, Control Logs and Keep Snapshots Small

Why Server Security Also Saves Disk Space

Publicly reachable servers are scanned automatically around the clock – especially on SSH. These access attempts are usually harmless, but they lead to a problem that is often underestimated: growing log files.

Unbounded system, auth or Docker logs make snapshots larger, backups slower and waste disk space for no reason. A few targeted measures prevent that reliably.

1) First Analysis: Where Is the Space Going?

Before cleaning up or hardening anything, it helps to understand what is taking up space:

# Overview of the disks
df -h

# Largest directories
du -sh /* 2>/dev/null | sort -hr | head -20

# Size of the systemd journals
journalctl --disk-usage

# Largest log directories
du -sh /var/log/* | sort -hr | head -10

Typical trouble spots with SSH scans:

  • /var/log/journal (systemd-journald)
  • /var/log/auth.log (authentication attempts)
  • /var/log/btmp (failed logins)

2) Cap journald

By default, systemd-journald is allowed to use a lot of space. A limit stops it growing forever:

# One-off cleanup
journalctl --vacuum-size=100M

Recommended permanent limits:

nano /etc/systemd/journald.conf
SystemMaxUse=200M
SystemMaxFileSize=50M
RuntimeMaxUse=50M
systemctl restart systemd-journald

3) Harden SSH: Keys Instead of Passwords

The single most important security measure for any server: SSH access via keys only. Password logins are vulnerable to brute force and generate a lot of unnecessary log noise.

Important: before disabling password logins, always confirm in a second terminal that your SSH key works.

nano /etc/ssh/sshd_config

Recommended settings:

PubkeyAuthentication yes
PasswordAuthentication no

Optional (recommended):

PermitRootLogin prohibit-password

Restart SSH (Ubuntu 24.04):

systemctl restart ssh

4) Fail2Ban: Automatic Defense

Fail2Ban watches log files and bans IPs automatically once there are too many failed attempts. That cuts down attack attempts and log spam considerably.

apt update && apt install -y fail2ban

A minimal sensible configuration:

cat > /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 86400
EOF

systemctl enable fail2ban
systemctl restart fail2ban

Check the status:

fail2ban-client status sshd

5) Keep Firewall Rules Strict

Whether you use UFW or the Hetzner Cloud Firewall, the same rule applies:

  • Only open the ports you actually need
  • Keep everything else closed

If SSH is moved to an alternative port (1234, for example):

  • Allow port 1234
  • Close port 22

Changing the port is not a security feature in itself, but it noticeably reduces automated scan traffic on port 22.

6) Optional: Change the SSH Port (Ubuntu 24.04)

An example using the alternative port 1234:

# Backup
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

nano /etc/ssh/sshd_config
Port 1234

Ubuntu 24.04 uses a socket by default that can force port 22:

systemctl stop ssh.socket
systemctl disable ssh.socket
systemctl enable ssh.service
systemctl restart ssh.service

Check the port:

ss -tlnp | grep ssh

Test the connection:

ssh -p 1234 -i ~/.ssh/your_key user@SERVER-IP

7) Limit Docker Logs

Docker logs can grow unnoticed too. Global log rotation prevents that:

nano /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
systemctl restart docker

Conclusion

Solid server hardening does not come from a pile of exotic tools, but from a few consistent measures:

  1. SSH keys instead of passwords
  2. Fail2Ban enabled
  3. A minimal firewall
  4. Capped logs

That keeps the server quiet and secure – and snapshots only grow because of real data, not pointless log spam.