Für die Authentifikation per SSH kann man ein Schlüsselpaar mit oder ohne Passwort verwenden. Ein solches Schlüsselpaar erzeugt man mit

ssh-keygen -t rsa -b 4096 -C "me@example.com" -f ~/.ssh/id_rsa-new

Der Parameter -f ist optional und spezifiziert nur den Namen der Datei der den privaten Schlüssel enthält. Der öffentliche Schlüssel bekommt den gleichen Namen mit der zusätzlichen Dateiendung .pub.

Führt man das Kommando aus erhält man eine Ausgabe wie die folgende

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/myuser/.ssh/id_rsa-new.
Your public key has been saved in /home/myuser/.ssh/id_rsa-new.pub.
The key fingerprint is:
a6:f4:47:cf:32:67:a5:3e:44:26:cc:39:a4:22:c3:5b myser@myhost
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|          .      |
|         + o     |
|        S o.o    |
|     . . +.o..  E|
|      o + .o+. . |
|       o +o +o.  |
|        ooo+oo   |
+-----------------+

und es werden zwei Dateien erzeugt:

$ ll ~/.ssh
-rw------- 1 myuser myuser 1,7K Mär 23 12:03 id_rsa-new
-rw-r--r-- 1 myuser myuser  402 Mär 23 12:03 id_rsa-new.pub

Der private Schlüssel id_rsa-new ist der Schlüssel mit dem man Zugriff auf einen Server erhalten kann und muss geheim gehalten werden. Wichtig für diese Datei ist, dass die Dateiberechtigungen so gesetzt werden, dass sie nur vom Benutzer gelesen und geschrieben werden darf, da sich sonst ssh beschwert und dessen Verwendung verweigert.

chmod 0600 ~/.ssh/id_rsa-new

Der öffentliche Schlüssel kann auf den Servern hinterlegt werden, auf denen man einen Zugriff per SSH möchte.

Entfernter Server

Um jetzt auf einem anderen Server den SSH Zugang über diesen Schlüssel zu ermöglichen, kopiert man den Inhalt der Datei ~/.ssh/id_rsa-new in die Datei ~/.ssh/authorized_keys auf dem Server.

cat ~/.ssh/id_rsa-new.pub | ssh myserver.local -l myusername "cat >> ~/.ssh/authorized_keys" 

Um vorher einen alten Key zu entfernen kann man folgendes machen

echo "sed -i '\,$(head -n 1 ~/.ssh/id_rsa-old.pub),d' ~/.ssh/authorized_keys" | ssh myserver.local bash

Damit der Server einen Authentifikation per Key zulässt muss in der Datei /etc/ssh/sshd_config folgendes gesetzt sein:

PubkeyAuthentication yes

Jetzt sollte man sich mit

ssh remotehost.de -l myusername

auf dem entfernten Server remotehost.de anmelden können. Die Option -l spezifiziert den Benutzernamen mit dem man sich am Server anmelden möchte und kann weggelassen werden wenn entweder der lokale Benutzername mit dem auf dem Server übereinstimmt oder man eine entsprechende Konfiguration unter ~/.ssh/config angelegt hat.

Script zum Ändern des Public Keys

#!/bin/bash
if [ -z $1 ]
then
        echo "No server given. Exiting..."
        exit 1
fi

# Add new key
cat ~/.ssh/id_rsa.pub | ssh $1 "cat >> ~/.ssh/authorized_keys"

# Remove old key
if [ $? -eq 0 ]
then
        echo "sed -i '\,$(head -n 1 ~/.ssh/id_rsa-old.pub),d' ~/.ssh/authorized_keys" | ssh $1 bash
else
        echo "Unable to add new key to ~/.ssh/authorized_keys on $1. Aborting..."
fi

# Show file ssh $1 "cat ~/.ssh/authorized_keys"

Das Script gibt am Schluss die Datei ~/.ssh/authorized_keys auf dem Zielserver zur Kotrolle aus.

Aus Platzgründen musste ich heute ein Unterordner auf einem meiner Samba-Shares auf eine andere Festplatte verlinken. Leider musste ich feststellen, dass Samba keine Links zulässt, die auf ein Ziel außerhalb des Shares zeigen.

Da der Mountpoint der Platte jedoch außerhalb liegen muss, da hier noch andere Dinge drauf sind musste ich Samba beibringen den Links doch bitte zu folgen. Und Linux wäre nicht Linux wenn es dafür nicht auch ein Schalterchen gäbe.

Um Samba zu erlauben Symlinks zu folgen, die nicht auf ein Ziel innerhalb des Shares zeigen muss folgendes in die [global] Sektion.

follow symlinks = yes
wide links = yes

Da man ja inzwischen Cloud-Speicher quasi hinterhergeworfen bekommt, bietet es sich an diesen z.B. als Backup-Speicher für seine Daten zu verwenden um diese ggf. vor Elementarschäden wie Feuer, Wasser, usw. zu schützen.

Das Problem ist dass man bei Cloud-Speichern natürlich nie weiß wer alles Zugriff auf die Daten hat. Bleibt also nur noch die Möglichkeit die Daten zu verschlüsseln.

Ein verschlüsseltes Dateisystem in einer Container-Datei, wie  man es z.B. mit cryptsetup erzeugen kann ist wenig praktikabel, da bei einer Änderung an einer Datei im verschüsselten Dateisystem die gesamte Container-Datei hochgeladen werden müsste. Bei mehreren GB Daten ist dieser Ansatz keine gute Idee.

Eine Lösung des Problems ist z.B. EncFS (encryption FileSystem). Laut ubuntuusers.de besteht allerdings eine potentielle Schwachstelle. Diese ist für meine Zwecke allerdings ein vertretbares Risiko.

Installation

Die Installation erfolgt mit

sudo apt-get install encfs

Als nächstes müssen die Benutzer, die encfs verwenden können sollen in die Benutzergruppe fuse aufgenommen werden:

sudo usermod -aG fuse BENUTZERNAME

Konfiguration

Als nächstes legen wir zwei Verzeichnisse an. Das erste Verzeichnis enthält die verschüsselten Daten auf dem Cloud Speicher und das andere dient als Mount-Point für das entschlüsselte Dateisystem auf dem wir arbeiten können.

mkdir -p /media/cloud/1und1/webdav/Backup /media/cloud/1und1/encfs

Im Verzeichnis /media/cloud/1und1/webdav ist in diesem Beispiel unser 1und1-Onlinespeicher gemounted. Es geht aber auch jeder andere wie z.B. Dropbox, Google Drive, etc.

Diese beiden Verzeichnisse verbinden wir jetzt mit encfs.

encfs /media/cloud/1und1/webdav/Backup /media/cloud/1und1/encfs

Dabei ist das erste Verzeichnis das Verzeichnis mit dem wir arbeiten können. Dieses ist an sich nur ein Mountpoint in den das zweite Verzeichnis, in dem die verschlüsselten Daten gespeichert werden sollen, eingehängt wird.

Als nächstes wird man gefragt, welchen Modus man benutzen möchte:

Neuer verschlüsselter Datenträger wird erstellt.
Bitte wählen Sie eine der folgenden Optionen:
 "x" für den Expertenmodus,
 "p" für den vorkonfigurierten Paranoia-Modus,
 etwas anderes oder eine Leerzeile wählt den Standard-Modus.
?>

Normalerweise kann man hier p für den vorkonfigurierten Paranoia-Modus wählen. Hat man als Cloud-Speicher z.B. 1und1 und damit eine Begrenzung der Länge der Pfadnamen auf z.B. 250 Zeichen, kann das schnell eng werden. Ist das der Fall muss man mit x den Expertenmodus verwenden.

Es werden im Folgenden die gewünschten Parameter abgefragt:

Manuelle Konfiguration gewählt.
Die folgenden Verschlüsselungsalgorithmen sind verfügbar
1. AES : 16 byte block cipher
 unterstützte Schlüssellänge zwischen 128 und 256 Bits
 unterstützte Blockgröße zwischen 64 und 4096 Bits
2. Blowfish : 8-Byte-Blockchiffre
 unterstützte Schlüssellänge zwischen 128 und 256 Bits
 unterstützte Blockgröße zwischen 64 und 4096 Bits

Hier wählt man z.B. 1 für AES.

Bitte wählen Sie eine Schlüssellänge in Bit. Die von Ihnen gewählte Verschlüsselung
unterstützt Längen von 128 bis 256 Bit in 64 Bit Schritten.
Zum Beispiel: 
128, 192, 256

Hier kann man je nach Sicherheitsempfinden und verfügbarer Rechenleistung die Schlüssellänge wählen. Es gilt um so höher um so sicherer. Beispielweise also 256.

Wählen Sie eine Blockgröße (in Byte) aus. Der ausgewählte Algorithmus
unterstützt Größen von 64 bis 4096 Byte in Schritten von je 16 Byte.
Oder drücken Sie Enter, um die Vorgabe (1024 Byte) zu übernehmen

Damit kann man festlegen wie viele Bytes encfs auf einmal verarbeitet. Ein höherer Wert veringert den Overhead der beim Verschlüsseln entsteht, führt aber auch dazu dass zum Lesen eines Teilbereiches einer Datei mehr Daten entschlüsselt werden müssen. Ein Mittelwert ist hier also nicht verkehrt. Z.B. der Standardwert 1024.

 Die folgenden Verschlüsselungsalgorithmen für Dateinamen stehen zur Verfügung:
1. Block : Blockverschlüsselung, versteckt die Dateinamengröße etwas
2. Null : No encryption of filenames
3. Stream : Stromchiffre, möglichst kurze Dateinamen

Hier wird es jetzt interessant. Wir wählen hier 3 für möglichst kurze Dateinamen.
Mit 2 könnten wir die Verschlüsselung der Dateinamen auch ganz deaktivieren wenn man so etwas möchte. Wir wählen also 3.

Enable filename initialization vector chaining?
This makes filename encoding dependent on the complete path, 
rather then encoding each path element individually.
The default here is Yes.

Dieses Feature erhöht die Sicherheit beim Verschlüsseln von Dateinamen in dem es den ganzen Pfad zum Verschlüsseln verwendet. Zwei gleiche Ordner- oder Dateinamen sehen in unterschiedlichen Pfaden somit anders aus.

Enable per-file initialization vectors?
This adds about 8 bytes per file to the storage requirements.
It should not affect performance except possibly with applications
which rely on block-aligned file io for performance.
The default here is Yes.

Dieses Feature erhöht die Sicherheit indem es zu einer Datei Zufallsdaten hinzufügt, damit zwei gleiche Dateien im verschlüsselten Zustand nicht gleich aussehen.

Enable filename to IV header chaining?
This makes file data encoding dependent on the complete file path.
If a file is renamed, it will not decode sucessfully unless it
was renamed by encfs with the proper key.
If this option is enabled, then hard links will not be supported
in the filesystem.
The default here is No.

Ist dieses Feature aktiv, kann man keine Hardlinks mehr verwenden, eine Datei lässt sich aber auch nicht mehr entschlüsseln, wenn sie ausserhalb des encfs umbenannt wurde. Die Daten innerhalb der Datei sind damit an dessen Pfad gebunden.

Enable block authentication code headers
on every block in a file?  This adds about 12 bytes per block
to the storage requirements for a file, and significantly affects
performance but it also means [almost] any modifications or errors
within a block will be caught and will cause a read error.
The default here is No.

Dieses Feature beeinflusst die Performance negativ, dafür wird jeder Block in jeder Datei mit einer kryptografischen Prüfsumme versehen und es ist damit praktisch unmöglich eine Datei zu manipulieren ohne dass die Änderung auffällt. Ist genug Rechenleistung vorhanden, kann man hier yes auswählen.

Sollen jedem Block-Vorspann Zufallsbytes hinzugefügt werden?
Das wird die Leistung veringern, aber sicherstellen, dass die
Blöcke unterschiedliche Sicherheitscodes verwenden. Sie können das selbe
Resultat mit geringeren Leistungseinbußen erzielen, indem Sie die dateispezifischen Initialisierungsvektoren aktivieren.
Auswahl der Anzahl der Bytes, von 0 (Keine Zufallsbytes) bis 8:

Da wird vorher die dateispezifischen Initialisierungsvektoren aktiviert haben ist das hier nicht mehr nötig.

Enable file-hole pass-through?
This avoids writing encrypted blocks when file holes are created.
The default here is Yes.

Bin mir nicht sicher. verhindert möglicherweise das Schreiben leerer Blöcke in Dateien. Aktivieren macht denke ich Sinn.

Zum Abschluss erfolgt eine Zusammenfassung der Konfiguration:

Konfiguration abgeschlossen. Das angelegte Dateisystem hat die
folgenden Eigenschaften:
Dateisystem Chiffre: "ssl/aes", Version 3:0:2
Dateinamenskodierung: "nameio/stream", Version 2:1:2
Schlüssellänge: 256 Bits
Blockgröße: 1024 Byte, enthält 8 Byte MAC-Kopf
Jede Datei enthält acht Byte Vorspann mit einmaligen IV Daten.
Dateinamensverschlüsselung benutzt IV Verkettungsmodus.
File holes passed through to ciphertext.

Als letztes wird das Kennwort verlangt:

Nun wird ein Kennwort für das Dateisystem benötigt.
Da es keinen Mechanismus zur Wiederhestellung gibt, müssen Sie
sich an das Kennwort erinnern! Das Kennwort kann mit encfsctl
nächträglich geändert werden.

Damit ist die Einrichtung abgeschlossen und jetzt wird jede Datei, die wir in /media/cloud/1und1/encfs anlegen verschlüsselt in die Cloud hochgeladen.

Um das Verzeichnis wieder auszuhängen gibt man folgendes ein:

fusermount -u /media/cloud/1und1/encfs

Um das Verzeichnis wieder einzuhängen gibt man erneut

encfs /media/cloud/1und1/webdav/Backup /media/cloud/1und1/encfs

ein. Nach Eingabe des Passworts wird das verschlüsselte Dateisystem unter /media/cloud/1und1/webdav/Backup eingehängt.

Möchte man z.B. für Scripts das Passwort automatisch übergeben, verwendet man folgenden Befehl:

echo "mypassword" | encfs --stdinpass /media/cloud/1und1/webdav/Backup /media/cloud/1und1/encfs