SSH keys nachträglich mit einem Passwort schützen

Hat man sich einmal an die Vorteile von public key Authentifizierung bei einem System gewöhnt, stellt man meist zügig alle anderen Systeme ebenfalls auf diese Art der Authentifizierung um. Möchte man sich von verschiedenen Systemen aus anmelden, muss der eigene private Key auf diese kopiert oder z.B. per USB-Stick mit sich geführt werden. Kommt dieser allerdings in falsche Hände, muss man einen neuen Schlüssel generieren und erneut an alle Systeme verteilen. Zum Schutz des privaten Keys, ist es möglich, diesen mit einem Passwort (besser: Passphrase) zu schützen. Dieses wird benötigt um den Key “freizuschalten”, die eigentliche Anmeldung am entfernten System läuft weiterhin über das public key Verfahren und benötigt kein Passwort.  Für eine einfachere Unterscheidung wird das Kennwort zur Freischaltung deshalb auch als “Passphrase” und nich als Passwort bezeichnet. Sollte man den privaten Schlüssel bei der Erstellung nicht mit einer Passphrase versehen haben, kann man dies noch nachträglich mit ssh-keygen tun.

[pat@earth ~]$ ssh-keygen -p
Enter file in which the key is (/home/pat/.ssh/id_rsa):  [Enter]
Key has comment ‘/home/pat/.ssh/id_rsa’
Enter new passphrase (empty for no passphrase):  newSuperSavePassword
Enter same passphrase again:  newSuperSavePassword
Your identification has been saved with the new passphrase.

Quellen:

http://kimmo.suominen.com/docs/ssh/#passwd

http://www.manpagez.com/man/1/ssh-keygen/

VPN einrichten mit pptpclient / pptp-linux

Für den Netzzugang über ein virtuelles privates Netz (VPN) gibt es sicherlich eine ganze Menge guter Gründe, einer davon ist z.B. die Überwindung der geobasierten Sperrung von Webseiten à la Youtube (“Dieses Video ist in deinem Land nicht verfügbar”). Auf Amerika beschränkte Angebote wie der Streaming Dienst Hulu sind damit in Deutschland nutzbar. Der Anbieter VPN on Demand befindet sich seit einiger Zeit in der Betaphase und ermöglicht einen kostenlosen VPN Zugang. Dazu einfach eine E-Mail mit dem Betreff “vpnod” an promotion@vpnod.com schicken und kurze Zeit später gibt es die Zugangsdaten per E-Mail.

Als erstes muss der PPTP-Client installiert werden. Unter Arch Linux mittels

[pat@earth ~]$ sudo pacman -S pptpclient

unter Debian und Ubuntu heißt das Paket pptp-linux und wird mittels

[pat@earth ~]$ sudo aptitude install pptp-linux

installiert. Nach der Installation konfigurieren wir eine neue VPN Verbindung, hier im Beispiel von VPN on Demand. Dazu legen wir im Verzeichnis /etc/ppp/peers eine Datei für die neue VPN-Verbindung an und tragen folgendes ein: (Die im folgenden verwendeten Variablen $BENUTZER und $PASSWORT sind natürlich mit den erhaltenen Zugangsdaten zu ersetzen)

[pat@earth ~]$ sudo vim /etc/ppp/peers/vpnod

pty “pptp vpn.vpnod.com –nolaunchpppd”
name $USER
linkname vpnod
remotename vpnod
ipparam vpnod
usepeerdns
require-mppe-128
file /etc/ppp/options.pptp

In der Datei chap-secrets werden nun die Zugangsdaten definiert.

[pat@earth ~]$ sudo vim /etc/ppp/chap-secrets

$BENUTZER vpnod $PASSWORT *

Zum testen starten wir das VPN und setzen die Schnittstelle als Standardgateway, so dass der gesamte Internetverkehr über das VPN läuft. Am besten vorher und nachher diese Seite zur Überprüfung der eigenen IP besuchen. Hinweis: Ab diesem Zeitpunkt wird jeglicher Traffic über das VPN geroutet, d.h. auch E-Mails, Instant Messenger oder andere Anwendungen die auf dem System laufen. Die Daten sind zwar bis zur VPN Gegenstelle verschlüsselt, ab dort ist es allerdings Aufgabe des Anwenders für die Verschlüsselung zu sorgen. Wer dem VPN Anbieter nicht traut (oder leicht zu Paranoia neigt :) ) sollte hier die selben Sicherheitsvorkehrungen wie bei der Nutzung eines öffentlichen WLAN Hotspots, sprich HTTPS/SSL, vornehmen.

[pat@earth ~]$ sudo pon vpnod
[pat@earth ~]$ sudo route add default dev ppp0

Sollte der Verbindungsaufbau scheitern, kann der Aufruf von pon mittels

[pat@earth ~]$ sudo pon vpnod debug dump logfd 2 nodetach

bei der Fehlersuche hilfreich sein.

Zum Abbau der Verbindung, die Route wieder entfernen (sollte poff automatisch machen) und die Verbindung trennen.

[pat@earth ~]$ sudo route del default
[pat@earth ~]$ sudo poff

Klappt alles ohne Probleme, kann man das ganze nun automatisieren. Alle Scripte (*.sh) im Ordner /etc/ppp/if-up.d/ werden automatisch nach dem Aufbau der VPN Verbindung ausgeführt. Da Rounting eine komplexe Sache und ein Post für sich wäre, hier nur beispielhalt ein Script zum routen des gesammten Traffics über das VPN.

pat@earth ~]$ sudo vim /etc/ppp/ip-up.d/10-route.sh

#!/bin/bash

# Interface (eth0 or wlan0 in most cases)
INTERFACE=eth0

# Interface as provided by calling pppd
VPN=$1
#VPN=ppp0

route del default ${INTERFACE}
route add default dev ${VPN}

Und erstellen ein weiteres Script, welches nach dem Abbau der VPN Verbindung wieder die richtige Route einträgt.

[pat@earth ~]$ sudo vim /etc/ppp/ip-down.d/10-route.sh
#!/bin/bash

# Interface (eth0 or wlan0 in most cases)
INTERFACE=eth0

# Interface as provided by calling pppd
VPN=$1

# Gateway (use ‘route’ to find out, IP or name)
GATEWAY=192.168.2.1

route del default ${VPN}
route add default gw ${GATEWAY} ${INTERFACE}

Ist der Hostname oder die IP des Gateways nicht bekannt, hilft das Kommando route.

[pat@earth ip-up.d]$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 202 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 202 0 0 eth0

Eine Möglichkeit das Ganze nun automatisch beim Systemstart zu machen, findet man für Arch Linux z.B. hier.

Quellen: http://pptpclient.sourceforge.net