Michael Küpers Blog
Mein Blog zu Themen rund um Linux, RaspberryPI und IT im Allgemeinen.
  • Home
  • RaspberryPI
  • Allgemeines
  • ---
  • Impressum
  • Datenschutzerklärung
  • Beitrag melden

Raspberry PI

Artikel zum Thema rund um den Raspberry PI

Warum du heute keinen RSA-Schlüssel mehr für SSH verwenden solltest

 

🧩 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
Veröffentlicht: 10. Oktober 2025
Zugriffe: 62

Einfaches Sicherungskonzept für meinen RaspberryPi-Container-Host

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:

  1. Raspberry Pi neu flashen und Basis-Setup einrichten

  2. Konfigurationen zurückspielen

  3. 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
Veröffentlicht: 21. Januar 2025
Zugriffe: 28

Versionskontrolle auf dem RaspberryPI mit Docker und Subversion

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
Veröffentlicht: 21. Januar 2025
Zugriffe: 37
  • RaspberryPI
  • Linux
  • Subversion
  • Versionskontrolle

Pihole im Container

Was ist Pihole?

 

Details
Geschrieben von: Michael Küper
Kategorie: Raspberry PI
Veröffentlicht: 20. Januar 2025
Zugriffe: 44

Raspberry PI für Docker Container

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
Veröffentlicht: 20. Januar 2025
Zugriffe: 68

Feeds

Feed erzeugen

Beiträge

Raspberry PI

  • Warum du heute keinen RSA-Schlüssel mehr für SSH verwenden solltest
  • Einfaches Sicherungskonzept für meinen RaspberryPi-Container-Host
  • Versionskontrolle auf dem RaspberryPI mit Docker und Subversion
  • Pihole im Container
  • Raspberry PI für Docker Container

Statistiken

  • Benutzer 1
  • Beiträge 18
  • Beitragsaufrufe 1856