This post documents the process of purchasing a used dedicated server from Hetzner Server Auction and configuring it as a hardened Ubuntu 26.04 system with RAID1 NVMe storage. The target hardware is an Intel i7-7700 with 1TB NVMe drives in software RAID configuration.
Finding and Purchasing the Server
Hetzner provides two tools for locating dedicated hardware outside standard catalog offerings:
Server Auction (www.hetzner.com/sb) lists previously used dedicated servers that have been returned, tested, and offered for resale at discounted prices. Listing prices decrease the longer inventory remains unsold. This market provides access to older but functional hardware such as i7-7700 systems with NVMe storage.
Server Finder (accessed through the Robot interface) provides filterable search across both new and auction inventory. Search parameters include CPU family, RAM capacity, disk type and size, RAID configuration, datacenter location, and price range. This tool efficiently narrows available listings to specific requirements.
For homelab and small production workloads, the auction market offers server-grade reliability at consumer hardware price points. The i7 7700 leased for this post has a built in GPU that can support multiple 2k and 4k transcodes, it’s NVMe storage, so despite it’s age, it will be a reliable work horse.
Pre-Purchase Verification
Before ordering, verify the following specifications:
CPU: The i7-7700 is a Kaby Lake processor with 4 cores, 8 threads, and 3.6GHz base clock. This provides adequate performance for gaming servers and some personal transcoding of videos and media.
Storage: Confirm both NVMe drives have identical model numbers and capacity. Hetzner mixes brands across used inventory pools. Any additional storage required will be added later from the StorageBox portfolio.
RAID implementation: Hetzner dedicated servers use Linux software RAID (mdadm) rather than hardware RAID controllers. RAID configuration occurs during OS installation through the installimage utility.
Datacenter location: Select a facility geographically close to your user base. Available locations include Nuremberg, Falkenstein, Helsinki, and Ashburn.
Setup fee: Auction listings may include one-time setup fees. Calculate total first-month cost before purchasing.
Network allocation: Review included monthly traffic allowance and whether additional IPv4 addresses carry extra charges.
After order completion, Hetzner provisions the hardware and sends root credentials for the rescue system via email. The rescue system is a minimal Linux environment used for disk partitioning and OS installation.
Initial Access and Rescue System
Connect to the rescue system using the provided credentials:
ssh root@<your-server-ip>All partitioning and RAID configuration occurs in the rescue environment before the production OS is installed.
Partitioning and RAID1 Configuration
The installimage script handles both RAID setup and OS installation through a single configuration file rather than manual mdadm and parted commands. Launch the interactive installer, modify the configuration file, then save and exit the editor. The deployment will immediately commence:
installimagePartition Layout Definition
The configuration file defines RAID level and partition structure. For 1TB x2 NVMe RAID1, a typical layout:
DRIVE1 /dev/nvme0n1
DRIVE2 /dev/nvme1n1
SWRAID 1
SWRAIDLEVEL 1
BOOTLOADER grub
PART /boot ext4 1024M
PART swap swap 32G
PART / ext4 allConfiguration notes:
SWRAID 1 and SWRAIDLEVEL 1 instructs installimage to create a Linux software RAID1 array across both NVMe drives before partitioning.
PART / ext4 all allocates remaining space to the root filesystem. For environments requiring separate mountpoints for isolation or granular backup control, split into multiple partitions:
PART /boot ext4 1024M
PART swap swap 32G
PART / ext4 100G
PART /var ext4 200G
PART /home ext4 allEach PART directive creates both the partition and its mountpoint. The installimage utility generates the resulting /etc/fstab automatically, eliminating manual mkfs and mount operations at this stage.
OS Image Selection
The installimage will prompt for this on its first run. The filename of the image is usually the last few lines of the installimage configuration file. Once the deployment is finished, the server needs to be rebooted. This can be done form the command line:
rebootRAID Verification After First Boot
After SSH reconnection to the installed system, verify RAID status:
cat /proc/mdstat
mdadm --detail /dev/md2Confirm both NVMe members appear with active sync status and no degraded markers such as [U_].
Distribution-Specific Variations
Debian: Uses identical installimage workflow. Select a Debian image instead of Ubuntu. Configuration syntax remains unchanged.
CentOS Stream / AlmaLinux / Rocky: Supported by installimage. Verify PART filesystem defaults as some images default to xfs instead of ext4. Set filesystem type explicitly if required.
Arch Linux: Not available as an installimage target. Manual partitioning and mdadm setup from the rescue system is required using commands such as mdadm --create /dev/md0 --level=1 --raid-devices=2 ... followed by bootstrap with pacstrap. This workflow requires significantly more manual configuration than Debian, Ubuntu, or RHEL-family installations.
SSH Configuration and Hardening
After OS installation, configure SSH security. This process applies uniformly across distributions with only service names and package managers differing.
Create Non-Root User
Its a good idea to create a non-root user, the user who will be running scripts and services with as little rights and permissions as are necessary. This means, if an application is compromised, lesser damage is possible. In this case, a user named localadmin is created.
adduser localadmin
usermod -aG sudo localadminOn CentOS, Rocky, and AlmaLinux, the sudo group is named wheel instead of sudo.
Copy SSH Key
From your local machine:
ssh-copy-id localadmin@<server-ip>Verify key-based authentication functions correctly before modifying SSH configuration.
Harden sshd_config
Choose a free port number to replace the standard SSH port with. It can be any free port. Edit /etc/ssh/sshd_config:
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers yourusernameChanging the default port reduces automated bot scanning traffic on port 22. This is not a primary security measure but reduces log noise. The fail2ban configuration below handles authentication attempts on any port.
Restart the SSH service:
systemctl restart ssh # Ubuntu/Debian
systemctl restart sshd # RHEL-familyUpdate Firewall Rules
sudo ufw allow 2222/tcp comment 'SSH'
sudo ufw enable
sudo ufw statusOn RHEL-family distributions:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reloadTest the new port configuration from a second terminal session before closing the original connection to avoid lockout:
ssh -p 2222 yourusername@<server-ip>fail2ban Installation and Configuration
fail2ban monitors log files for repeated failed authentication attempts and temporarily bans source IP addresses at the firewall level. Without this basic protection, many services will simply deny a login and allow the attack to simply cycle through passwords.
With fail2ban, the client IP will get blocked for a period of time.
Installation
sudo apt update && apt install fail2ban -y # Ubuntu/Debian
dnf install fail2ban -y # RHEL-family
pacman -S fail2ban # ArchLocal Jail Configuration
Do not edit jail.conf directly as package updates will overwrite modifications. Create jail.local instead:
sudo nano /etc/fail2ban/jail.local
Create a basic configuration file with a low bantime while testing.
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 4
bantime = 24hConfiguration details:
port = 2222 must match the sshd_config port setting or fail2ban will apply bans to an unused port.
backend = systemd reads log data directly from journalctl rather than text log files. This configuration is correct for Ubuntu 26.04 where sshd logs to the systemd journal by default rather than /var/log/auth.log. On distributions using traditional auth logs, set logpath = /var/log/auth.log for Debian/Ubuntu or logpath = /var/log/secure for RHEL-family systems instead.
Enable and Start Service
sudo systemctl enable fail2ban
sudo systemctl start fail2banVerify SSH Monitoring
fail2ban-client status sshdThe output should show the jail active with filter and action lists. To verify ban functionality, deliberately fail authentication several times from another machine, then check:
fail2ban-client status sshdThe source IP should appear under Banned IP list. Unban after testing, if you started with a low bantime, increase that now. Normally, modern bot farms are doing the infiltration and normally they update their IP addresses often. A bantime of a few hours would then suffice most applications
Unban yourself, if required:
fail2ban-client set sshd unbanip <your-ip>Final Verification Checklist
Before deployment:
mdadm --detail /dev/md2shows a healthy, non-degraded arraydf -hconfirms all intended mountpoints are present with correct sizes- Root login over SSH is disabled and password authentication is disabled
ufw statusor firewalld shows only required ports exposedfail2ban-client status sshdshows the jail active- SSH key authentication on the non-default port is verified from a second machine before closing the rescue system session
- mdadm.conf and fstab are backed up to off-server storage
Summary
An i7-7700 with 1TB RAID1 NVMe from Hetzner Server Auction provides reasonable value for homelab and small production workloads. The CPU is several generations old but remains capable for most server tasks. RAID1 NVMe provides redundancy without the performance limitations of spinning disks. The complete setup process from auction purchase through rescue system configuration, installimage partitioning, SSH hardening, and fail2ban deployment takes approximately 30 to 45 minutes and results in a server that does not accept root password authentication on port 22.
AI assistance is used on this site for language, formatting, and turning research into a consistent template. It is not used to perform the underlying research or verify technical claims. Every command, configuration, and step in this post is tested by hand before publication.