Communardo Techblog

Neuere Apache-Versionen unterstützen sogenannte Multidomainzertifikate. Damit ist es möglich, mehrere vhost mit nur einem SSL-Zertifikat, welches der Browser als gültig akzeptiert, abzusichern. Um jedoch ein Zertifikat von einer CA zu erhalten, müssen wir ein CSR (Certificate Signing Request) erzeugen. Mit openssl ist diese Aufgabe schnell erledigt. Wie kann man hier aber mehrere Domains angeben? Ein möglicher Weg kann die Erstellung eines CSRs mit mehreren CommonNames sein. Dazu editieren wir /etc/ssl/openssl.cnf. In der Sektion [ req_distinguished_name ] ändern wir den Eintrag:

commonName = Common Name (eg, YOUR name)
commonName_max = 64

in:

0.commonName = Common Name 1 (eg, YOUR name)
0.commonName_max = 64

1.commonName = Common Name 2 (eg, YOUR name)
1.commonName_max = 64
.
.
.
um. Mit einem 0.commonName_default=www.domain.tld kann man auch gleich einen passsenden Standardwert einstellen. Zum Schluß generieren wir uns den Schlüssel mit 2048 bits und den CSR:

openssl req -new -nodes -keyout dateiname.key -out dateiname.csr -newkey rsa:2048

Weitere mögliche Wege gehen über “subjectAltName” oder über “commonName” und “subjectAltName”.

In einigen wenigen Fällen ist erwünscht oder sogar erforderlich, dass man sich auf eine fremde Maschine per ssh ohne Passwortabfrage einloggt. Denkbare Anwendungsfälle sind der Einsatz in Shellskripten oder wie hier näher erläutert, der Aufbau eines Tunnels über ssh, um z.B. ein ungeschütztes Protokoll über das Internet von einer entfernten Maschine auf eine lokale Maschine zu Verfügung zu stellen. Beispielhaft werde ich in den beiden Teilen schildern, wie man PostgreSQL von einer gehosteten Maschine ins lokale Netzwerk bekommt.

In einem ersten Schritt generieren wir uns einen passenden Schlüssel mit dem Kommando ssh-keygen. Wir haben die Auswahl unter RSA-Schlüsseln mit einer Länge von 768 bis 2048 bits und einem DSA-Schlüssel mit genau 1024 bits. Bei RSA-Schlüsseln wird eine Länge von 2048 bits als ausreichend sicher angenommen.

ssh-keygen -t rsa -b 2048

ssh-keygen -t dsa

Die Frage nach dem Speicherort kann man in den meisten Fällen bestätigen, im Normalfall unter ~/.ssh/id_dsa oder id_rsa. Braucht man mehr als einen Standardschlüssel, gibt man einfach einen anderen Namen ein. Die Frage nach einem Passwort und dessen Wiederholung lassen wir leer. Nun müssen wir den öffentlichen Teil des Schlüssels auf den Remothost installieren. Auch hier bringt Linux gleich die passenden Tools mit:

ssh-copy-id -i ~/.ssh/id_dsa.pub user@remotehost

Werden mehere Schlüssel für unterschiedliche Accounts/Maschinen gebraucht, ergänzt man die ~/.ssh/config um folgende Einträge:

Host remotehost
Port 22
IdentityFile ~/.ssh/<key>

Da ich ein Login mit einem ungesicherten Key aus Sicherheitsbedenken ablehnen muss, zeige ich einen eher unbachteten Weg, den so gewonnen Zugang soweit einzuschränken, dass nur die Ausführung eines Kommandos erlaubt wird. Man ergänzt auf dem Remotehost im Homeverzeichnis des users die .ssh/authorized_keys die neu erstellte Zeile, die je nach Art des erstellten Schlüssels mit ssh-rsa für einen RSA-Key bzw. mit ssh-dss für einen DSA-Key beginnt um z.B. den Eintrag:

command="/usr/bin/sleep 1800", ssh-dss ...

Jetzt darf der Besitzer des Schlüssel nur noch /usr/bin/sleep 1800 auf dem Remotehost ausführen. Für unsere Zwecke des Tunnelbaus ideale Voraussetzungen…

Betreibt man einen Apache als Reverse Proxy, so hat man im Allgemeinen das Problem, dass alle
Zugriffe auf dem Backend-Apache als Zugriffe des Frontends geloggt werden. Damit ist es
praktisch unmöglich eine vernünftige Statistik zu erstellen.
Abhilfe schafft hier das rpaf-Modul (reverse proxy add forward). Dieses Modul kann die für andere
Apache-Module sichtbare Remoteadresse ändern. Installiert wird das Modul auf dem Backend. Die
Konfiguration gestaltet sich sehr einfach:

LoadModule rpaf_module mod_rpaf.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.2

Zuerst wird das Modul geladen und eingeschalten.Mit RPAFsethostname werden die selben
Hostnamen wie auf dem Frontend verwendet. Zum Schluß werden die Frontends definiert. Der
Vollständigkeithalber die letzte Direktive:

RPAFheader X-Forwarded-For #wählt Header X-Forwarded-For oder X-Real-IP

Betreibt man in einem Netzwerk ein Active Directory und Subversion (HTTP basierend), bietet es
sich an, das AD für eine Rechtevergabe für das SVN zu verwenden. Mit dem Umweg über ADISS
(Active Directory Interface for Subversion Security) ist dies auch problemlos möglich.
Vorausetzungen sind ein Apache, php (ldap,mysql), mySQL und ein (lesender) Zugriff auf das AD.
Folgt man den Anweisungen in der INSTALL.txt, so ist man in wenigen Minuten am Ziel und
automatisiert so die Verwaltung der Zugriffsrechte auf das Subversion über die
Gruppenzugehörigkeit im AD. Zu finden ist Adiss auf Sourceforge