Für diesen Zweck gibt es ein Tool, welches die Dateien erst mehrfach mit Zufallswerten überschreibt und anschließend die Datei löscht.

shred -v -u -n 6 file.name

-v –> Gibt aus, was gerade getan wird

-u –> löscht die Datei nach dem Überschreiben

- n 6 –> Überschreibt die Datei 6mal mit Zufallswerten und nicht 10mal (Default)

file.name –> Die zu überschreibende Datei

Bei der Installation habe ich nicht so besonders darauf geachtet, welche Zeitzone meine System haben. Nach und nach nervt es aber ziemlich, dass alle Rechner eine andere Zeit verwenden. Also ist nachträglich Zeitzone und Uhrzeit einzustellen.

Zeitzone:

tzconfig

Nach diesem Kommando kann man auswählen, welche Zeitzone man gern hätte. Das Ergebnis steht in /etc/localtime
Anschließend ist noch die Zeit mit einem Zeitserver zu synchronisieren. Ich verwende dazu rdate.

apt-get install rdate

Anschließend wird die Zeit von einem öffentlichen Zeitserver geholt:

rdate ptbtime1.ptb.de

Und das war’s schon.

keywords: gnupg kmail debian bad passphrase

Da ich privat gern verschlüsselte bzw. signierte emails versenden möchte, habe ich mir das Paket gnupg installiert.

apt-get install gnupg2

Damit wurden gleichzeitig alle weiteren erforderlichen Pakete mitinstalliert.
Anschließend habe ich mir damit meine private und public keys erstellt.

gpg –gen-key

Den so erstellten Schlüssel muss man exportieren, da einem sonst keiner verschlüsselte emails senden kann. Diese Schlüssel kann man auf keyservern unterbringen, auf seiner Website, …

gpg –export –armor

Bekommt man öffentliche Schlüssel, so kann man sie mit

gpg –import

zu seinem Schlüsselbund hinzufügen.
Weiterhin sollte man dringend ein Rückrufzertifikat erstellen. Könnte ja sein, man muß seinen Schlüssel irgendwann zurückrufen!

gpg –gen-revoke

Wenn man kmail nutzt sind die Verschlüsselungsoptionen im kmail noch einzustellen.
Settings — Configure kmail — Security — Crypto Backends

Settings — Configure kmail — Identities — Modfiy

An dieser Stelle war es schonmal möglich, verschlüsselte emails zu versenden. Leider funktionierte bei mir das entschlüsseln nicht. Beim Empfang einer verschlüsselten email, wurde statt dem Inhalt der mail eine “Beschwerde” angezeigt, dass kgpg das ganze nicht entschlüsseln konnte, wegen “bad passphrase”. Und dabei wurde vorher nichtmal nach einem Passwort gefragt

Also Tante google nutzen und schon waren die erforderlichen Einstellungen gefunden.

1. Die ~/.gnupg/gpg-agent.conf sieht bei mir so aus:

pinentry-program /usr/bin/pinentry-qt
no-grab
default-cache-ttl 1800
debug-level basic
log-file socket:///home/mrre/.gnupg/log-socket

2. Ich habe eine gpg.conf erstellt:

utf8-strings
keyserver subkeys.pgp.net

3. kgpg muß automatisch beim Start von kmail gestartet werden. Und zwar aus der gleichen Konsole heraus, da sonst Variablen fehlen.
Die Reihenfolge sollte so aussehen:

1. gpg-agent –daemon
2. kgpg
3. kmail

Das kann auch automatisiert werden, indem man folgende Datei erstellt: ~/.kde/env/gpg-agent.sh
Diese muss den Inhalt haben:

eval “$(gpg-agent –daemon)”

Und mit dieser Konfiguration funktioniert es, ent- und verschlüsselte emails zu empfangen.

Wer es selber mal probieren möchte, kann mir gern eine verschlüsslte mail schicken. Kontaktdaten und public key findet man hier.

Es gibt dafür ein gutes Howto auf der openvpn-Website. Deshalb will ich nur kurz schreiben, wie ich es umgesetzt habe.

Zuerst auf dem Server openvpn installiert:

apt-get install openvpn

Im nächsten Schritt muß man die Certificate Authority und die Schlüssel für die Clients erstellen.
Die Scripte für easy-rsa im liegen nach der Installation im Verzeichnis /usr/share/doc/openvpn/examples. Damit sie nicht überschrieben werden, wenn man einen upgrade des openvpn macht, wurden sie nach /etc/openvpn/easy-rsa kopiert.

Anschließend ist die Datei ../easy-rsa/vars zu bearbeiten. Dieses Script legt nur die Variablen für die nachfolgenden Schritte an. Alle Variablen so setzen, dass sie für die eigenen Zwecke passen. Vor allem die Variablen:

KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, KEY_EMAIL

Weiterhin sind nachfolgende Variablen zu setzen:

KEY_CONFIG = openssl.cnf
KEY_DIR = Verzeichnis, in das die Keys gelegt werden
KEY_SIZE = Verschlüsselungstiefe (2048 zur Erfüllung paranoider Sicherheitswünsche)

Jetzt sind die Scripte nacheinander aufzurufen, um die Certificate Authority und die keys zu erstellen.

Der Aufruf der vars muß so erfolgen:

. ./vars

(Aufruf aus dem Verzeichnis ../easy-rsa heraus. Der “.” am Anfang stellt sicher, dass die erstellten Variablen wirklich exportiert werden!)

./clean-all –> löscht das keys - Verzeichnis und erstellt die leeren Dateien, für die Erstellung SSL-Cert erforderlich sind.

Jetzt ist es soweit, dass die einzelnen Schlüssel erstellt werden können.

./build-ca
./build-key-server server
./build-key client1
./build-key client2
./build-dh

Zu beachten ist, dass bei der Erstellung der clients-keys beim Servername der Hostname des Clients eingegeben werden muss. (@least bei mir. Sonst konnte ich mich nicht mit mehreren Clients zu gleich über vpn auf dem Server anmelden.)

Danach existieren diese Files (Tabelle hier geborgt):

Filename Needed By Purpose Secret?

ca.crt server + all clients Root CA certificate NO
ca.key key signing machine only Root CA key YES
dh{n}.pem server only Diffie Hellman parameters NO
server.crt server only Server Certificate NO
server.key server only Server Key YES
client1.crt client1 only Client1 Certificate NO
client1.key client1 only Client1 Key YES
client2.crt client2 only Client2 Certificate NO
client2.key client2 only Client2 Key YES
client3.crt client3 only Client3 Certificate NO
client3.key client3 only Client3 Key YES

Diese Files müssen jetzt, wie angegeben, auf die entsprechenden Maschinen verteilt werden. (SCP war hier die Methode der Wahl.)

Damit der Server und die Clients passend laufen, müssen noch Grundeinstellungen an den Config-Files durchgeführt werden:

Server-Seitig /usr/share/doc/openvpn/examples/sample-config-files

Dabei habe ich bei mir folgende Einstellungen geändert:

dh ../location_of_dh_file/../dh1024.pem
ca ../location_of_ca_file/../ca.crt
cert ../location_of_cert_file/../server.crt
key ../location_of_key_file/../server.key
server 10.8.0.0 255.255.255.0
user nobody
group nogroup

Damit war der Server schonmal startklar. Er kann mit openvpn server-config-file & gestartet werden. (Das ‘&’-Zeichen ist erforderlich, damit der Dienst im Hintergrund läuft.)

In den Config-Files der Clients war das gleiche Spiel erforderlich. Die Datei /usr/share/openvpn/examples/client.conf nach /etc/openvpn kopiert und ähnliche Einstellungen wie für die Serverseite durchführen (betrifft location der key-files).
Anschließend noch die ip-adresse des openvpn-servers angeben:

remote abs.dyndns.org 1211 #(Port-Angabe nach Leerzeichen)

Damit wäre auch der Client konfiguriert.

Starten mit openvpn client-config-file &

Anschließend kann man mit ifconfig überprüfen, ob ein tun-Device vorhanden ist und welche IP-Adresse es hat.

Unter Windows funktioniert die Konfiguration ähnlich. Die Beschreibung findet man ebenfalls hier. Es gab keine nennenswerten Probleme. Zu erwähnen ist, dass man openvpn auch als Dienst laufen lassen kann (Systemsteuerung –> Verwaltung –> Dienste –> openvpn (automatisch starten) )
Auf diese Weise wird der Client jedesmal beim Hochfahren von Windows gestartet. Wenn man das openvpn-log-file anschaut, dann sieht man, dass der Windows-Rechner (auch ohne Login eines Users) sofort eine ip-Adresse vom openvpn-Server bekommt. Ich vermute, dass damit sogar ein Domain-Login auf dem Samba über vpn möglich ist. Leider kann ich das nicht probieren, da meine Windows-Maschine sich sofort über das lokale Netz an der Domäne anmeldet. Wenn ich mal außerhalb mit dem Rechner unterwegs bin, werde ich das mal testen.

Abschließend ist zu erwähnen, dass alle Server, auf die man über vpn zugreifen möchte, auch entsprechend konfiguriert werden müssen. Dem nfs muß beispielsweise in der hosts.allow und in der exports erklärt werden, dass alle Rechner des Adressbereichs 10.8.0.* Zugriff bekommen sollen. Sonst kann man keine shares mounten.

Fazit: Mit openvpn kann man sich die Möglichkeit schaffen, von überall auf sein Heim-Netzwerk zuzugreifen. Es ist kein ssh-Login erforderlich. Das System verhält sich, als ob man im Heimnetz arbeitet. (Das ganze ist natürlich von der upload-Geschwindigkeit ins Internet abhängig. Bei mir ist die wie beim durchschnittlichen DSL sehr langsam, so dass eine Mindestmenge an Geduld erforderlich ist.)