Varmuuskopiointi ja kryptaus?

[qwertyy]

Eli kuten otsikko kertoo, miten itse toimit tai toimisit?

Ajattelin, että josko vihdoin ja viimein saisi varmuuskopiot suositeltuun 1-2-3 järjestelmään. Jos joku ihmettelee tuota, niin suositus on.
1. Yksi kopioista pitää olla säilytettynä jossain muualla
2. Tiedot kahdella erilaisella medialla (Kiintolevy, SSD, nauha-asema jne.)
3. Tiedoista pitää olla kolme kopiota. Käytössä olevat tiedostot ja kaksi varmuuskopiota.

Kohdat kaksi ja kolme toteutuu aika hyvin, ensimmäinen on tekemättä. Sen voisi lähiaikoina viimein toteuttaa. Eli kyseessä olisi siis varmaankin tiedostojen kopiointi jollekin asemalle ja mieluusti sen kryptaus jos jättää aseman esim. työpaikalle josta sen joku voisi löytää jossain vaiheessa.

Veracrypt? Tuossa voisi ilmeisesti käyttää avaimena jotain tiedostoa, mutta miten varmistaa sitten parhaiten sen, että vaikka avaimena käytettävä kuva X pysyy takuuvarmasti korruptoimattomana? Tiedosto johonkin pilvipalveluun ja sen suolat talteen? Karu totuus lienee, että salasanalla kryptaaminen ei ole oikein hyvä tapa enää nykyaikana ja tietysti jos salasana pääsee vielä hukkuun.

Ajatuksia sopivaan tapaan? Joku avoimenkoodin ja multiplatform softa olisi hyviä. Eli mitään Bitlockeria en tuohon aio käyttää.

Kaikki vinkit ja ajatukset on toivottuja. Olettaisin että tämä varmuuskopio on se mikä useimmilla on hiukan huonolla tolalla. En tiedä sitten onko valintani lainkaan hyvä. Ulkoinen isohko USB-asema, jossa ikävä kyllä varmasti on SMR-kiintolevy sisässä, eli suorituskyky lienee kyllä aika heikko useamman teran kanssa, mutta toisaalta. Tähän kopioon ei tietysti toivottavasti joutuisi koskeen. Ajattelin, että SMR-tyyppinen kiintolevy kuitenkin lienee parempi, mitä SSD:t koska asema varmaankin tulee ns. seisomaan jossain paikassa varsin pitkiä aikoja. Olisi tyyliin edes vuosittainen backup jossain "etäjemmassa".

[igor_2]

Sen olen oppinut, että tässä pätee sama kun henk. koht. kirjanpidossa. Jos asiat tekee vaikeamman kautta, niin tekemättä tahtoo pidemmän päälle jäädä. Linuxin Luksilla olen siis kryptannut muussa osoitteessa olevan backup USB -levyn. Kun ei ole valtiosalaisuuksia, niin riittää.

[qwertyy]

Kysyin mielenkiinnosta tekoälyltä, kun monet softat näyttää suosittelevan vähintään 20 merkin salasanoja tai oikeastaan varoittavat käyttämästä alle 20 merkin salasanoja, että kauanko luks tai veracrypt tyyppisen salauksen purkaminen teoreettisesti kestää modernilla huippu näytönohjaimella.

Lyhyesti lainattuna vastauksen kohtaa jossa huomautettiin salasanan muotoilusta.

Termi "10 merkin salasana" ei ole standardi, mutta voimme analysoida sitä käytettyjen merkkien tyypin perusteella. Ero on hämmästyttävä.

Salasanaskenaario (10 merkkiä) Merkistöyhdistelmät Murtamisaika (offline-hyökkäys, huippuluokan näytönohjain)
Vain numerot (esim. 3819662410), merkit 0-9, yhdistelmien määrä 10 miljardia, ratkaisuaika sekunteja.

Vain pienet kirjaimet (esim. passwordie), merkkien määrä 26 (a-z), yhdistemien määrä 141 biljoonaa, ratkaisuaika tunneista muutamaan päivään.

Isot ja pienet kirjaimet (esim. Passwordie) merkkien määrä 52 (a-z, A-Z), yhdistelmien määrä 19 kvadriljoonaa, ratkaisuaika kuukausia.

Kaikki merkit (esim. P@ssw0rd!#) merkkien määrä ~75+ (a-z, A-Z, 0-9, symbolit), yhdistelmien määrä ~577 kvadriljoonaa, ratkaisuaika vuosikymmenistä vuosisatoihin.

Eli aika luotettava lienee jo esim. tuollainen 10 merkin salasana jossa on numerot ja kirjaimet isona ja pienenä. Mutta selkeästi pelkästään pienellä kirjoitettu salasana ei ole tosiaan enää nykypäivää.

Valinnasta antoi seuraavaa LUKS:n ja VeraCryptin välillä.

Choose LUKS if:

You are exclusively a Linux user.
Your primary concern is maximizing resistance against technologically advanced brute-force attacks.
You value the stability and performance that comes from deep kernel-level integration.

Choose VeraCrypt if:
Your threat model includes the possibility of being forced to reveal your password.
You need to access your encrypted data across multiple operating systems (Windows, macOS, Linux).
You prefer creating encrypted file "containers" for portability rather than encrypting entire partitions.

Ultimately, both LUKS and VeraCrypt are top-tier encryption tools. When used with a strong, long password, both will protect your data from all but the most sophisticated and well-resourced adversaries. The "safer" option is the one that best aligns with your personal security needs and your daily workflow.

[nm]

Jos salasanaa ei tarvitse kirjoittaa useita kertoja päivässä, lyhyen ja kryptisen salasanan sijaan usein suositellaan pidempää 20-30 merkin salasanalausetta Siinä voi olla pelkkiä aakkosia tai joku yksittäinen numero joukossa, mutta olennaista olisi, että salasanan oppii ja muistaa helposti.

[qwertyy]

...olennaista olisi, että salasanan oppii ja muistaa helposti.

Tämä on kyllä erittäin oleellista. Joskus kauan sitten ennen kuin käytin salasanamanageria, yritin toteuttaa tämän ykköskohdan ja tein salasanan, joka oli jonkinlainen variaatio jostain ja no... Sinne jäi ne tiedot kun pääsi unohtumaan 😀

No onneksi tuo oli vielä kokeiluvaiheessa ja mitään kriittistä ei hävinnyt kun skannaukset oli vielä muualla tallessa. Suosittelen ihan kirjoittamaan muuten kriittiset salanat ylös jonnekin. Ei vain mainitse käyttökohdetta yhteydessä ja sijainti on jossain hiukan piilossa.

Vielä aiheeseen palatakseni, kävi mielessä että päärakennuksesta erikseen olisi kylmä varasto, jossa on kyllä sähköt ja jonne voisi wifi kantaa. Voisi harkita jotain älypistorasiaa ja laittaa ehkä raspberryn ja siihen jonkin luks:lla suojatun kiintolevyn kiinni. Tuuppaisi vaikka sftp:llä koti NAS:n tiedostot sinne pari kertaa vuodessa ja antaisi muun ajan olla virrattomana. Talvea varten pitäisi kyllä tehdä joku pakkasvahtikotelo tms.

Siihen liittyen
Kokeilin mielenkiinnosta kysyä geminiltä tuollaisen luomisesta ja omaan silmään vaikuttaa toimivalta? Joku LUKS:sta ja SFTP:stä enemmän ymmärtävä varmaankin pystyy vahvistamaan pitäisikö tuon toimia? Oikeastaan tuo loppuohjeen chroot:n tarkoitus menee itsellä ohi. Onko tuon tarkoitus estää sftp käyttäjän pääseminen root käyttäjäksi? Joku tietoturvanäkökulma tuossa varmaankin on?

## Secure Your Data and Access it Remotely: A Guide to a Homenetworked Raspberry Pi with LUKS and SFTP

**Transform your Raspberry Pi into a secure home server, shielding your data with robust LUKS encryption and enabling convenient file transfers via the secure SFTP protocol. This comprehensive guide will walk you through setting up a Raspberry Pi with an encrypted external hard drive that automatically unlocks on boot, and configuring a dedicated SFTP user to access this secure storage.**

This setup is ideal for creating a private, centralized storage solution for your important files, accessible from anywhere within your home network. By leveraging LUKS (Linux Unified Key Setup-on-disk-format), your data will be encrypted at rest, protecting it from unauthorized access even if the physical drive is stolen. SFTP (SSH File Transfer Protocol) ensures that your files are encrypted during transfer, providing a secure alternative to traditional FTP.

### **I. Initial Setup and System Preparation**

Before diving into encryption and file sharing, ensure your Raspberry Pi is properly configured for a stable server environment.

1.  **Install Raspberry Pi OS:** Begin with a fresh installation of Raspberry Pi OS Lite for a minimal, headless setup. You can use the Raspberry Pi Imager to easily write the OS to your microSD card.

2.  **Enable SSH:** During the initial setup or via the `raspi-config` tool (`sudo raspi-config`), enable the SSH server. This is essential for remote management and for SFTP to function.

3.  **Connect to Your Network:** Connect your Raspberry Pi to your home network via an Ethernet cable for the most stable connection.

4.  **Assign a Static IP Address:** To reliably connect to your Raspberry Pi, it's crucial to assign it a static IP address. You can do this by editing the `dhcpcd.conf` file:

    ```bash
    sudo nano /etc/dhcpcd.conf
    ```

    Add the following lines to the end of the file, replacing the example IP addresses with your desired configuration:

    ```
    interface eth0
    static ip_address=192.168.1.10/24
    static routers=192.168.1.1
    static domain_name_servers=192.168.1.1 8.8.8.8
    ```

    Reboot your Raspberry Pi for the changes to take effect.

5.  **Update Your System:** Ensure all your packages are up-to-date:

    ```bash
    sudo apt update && sudo apt upgrade -y
    ```

### **II. Encrypting Your External HDD with LUKS and Automating Mounting**

This section details the process of encrypting your external hard drive and configuring it to automatically unlock and mount at boot using a keyfile. This avoids the need to manually enter a passphrase every time the Raspberry Pi starts.

1.  **Install Cryptsetup:** This utility is essential for managing LUKS encrypted volumes.

    ```bash
    sudo apt install cryptsetup -y
    ```

2.  **Identify Your External Drive:** Connect your external HDD to the Raspberry Pi and identify its device name.

    ```bash
    lsblk
    ```

    Look for your drive in the output (e.g., `/dev/sda`, `/dev/sdb`). Be absolutely certain you have the correct device name to avoid formatting the wrong drive.

3.  **Create a Keyfile:** This file will be used to automatically unlock the encrypted drive.

    ```bash
    sudo dd if=/dev/urandom of=/etc/luks_keyfile bs=1024 count=4
    sudo chmod 0400 /etc/luks_keyfile
    ```

4.  **Format the Drive with LUKS:** This command will create a LUKS encrypted partition on your external drive. **This will erase all data on the target drive.**

    ```bash
    sudo cryptsetup luksFormat /dev/sdX /etc/luks_keyfile
    ```

    Replace `/dev/sdX` with the correct device name of your external drive. You will be prompted to confirm the action.

5.  **Add the Keyfile to the LUKS Header:** This allows the system to use the keyfile for decryption.

    ```bash
    sudo cryptsetup luksAddKey /dev/sdX /etc/luks_keyfile
    ```

6.  **Open the Encrypted Drive:** To format the encrypted volume, you first need to open it.

    ```bash
    sudo cryptsetup luksOpen /dev/sdX secure_storage --key-file /etc/luks_keyfile
    ```

    This will create a new device mapper entry at `/dev/mapper/secure_storage`.

7.  **Format the Encrypted Volume:** Now you can create a filesystem on the unlocked volume.

    ```bash
    sudo mkfs.ext4 /dev/mapper/secure_storage
    ```

8.  **Configure Automatic Mounting:** To have the drive automatically unlocked and mounted at boot, you need to edit `/etc/crypttab` and `/etc/fstab`.

    * **Edit `/etc/crypttab`:**

        ```bash
        sudo nano /etc/crypttab
        ```

        Add the following line:

        ```
        secure_storage /dev/sdX /etc/luks_keyfile luks
        ```

    * **Get the UUID of the Encrypted Volume:**

        ```bash
        sudo blkid /dev/mapper/secure_storage
        ```

        Note the `UUID` from the output.

    * **Create a Mount Point:**

        ```bash
        sudo mkdir /mnt/secure_storage
        ```

    * **Edit `/etc/fstab`:**

        ```bash
        sudo nano /etc/fstab
        ```

        Add the following line, replacing `YOUR_UUID_HERE` with the UUID you noted:

        ```
        UUID=YOUR_UUID_HERE /mnt/secure_storage ext4 defaults 0 2
        ```

9.  **Reboot and Verify:** Reboot your Raspberry Pi. After it restarts, check if the encrypted drive is mounted:

    ```bash
    df -h
    ```

    You should see `/dev/mapper/secure_storage` mounted on `/mnt/secure_storage`.

### **III. Setting Up a Secure SFTP User and Directory**

The final step is to create a dedicated user for SFTP access and restrict them to the encrypted storage.

1.  **Create an SFTP User:** Create a new user who will only have SFTP access.

    ```bash
    sudo adduser sftpuser
    ```

    Follow the prompts to set a password and user details.

2.  **Configure the SSH Server for SFTP Chroot:** Edit the SSH daemon configuration file.

    ```bash
    sudo nano /etc/ssh/sshd_config
    ```

    Add the following lines at the end of the file:

    ```
    Match User sftpuser
        ChrootDirectory /mnt/secure_storage
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no
    ```

3.  **Set Correct Permissions:** For the `ChrootDirectory` to work, the directory itself must be owned by `root`. However, the user needs to be able to write files inside it. We will create a subdirectory for the user to write to.

    * **Change ownership of the mount point:**

        ```bash
        sudo chown root:root /mnt/secure_storage
        ```

    * **Create a writable directory for the user:**

        ```bash
        sudo mkdir /mnt/secure_storage/files
        sudo chown sftpuser:sftpuser /mnt/secure_storage/files
        ```

4.  **Restart the SSH Service:**

    ```bash
    sudo systemctl restart ssh
    ```

### **IV. Transferring Files via SFTP**

You can now use any SFTP client (such as FileZilla, WinSCP, or the command-line `sftp`) to connect to your Raspberry Pi and transfer files.

* **Host:** The static IP address of your Raspberry Pi (e.g., `192.168.1.10`)
* **Username:** `sftpuser`
* **Password:** The password you set for `sftpuser`
* **Port:** The default SSH port, `22`

When you connect, you will be in the `/` directory, which is actually `/mnt/secure_storage`. You will only be able to see and interact with the `files` directory that you have write permissions for.

You have now successfully created a secure, home-networked storage solution with your Raspberry Pi, protecting your data with LUKS encryption and providing secure remote access via SFTP.

[JaniAlander]

Hmmh toi ilmeisesti avaa kryptauksen aina kun Pi käynnistetään automaattisesti?

Mitäs jos koko laite nyysitään?

[qwertyy]

Hmmh toi ilmeisesti avaa kryptauksen aina kun Pi käynnistetään automaattisesti?

Mitäs jos koko laite nyysitään?

Tätä minäkin mietiskelin. Tuo kohta ja eteenpäin kolmonen

2.  **Configure the SSH Server for SFTP Chroot:** Edit the SSH daemon configuration file.

Niin nuo ei ihan täysin auennut itselle. Eli onko tuo jotenkin normaalia turvallisempi? Eikös jos tuon root tunnuksen saa käsiin, niin laite on periaatteessa heti korkattu? No en tiedä sitten kun tuossa on tuo sftp user, että lisääkö tuo turvaa kun ei ole esim. smb päällä jne?


Sen verran tilapäivitystä tuohon VeraCryptin käyttöön, että en tiedä onko tuo oikeinkaan järkevä tuollaisella SMR-asemalla. Taisi käydä niin kuin arvelin. Alkuun data virtasi ok, niin kuin kiintolevylle yllensä, mutta tyyliin tunnin päästä kun kävin katsoon niin datavirta on suorastaan romahtanut. Näyttää kirjoittavan hetken nopeasti ja taas tipahtaa. Dataa noin 3 teraa ja näyttäisi, että liekö joku melkein pari vuorokautta odotettavissa ajaksi. Voisi olla paljon realistisempi ihan vaikka pakata nuo tiedostot vaikka 7zipillä ja käyttää salausta. Se vaikuttaisi omaavan aika hyvät kryptaustoiminnot jo itsessään.

*lisäys*
https://forum.level1techs.com/t/smr-drive-nas-advice/172743

Be aware though, if you want to encrypt them, that it takes a very long time on smr drives.

I once encrypted an 8 TB seagate smr drive with luks.
It took 14 days nonstop.

A 8 TB cmr drive takes ~ 26 hours.

Auts.. Tämän siitä saa kun menee ostaan halvinta. Ja vielä osasin epäillä hitautta ja tietoisesti ostin 

[Whig]

Mitenköhän turvallista tuo on sillä muistan, kun itse peuhasin Raspberry Pi:n ja MicroSD korttien kanssa niin välillä sai olla asentamassa käyttistä uudelleen kortille, kun jokin oli kortin datoja sotkenut.
Tosin silloin syynä saattoi olla lyhyet sähkökatkot tai jokin vastaava mutta olettaisin kryptatun kortin oleven vielä herkempi pienellekkin virheelle.

[qwertyy]

Tuo kryptaisi vain sen ulkoisen liitetyn kiintolevyn, ei itse raspberryn korttia. Mutta tuo on kyllä ihan totta. Raspberry suorastaan vaatii suht laadukkaan muistikortin ja sähkökatko tai erityisesti liian pieni virtalähde kyllä tosiaan sekoittaa tiedostojärjestelmän aika helposti.

[qwertyy]

Ajattelin vielä palata tuohon 2,5" Seagate USB SMR kiintolevyyn. Ei ole kärsimättömän henkilön kapistuksia. Sain kopion tehtyä Veracrypt kontaineriin viimein. 2,7 teraa ja kirjoitusaika n.38h ja tuokin vielä hiukan optimistinen, koska useamman kerran katkesi verkkoyhteys ja FreeFileSync tietysti lopetti kopioinnin ja keskeytti kellon, mutta vaikutti siltä, että tuon keskeytyksen aikana asema ilmeisesti tyhjensi välimuistia asemalle pitkät ajat. Veikkaisin todellisen ajan siis olevan pari täyttä vuorokautta.

No nyt tiedostot on kuitenkin kirjoitettu ja synkronointi FFS:n avulla ei enää vie varmaankaan pitkiä aikoja, mutta silti.

SMR-asemat. Oma suositus välttäkää jos kirjoitatte asemalle esim. +10Gt tiedostoja kerralla. Ostakaa CMR-asemia jos mahdollista. Tekniikka ei ole tässä suhteessa kiintolevyn suhteen kehittynyt ja melkoinen kirous kun valmistajat ei tätä ominaisuutta lähellekään aina selkeästi mainitse.

Jos joku on utelias, että minkälaisia tiedostoja kyseessä, niin hyvin sekalainen kirjo. Useammat tyyliin Windows asennukset, eli todella paljon pieniä tiedostoja ja sitten myös kymmenien gigojen snapshotteja, muutama jopa yli 100gigan kiintolevyn varmuuskopiointikloonaus seassa. Eli hyvin laidasta laitaan.

Mikä Englanti taipuu, niin tällä on aika mielenkiintoisia testejä
https://www.youtube.com/watch?v=hAijmZsTd2A