VPS för krypterad lagring (LUKS, ärlig om gränserna)

„Krypterad VPS" är en fras många värdar slänger sig med utan att säga vad den skyddar mot. Vi är hellre rakt på sak, för de som bryr sig om detta bryr sig om noggrannhet. Du kan köra krypterad lagring på en VPS — en LUKS-krypterad datavolym du låser upp med en lösenfras — och den skyddar verkligen din data i vila. Vad den inte gör är att göra en körande server osynlig för den som kontrollerar den fysiska hårdvaran. Här är den ärliga formen av det, och hur du sätter upp det.

Vad kryptering på en VPS gör — och inte

Vad som är äkta: en LUKS-volym är chiffertext när den är låst. Stäng av servern, eller lås helt enkelt inte upp volymen, och filerna är oläsbara utan din lösenfras. En disk som avvecklas, avbildas kallt eller beslagtas i avstängt läge lämnar inget läsbart. Det är ett äkta, värdefullt skydd — och det är det vanliga hotet för de flesta (en pensionerad disk, en kall snapshot, tillfällig åtkomst).

Vad som inte är det: så länge volymen är monterad och servern kör finns krypteringsnyckeln i RAM, och leverantören driver hypervisorn under din VM. Fullständig diskkryptering på vilken VPS som helst — vår eller någon annans — kan inte skydda en körande, upplåst volym från en beslutsam operatör av den fysiska maskinen. Varje värd som lovar annat översäljer. Det gör vi inte.

Alltså: äkta skydd i vila, ärliga gränser live. Den avvägningen är värd det för ett privat datalager du håller oläsbart i vila — parat med KYC-fri registrering så att lagret inte ens är knutet till din identitet från början.

Sätt upp en LUKS-krypterad volym (Ubuntu 24.04)

# encrypt a data file/volume with LUKS; keep the passphrase OFF the server
apt update && apt install -y cryptsetup

# create a 20 GB encrypted container (or point at a raw data disk)
fallocate -l 20G /srv/secure.img
cryptsetup luksFormat /srv/secure.img        # sets your passphrase
cryptsetup luksOpen  /srv/secure.img secure  # unlock → /dev/mapper/secure
mkfs.ext4 /dev/mapper/secure
mkdir -p /mnt/secure && mount /dev/mapper/secure /mnt/secure
# your files live in /mnt/secure — ciphertext once closed

Efter en omstart förblir volymen låst tills du själv låser upp den:

cryptsetup luksOpen /srv/secure.img secure   # enter passphrase over SSH
mount /dev/mapper/secure /mnt/secure

Lagra aldrig lösenfrasen på servern. Lås upp manuellt (eller pipa den via din SSH-session) så att nyckeln bara finns i minnet medan du använder den. Lägg den inte i ett boot-skript — det omintetgör poängen.

Ärlig omfattning, en gång till

• Skyddar: data i vila — avstängd, före upplåsning, kall snapshot, pensionerad disk.
• Skyddar inte: en körande, upplåst volym från någon med fysisk/hypervisor-kontroll.
• Inte anonymitet i sig: din server har fortfarande en publik IP och trafik på ledningen. Det här handlar om konfidentialitet för data i vila, kombinerat med KYC-fri fakturering.

Om din hotmodell är juridiskt tryck snarare än en stulen disk är den mer meningsfulla signalen vår warrant canary — ett daterat uttalande om att vi inte haft hemliga order eller krav på att försvaga säkerheten, hållet aktuellt. En canary du kan bevaka slår ett krypteringsmärke du inte kan verifiera. Se även den ärliga genomgången av anonym VPS om vad KYC-fritt ger dig och inte.

Varför EQVPS för krypterad lagring

• Full root, så LUKS och ditt upplåsningsflöde är helt dina — ingen nyckeldeponering hos leverantören, ingen vid boot lagrad lösenfras om du inte väljer det.
• Ingen KYC, kryptobetalning. E-post för att registrera, USDC/USDT för att betala — lagret är inte svetsat till din identitet.
• EU (Tyskland, Finland), verklig dataskyddslag, en offentlig warrant canary, root på ~60 sekunder.

Anonym VPS, KYC-fri — den ärliga versionen → · Självhosta Vaultwarden (krypterat valv) →