Raspberry PI
Artikel zum Thema rund um den Raspberry PI
🧩 Einleitung
Viele Administratoren und Entwickler greifen aus Gewohnheit immer noch zu ssh-keygen -t rsa
, wenn sie neue SSH-Schlüssel erzeugen.
Doch das ist — freundlich gesagt — nicht mehr Stand der Technik.
RSA funktioniert zwar noch, aber es ist ineffizient, veraltet und zunehmend unpraktisch, wenn man moderne Systeme sicher administrieren will.
🔐 RSA: Der alte Veteran
RSA war jahrzehntelang der Standard für sichere SSH-Verbindungen.
Aber die Zeit geht weiter:
- Für ausreichende Sicherheit braucht RSA heute mindestens 3072 bis 4096 Bit.
- Das bedeutet:→ Lange Schlüssel,→ mehr Rechenzeit,→ größere Datenübertragung beim Login.
Kurz: funktioniert, aber nicht elegant.
⚙️ Ed25519: Der moderne Nachfolger
Mit Ed25519 hat OpenSSH (ab Version 6.5, 2014) eine neue Kurve eingeführt, die speziell für SSH entwickelt wurde.
Vorteile:
- 🔒 Sicherer bei kürzeren Schlüsseln→ 256 Bit Ed25519 ≈ 4096 Bit RSA
- ⚡ Schneller beim Login und bei Signaturen
- 🧱 Kompaktere Schlüssel (weniger Ballast in authorized_keys)
- 🧠 Deterministisch: keine fehleranfällige Zufallszahlengenerierung
- 🛡️ Empfohlen vom OpenSSH-Projekt selbst
“New users should use Ed25519 keys unless they need to interoperate with legacy systems.”
— OpenSSH Developers
🧮 Praxisbeispiel: Key-Erzeugung
🟢 Moderne Variante
ssh-keygen -t ed25519 -C "meinrechner@home"
Erzeugt:
~/.ssh/id_ed25519
→ privater Schlüssel~/.ssh/id_ed25519.pub
→ öffentlicher Schlüssel
🔴 Alte Variante (nur für Alt-Systeme)
ssh-keygen -t rsa -b 4096 -C "legacy@server"
Nur verwenden, wenn du z. B. mit älteren NAS-Systemen, Routern oder uralten SSH-Versionen arbeiten musst.
🧩 Technischer Vergleich
Merkmal | RSA | Ed25519 |
---|---|---|
Algorithmus | Faktorisierung großer Primzahlen | elliptische Kurve (Curve25519) |
Schlüssellänge | 2048–4096 Bit | 256 Bit |
Sicherheit | gut (bei 4096 Bit) | exzellent |
Geschwindigkeit | langsam | sehr schnell |
Schlüsselgröße | groß | klein |
RNG-Abhängigkeit | ja | nein |
Standardisierung | älter (1977) | modern (2011) |
Empfehlung | nur für Legacy | Standard ab OpenSSH 6.5 |
🔧 Kompatibilitäts-Check
So prüfst du, ob dein Server Ed25519 versteht:
ssh -Q key
Wenn in der Liste ssh-ed25519
auftaucht, bist du sicher.
💡 Fazit
RSA war ein Meilenstein, aber Ed25519 ist der neue Standard.
Wer heute noch RSA verwendet, verschwendet Rechenleistung und verliert an Sicherheitsspielraum.
Wenn du SSH-Schlüssel neu anlegst, gilt:
Immer Ed25519 — außer du musst mit Altgeräten sprechen.
👉 Befehl für neue SSH-Keys:
ssh-keygen -t ed25519 -C "backup@meinserver"
Dann den öffentlichen Key mit
ssh-copy-id user@server
installieren – fertig.
- Details
- Geschrieben von: Michael Küper
- Kategorie: Raspberry PI
- Zugriffe: 62
Ich betreibe einen kleinen Container-Host auf einem Raspberry Pi. Für ein komplexes Sicherungssystem fehlt mir die Zeit – und ehrlich gesagt auch die Notwendigkeit. Trotzdem möchte ich im Fall eines Hardwaredefekts oder Datenverlustes schnell wieder lauffähig sein. Deshalb habe ich mir ein einfaches, aber durchdachtes Sicherungskonzept überlegt, das ich hier kurz vorstellen möchte.
Was soll gesichert werden?
Grundsätzlich sichere ich nur das, was ich wirklich brauche, um meinen Container-Host innerhalb kurzer Zeit wiederherstellen zu können:
-
Die Konfigurationsdateien meiner Container (z. B.
docker-compose.yml
) -
Die Datenverzeichnisse der Container, die ich per Bind Mounts eingebunden habe
-
Wichtige Konfigurationsdateien auf dem Host (z. B.
/etc
und ausgewählte Inhalte von/home/pi
)
Was sichere ich bewusst nicht?
Ich verzichte bewusst auf die Sicherung des gesamten Betriebssystems oder der Container-Images:
-
Container-Images kann ich jederzeit erneut aus dem Internet beziehen
-
Das Betriebssystem (Raspberry Pi OS) ist schnell neu aufgesetzt
-
Der Rest ist in wenigen Minuten per Backup zurückgespielt
Sicherungsmethode in der Praxis
Ich setze auf eine Kombination aus Transparenz und Einfachheit:
-
Alle Container nutzen Bind Mounts statt Docker Volumes
Vorteil: Ich weiß genau, wo die Daten liegen, und kann sie direkt mit
rsync
oder ähnlichen Tools sichern. -
Regelmäßige Sicherung mit rsync
Ich sichere die Mountpoints und Konfigurationsdateien manuell oder per cronjob auf eine externe Festplatte oder ein Netzlaufwerk.
Kurze Übersicht: Was wird gesichert und wie?
Bereich | Sicherungsmethode |
---|---|
Containerdefinitionen | docker-compose.yml |
Datenvolumen (Bind Mounts) | rsync auf externes Ziel |
Host-Konfiguration | Backup von /etc , /home/pi |
Container-Images | nicht gesichert |
Betriebssystem | nicht gesichert |
Beispiel: Bash-Skript zur Sicherung
Hier ein einfaches Beispiel-Skript zur Sicherung wichtiger Verzeichnisse:
#!/bin/bash
BACKUP_DIR="/mnt/backup/rpi-container"
DATE=$(date +%Y-%m-%d)
DEST="$BACKUP_DIR/$DATE"
mkdir -p "$DEST"
# Docker-Konfigurationen sichern
cp /home/pi/docker-compose.yml "$DEST/"
# Datenverzeichnisse sichern (Beispielpfade anpassen)
rsync -a /srv/container-data/ "$DEST/container-data/"
# Host-Konfiguration sichern
rsync -a /etc/ "$DEST/etc/"
rsync -a /home/pi/ "$DEST/home-pi/" --exclude=.cache
# Alte Backups löschen (älter als 30 Tage)
find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
Beispiel: Cron-Job für tägliches Backup um 3 Uhr nachts
Diesen Eintrag kannst du mit crontab -e
hinzufügen:
0 3 * * * /home/pi/backup.sh >> /var/log/backup.log 2>&1
Voraussetzung: Das oben gezeigte Skript liegt unter /home/pi/backup.sh
und ist ausführbar (chmod +x backup.sh
).
Wiederherstellung: So einfach wie möglich
Ziel ist, dass ich im Fehlerfall schnell wieder starten kann:
-
Raspberry Pi neu flashen und Basis-Setup einrichten
-
Konfigurationen zurückspielen
-
Docker installieren und
docker-compose
ausführen
Die Wiederherstellung habe ich bisher noch nicht komplett getestet – das steht demnächst auf meiner Liste.
Fazit
Mein Sicherungskonzept ist einfach, aber effektiv. Es verzichtet bewusst auf Voll-Backups und setzt stattdessen auf Klarheit, Kontrolle und Schnelligkeit. Wer auf seinem Raspberry Pi Container-Hosts betreibt, kann mit wenig Aufwand ein ähnlich schlankes Konzept umsetzen – Hauptsache, man hat überhaupt eines.
- Details
- Geschrieben von: Michael Küper
- Kategorie: Raspberry PI
- Zugriffe: 28
In diesen Beitrag wird das Erstellen eines Subversion Containers beschrieben
Voraussetzungen
- Grundkenntnisse im Umgang mit Linux und Docker
- Ein fertig installierter RaspberryPI mit betriebsbereitem docker
- Ein Verzeichnis in dem die Subversion Repositories abgelegt werden. In dieser Beschreibung wird das Verzeichnis /docker als Basisverzeichnis für diesen und zukünftige Container verwendet.
- Ein Verzeichnis zum Erstellen der Konfiguration für den Container und für die Scripte.
Zu Erstellende Dateien
- Dockerfile enthält die Daten zum Erstellen eines Docker Image
- build.sh ist ein Shell Script und vereinfacht das wiederholte Erstellen des Images
- run.sh ist ebenfalls ein Shell Script zur Vereinfachung des Erzeugens und Startes des Containers
Die Scriptdatein build.sh und run.sh sind nicht unbedingt erforderlich, werden jedoch aus Gründen der Bequemlichkeit und Wiederverwertung angelegt.
Benötigte Dateien erstellen
Dockerfile:
Zum Beginn wählt man als Basis eine Image aus, das für diesen Zwecke geeignet ist oder erstellt ein eigenes Basisimage. Für das Subversion Image wird als Basis das aarch64/alpine Image verwendet, da auf dem RaspberryPI die 64Bit Version des HypriotOS läuft und ein möglichst kleines Image erzeugt werden soll (Das fertige Image ist nur 13,9 MB groß).
FROM aarch/alpine
MAINTAINER Michael Kueper <Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. >
LABEL version latest
LABEL description Simple Subversion Container
RUN apk update \
&& apk upgrade \
&& apk add subversion
VOLUME /var/svn
EXPOSE 3690:3690
CMD svnserve -d -r /var/svn/ --log-file /dev/stdout --foreground
build.sh:
#!/bin/bash
docker build -t blog/rpi-svn .
run.sh:
#!/bin/bash
docker run -d -p 3690:3690 -v /docker/blog-svn:/var/svn --name blog-svn --restart unless-stopped blog/rpi-svn
Angepasstes Image erstellen
Um den Container zu erzeugen wir das Script build.sh aufgerufen. Es erstellt aus dem Basisimage aarch64/alpine ein Image mit der im Dockerfile angegebenen Konfiguration. Während des build Vorgangs werden einige Informationen angezeit, an deren Ende eine Meldung dieser Art erscheinen sollte:
Successfully built 96f2cfda14c2
Nach dieser Meldung ist der Subversion Container erstellt und kann mit dem Script run.sh gestartet weden.
Nach dem Abschluss des Scripts erscheint eine Ausgabe ähnlich der folgenden:
5c46d120a5d6fb33589ed0cb66f68f7491320b6d9ee9abd034222336889769ae
Container erstellen und starten
Mit dem Befehl docker ps -a kann überprüft werden ob der Container korrekt gestartet wurde und läuft. Es sollte eine Ausgabe ähnlich der folgen erscheinen:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5c46d120a5d6 blog/rpi-svn "/bin/sh…" 29 sec.. Up 23 sec... ...:3690->3690 blog-svn
Erstellen eines Repository
Zum Erstellen eines neuen Repository nutzen wir den exec Befehl von docker
docker exec blog-svn svnadmin create /var/svn/neues_repository
Zur weiteren Konfiguration des Reposit kann im vorgegebenen Host Verzeichnis, in diesem Script /docker/blog-svn/neues_repository/, die weitere Konfiguration erfolgen.
Es muss festgelegt werden, auf welche Weise schreibberechtigte Benutzer sich Authentizieren müssen. Das wird in der Datei /docker/blog-svn/neues_repository/conf/svnserve.conf eingetragen. In diesem Fall soll das über eine Passwort Datei erfolgen.
[general]
### The anon-access and auth-access options control access to the
### repository for unauthenticated (a.k.a. anonymous) users and
### authenticated users, respectively.
### Valid values are "write", "read", and "none".
### Setting the value to "none" prohibits both reading and writing;
### "read" allows read-only access, and "write" allows complete
### read/write access to the repository.
### The sample settings below are the defaults and specify that
### anonymous users have read-only access to the repository, while authenticated
### users have read and write access to the repository.
# anon-access = read
auth-access = write
### The password-db option controls the location of the password
### database file. Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.
password-db = passwd
Dazu müssen die beiden rot markiertenEinträge auth-access = write und password-db = passwd aktiviert werden.
Im nächsten Schritt müssen die schreibberechtigten Benutzer angelegt werden. Dieses wird In der Datei /docker/blog-svn/neues_repository/conf/passwd vorgenommen. Es ist darauf zu achten, dass die Passworte in dieser Datei im Klartext eingetragen werden.
[users]
marry = marrys_secret_password
<
Auf die gleiche Art und Weise können beliebige viele weitere Repositories angelegt werden.
Nachdem das Repositoty angelegt und konfiguriert ist, kann über das svn Protokoll darauf zugegriffen werden.
Beispiel:
svn co svn://your.server.address/neues_reposority
- Details
- Geschrieben von: Michael Küper
- Kategorie: Raspberry PI
- Zugriffe: 37
Raspberry PI für Docker Container
Das Ziel dieses Projekts ist einen Raspberry PI so zu installieren, dass auf diesem verschiedene andere Server in Containern verwendet werden können.
Um dieses umzusetzen benötigen wir die folgenden Komponenten:
- RaspberryPI 4 oder 5
- Passendes Gehäuse
- Passendes Steckernetzteil
- SD-Karte oder SSD-Festplatte
Nach dem Zusammenbau wird das notwendige Image auf die SD-Karte übertragen. Hierzu eignet sich besonders das 64-BIT Image Raspberry Pi OS Lite.
- Details
- Geschrieben von: Michael Küper
- Kategorie: Raspberry PI
- Zugriffe: 68