How to Set Up an Encrypted SWAP Partition on Existing Debian 12

Encrypting swap on an existing Debian 12 system is worthwhile when you want to prevent memory pages, passwords, document fragments, and other transient data from being written to disk as plaintext. For a machine that does not need hibernation, Debian documents a simple design: put the swap partition behind plain dm-crypt and generate a fresh random encryption key at every boot.

This guide uses that design. It assumes Debian 12 “bookworm,” a dedicated swap partition, and systemd as the init system. The commands are deliberately conservative because a mistake in a block-device path can overwrite the wrong partition. Read the decision points first, then substitute your own device identifiers rather than copying the example values blindly.

Debian’s cryptsetup documentation describes encrypted swap specifically and recommends deactivating swap, adding the partition to /etc/crypttab with /dev/urandom, changing /etc/fstab to the mapped device, and then reactivating swap. See the Debian cryptsetup README. Debian 12’s crypttab(5) manual also documents the crypttab fields and plain dm-crypt options.

Should you use random-key encrypted swap?

Use it when you want encrypted swap and do not need hibernation. The key is regenerated at every boot, so old swap contents become unreadable after shutdown. That is exactly the security property most desktop and server installations want.

Do not use this exact setup if you rely on hibernation, suspend-to-disk, hybrid sleep, or suspend-then-hibernate. Resume requires the next boot to decrypt the same hibernation image. A new random key makes that impossible. Debian explicitly notes that random-key swap cannot be used as a resume device. Debian 12’s systemd hibernate-resume documentation likewise shows that resume depends on a persistent resume device.

If hibernation is a requirement, use a persistent encryption design such as a LUKS-backed swap device with an appropriate unlock and resume configuration instead. That is a different setup and is intentionally outside this guide.

Is your swap already protected by disk encryption?

Check before changing anything. If your swap logical volume already lives inside a LUKS-encrypted container, adding another dm-crypt layer may provide little practical benefit while increasing complexity.

swapon --show
lsblk -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,PARTUUID

Look at the device shown by swapon --show and trace its parents in lsblk. A common unencrypted layout might show /dev/sda3 directly as type swap. An encrypted-LVM installation may instead show swap beneath a crypto_LUKS parent.

The distinction matters because this article is about converting an unencrypted dedicated swap partition. If swapon --show reports a swapfile instead, use a swapfile-specific procedure. If the swap is already inside encrypted storage, first decide whether a second layer is actually necessary.

What should you record before turning swap off?

Record the exact partition path, its size, and its PARTUUID. A PARTUUID identifies the partition-table entry and remains useful even after the swap signature inside the partition is replaced by encrypted data.

For example:

sudo blkid /dev/sda3
ls -l /dev/disk/by-partuuid/

You may see output containing a value such as:

PARTUUID="11111111-2222-3333-4444-555555555555"

In the examples below, the corresponding stable path is:

/dev/disk/by-partuuid/11111111-2222-3333-4444-555555555555

Avoid relying on /dev/sda3 if disk enumeration could change. Also avoid using the old swap filesystem UUID as the long-term source identifier: the encrypted-swap setup recreates the swap signature on the mapped encrypted device, so that old raw-swap UUID is not the right persistent identity for the underlying partition.

1. How do you prepare the system safely?

Install cryptsetup if it is not already present, then back up the two configuration files you will edit.

sudo apt update
sudo apt install cryptsetup
sudo cp -a /etc/crypttab /etc/crypttab.before-encrypted-swap 2>/dev/null || true
sudo cp -a /etc/fstab /etc/fstab.before-encrypted-swap

If /etc/crypttab does not yet exist, that is not a problem; create it when you edit the configuration.

Next, make sure the system has enough available memory for the short period while swap is disabled. Then turn off only the swap partition you are converting. Using the exact device is safer than swapoff -a on a machine with several swap areas:

sudo swapoff /dev/sda3
swapon --show

Do not run mkswap on the raw partition after this point. The swap signature should be created on the encrypted mapper device, not on the unencrypted backing partition.

2. What belongs in /etc/crypttab?

Create or edit /etc/crypttab and add one entry for the encrypted swap mapping. The following follows the Debian cryptsetup documentation:

cswap /dev/disk/by-partuuid/11111111-2222-3333-4444-555555555555 /dev/urandom plain,cipher=aes-xts-plain64,size=256,swap

Replace the example PARTUUID with the one from your system.

The fields mean:

• cswap is the mapper name, creating /dev/mapper/cswap.
• The second field is the actual underlying swap partition.
• /dev/urandom supplies a new random key whenever the mapping is created.
• plain selects plain dm-crypt rather than a persistent LUKS header.
• cipher=aes-xts-plain64,size=256 makes the plain-dm-crypt parameters explicit instead of depending on defaults that may change.
• swap tells the cryptsetup integration that this mapped device is swap and should be initialized appropriately.

Podręcznik crypttab Debiana ostrzega, że ​​zwykły dm-crypt nie przechowuje metadanych dotyczących szyfru, skrótu ani rozmiaru klucza w nagłówku, w przeciwieństwie do LUKS. Dlatego jawne zapisywanie szyfru i rozmiaru klucza jest przydatne. Podręcznik dokumentuje również discardimplikacje bezpieczeństwa, ale zwraca na nie uwagę; nie dodawaj tego tylko dlatego, że urządzeniem bazowym jest dysk SSD, chyba że rozważyłeś ten kompromis.

3. Jakie zmiany w /etc/fstab?

Znajdź starą, niezaszyfrowaną linię wymiany w pliku /etc/fstab. Może ona używać identyfikatora UUID, ścieżki urządzenia lub innego trwałego identyfikatora. Na przykład:

UUID=OLD-SWAP-UUID none swap sw 0 0

Zastąp je zmapowanym zaszyfrowanym urządzeniem:

/dev/mapper/cswap none swap sw 0 0

Nie pozostawiaj obu wpisów aktywnych. Jeśli zarówno partycja surowa, jak i partycja /dev/mapper/cswapwymiany są włączone jako partycja wymiany, zaprzeczysz celowi szyfrowania partycji i ryzykujesz pomyłkę w aktywacji podczas rozruchu.

Podręcznik fstab(5) systemu Debian definiuje format wpisów wymiany, natomiast swapon(8) wyjaśnia, w jaki sposób aktywowane są wpisy oznaczone jako wymiana.

4. Jak aktywować i zweryfikować urządzenie przed ponownym uruchomieniem?

Po zapisaniu obu plików należy rozpocząć szyfrowane mapowanie, a następnie włączyć wpis wymiany. Dokumentacja cryptsetup Debiana używa:

sudo cryptdisks_start cswap
sudo swapon -a

Teraz sprawdź wszystkie trzy warstwy:

swapon --show
sudo cryptsetup status cswap
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS

Prawidłowy wynik powinien pokazywać wymianę na /dev/mapper/cswappartycji oryginalnej, a nie bezpośrednio na niej. cryptsetup status cswapPowinien również zgłaszać mapowanie jako aktywne.

Jeśli cryptdisks_startnie jest dostępny w instalacji, nie improwizuj poleceń destrukcyjnych. Sprawdź ponownie, czy cryptsetuppakiet jest zainstalowany i czy składnia crypttab jest poprawna. Możesz również pozwolić, aby normalny proces rozruchu Debiana utworzył mapowanie po zakończeniu konfiguracji wznowienia poniżej. Debian 12 używa generatorów systemd do tłumaczenia konfiguracji crypttab i fstab na jednostki rozruchowe.

5. Czy trzeba wyłączyć wybudzanie ze stanu hibernacji?

Tak, jeśli ta partycja została skonfigurowana jako urządzenie wznawiania systemu. Klucz losowy nie może odszyfrować obrazu hibernacji zapisanego przy użyciu poprzedniego klucza. Instrukcje szyfrowanej partycji wymiany Debiana wyraźnie nakazują administratorom wyłączenie wznawiania podczas konwersji starej partycji wymiany wznowienia na szyfrowaną partycję wymiany z kluczem losowym.

Sprawdź aktualną konfigurację:

grep -R "^[[:space:]]*RESUME=" /etc/initramfs-tools/conf.d/ 2>/dev/null

Jeśli dotyczy to partycji wymiany, którą właśnie przekonwertowałeś, ustaw opcję wznowienia na none:

echo "RESUME=none" | sudo tee /etc/initramfs-tools/conf.d/resume
sudo update-initramfs -u

To jest właśnie ten moment, w którym update-initramfs -ujest to istotne. Nie musisz odbudowywać initramfs tylko dlatego, że zmienił się standardowy wpis wymiany po uruchomieniu; musisz go zaktualizować, usuwając stary cel wznowienia hibernacji, którego initramfs mógłby w przeciwnym razie użyć.

Test ponownego uruchomienia: co potwierdza działanie konfiguracji?

Ponowne uruchomienie jest możliwe dopiero po zakończeniu aktywacji na żywo i poprawieniu plików konfiguracyjnych:

sudo reboot

Po powrocie systemu uruchom:

swapon --show
sudo cryptsetup status cswap
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
cat /proc/swaps

Kluczowe kryteria sukcesu są proste:

• /dev/mapper/cswapjest aktywny jako swap.
• Surowa partycja zapasowa nie jest bezpośrednio wymieniona jako aktywna partycja wymiany.
• cryptsetup status cswapinformuje o aktywnym mapowaniu zwykłego dm-crypt.
• Maszyna uruchamia się bez pytania o hasło wymiany; losowy klucz jest generowany automatycznie.

Można również dwukrotnie zrestartować komputer i porównać zachowanie mapowania. Celem tego projektu jest ulotność klucza szyfrującego; zawartość pliku wymiany z poprzedniego rozruchu nie będzie możliwa do odzyskania po odtworzeniu mapowania.

Co się stanie, jeśli maszyna przejdzie w tryb awaryjny?

Najczęstszymi przyczynami są nieprawidłowa ścieżka do urządzenia zapasowego, literówka w pliku /etc/crypttablub /etc/fstablinia, która nadal wskazuje na starą, surową partycję wymiany. Uruchom system w trybie odzyskiwania lub użyj środowiska ratunkowego, zamontuj system plików główny do odczytu i zapisu i w razie potrzeby przywróć kopie zapasowe.

Przydatne kontrole obejmują:

sudo cryptsetup status cswap
systemctl status systemd-cryptsetup@cswap.service
systemctl status dev-mapper-cswap.swap
journalctl -b -u systemd-cryptsetup@cswap.service

Nazwy jednostek mogą być zapisywane inaczej w przypadku nietypowych nazw map, dlatego należy z nich korzystać, systemctl list-units '*cryptsetup*'jeśli dokładna nazwa usługi nie jest oczywista.

A co z utylizacją dysków SSD?

Nie włączaj domyślnie opcji „disclaim” tylko po to, by uzyskać teoretyczną wydajność dysku SSD. Dokumentacja crypttab Debiana stwierdza, że ​​przesyłanie żądań „disclaim” przez urządzenie szyfrowane ma wpływ na bezpieczeństwo. Podręcznik „swapon” Debiana również zauważa, że ​​funkcja „disclaim” może poprawić wydajność niektórych dysków SSD, ale często tak nie jest. Jeśli jej potrzebujesz, najpierw przeanalizuj swój model pamięci masowej i model zagrożenia, a następnie dodaj ją celowo.

Czy zaszyfrowana partycja wymiany jest nadal użyteczna, jeśli system plików główny jest niezaszyfrowany?

Tak, ale należy zrozumieć tę granicę. Szyfrowana partycja wymiany chroni strony pamięci zapisane na partycji wymiany. Nie szyfruje plików zapisanych w niezaszyfrowanym systemie plików głównym lub domowym, historii powłoki, pamięci podręcznej aplikacji, zrzutów awaryjnych, plików tymczasowych ani logów. Jeśli celem jest szeroko zakrojona ochrona przed ujawnieniem danych w wyniku kradzieży dysku, szyfrowanie całego dysku lub systemu plików zapewnia pełniejszą kontrolę.

Ostateczna lista kontrolna

• Sprawdź, czy cel jest dedykowaną, niezaszyfrowaną partycją wymiany, a nie plikiem wymiany i czy nie jest już chroniony przez zaszyfrowane urządzenie nadrzędne.
• Zapisz stabilną ścieżkę partycji, taką jak /dev/disk/by-partuuid/....
• Przed skonfigurowaniem dm-crypt należy wyłączyć surową wymianę.
• Dodaj wpis plain-dm-crypt z losowym kluczem do /etc/crypttab.
• Wskaż /etc/fstabtylko /dev/mapper/cswap.
• Aktywuj mapowanie i zweryfikuj je przed ponownym uruchomieniem.
• Jeśli stara wymiana była urządzeniem wznawianym, ustaw RESUME=nonei uruchom update-initramfs -u.
• Po ponownym uruchomieniu sprawdź, czy jako partycja wymiany aktywny jest wyłącznie zaszyfrowany maper.

W przypadku systemów Debian 12, które nie posiadają hibernacji, takie podejście pozwala zachować niewielką konfigurację i uniknąć przechowywania trwałego klucza wymiany. Kluczową decyzją nie jest pytanie „które polecenie szyfrowania powinienem uruchomić?”, ale czy losowa wymiana klucza spełnia wymagania dotyczące zarządzania energią. Po ustaleniu tego, reszta to kontrolowana migracja z surowej partycji wymiany do mapowania dm-crypt, które jest bezpiecznie odtwarzane przy każdym uruchomieniu.