gmake && gmake install

Als nächstes werden auf allen Datenbanken, inklusive dem Template (so spart man sich das fehlerträchtige nachträgliche Installieren), die Unterstützungstabellen als PostgreSQL-Superuser installiert:

psql -d db -f /usr/share/postgresql/contrib/pgsnmpd.sql

Da auf meiner Maschine bereits ein SNMPd seinen Dienst tut, starte ich den pgsnmpd als Subagent. Dazu wird in der snmpd.conf der folgende Eintrag aktiviert:

master agentx

Startet danach der SNMP-Daemon nicht mehr, so muß in eventuell unter /var ein Verzeichnis agentx für den Socket angelegt werden. Danach kann man den pgsnmpd als Subagent starten:

/usr/bin/pgsnmpd -b -s -C"user=postgres host=localhost"

Bei mir fehlten allerdings noch die (aktuelle) RDBMS-MIB, APPLICATION-MIB, SYSAPPL-MIB und die NETWORK-SERVICES-MIB. Diese kann man sich aber schnell aus dem Internet besorgen.
Eine Verbindung zum RDBMS muss als PostgreSQL-Superuser erfolgen. Ist die Verbindung von Superuser auf localhost mit einem Passwort geschützt, wie sich das gehört, hilft eine .pgpass mit dem Inhalt

hostname:port:database:username:password

im Homeverzeichnis weiter. Erhält man dann vielleicht in den Logs noch ein:

registering pdu failed

sollte man in der Prozesstabelle schauen, ob der pgsnmpd bereits gestartet war. Zum Schluß binden wir den den pgsnmpd noch in die init-Skripte ein, um ein Hochfahren des Dienstes beim Reboot zu garantieren. Ich habe die /etc/init.d/local (Gentoo) dafür gewählt.

ssh -f -L 2222:remotehost:5432 -c blowfish user@remotehost /usr/bin/sleep 1800

Mit der Option -f wird ssh in den Hintergrund vor der Ausführund des Kommandos /usr/bin/sleep geschickt. Mit -L localport:remotehost:remotehostport wird ein Tunnel von dem PostgreSQL-Standardport 5432 auf remotehost zum Port 2222 auf localhost gebaut. Jetzt noch die Zugriffsrechte der Datenbank für localhost auf dem remotehost aktualisiert und wir können den ersten Test durchführen:

psql -U benutzer -d db -h localhost -p 2222

Wird diese Verbindung dauerhaft benötigt bietet es sich eine Automatisierung über cron an. Dazu habe ich folgendes Skript erstellt:

#!/bin/sh
PORT=`lsof -i | grep localhost:2222 | head -1 | cut -d" " -f1`
SSH=`which ssh`
if [ "${PORT}"x == "x" ]; then
$SSH -f -L 2222:remotehost:5432 -c blowfish user@remothost /bin/sleep 1800
fi

Diese prüft ab, ob der definierte Port offen ist, und startet die Verbindung einfach neu, wenn dies nicht der Fall ist.

emerge -av rkhunter chkrootkit

Die effektivste Art, diese Tools zu nutzen, ist es, diese über cron ausführen zu lassen. Dazu wird unter Gentoo der Parameter ENABLE unter /etc/cron.daily/rkhunter von NO auf YES gesetzt. Die Variable UPDATE ebenfall auf YES zu setzen ist sinnvoll. Zum Aktivieren von chkrootkit wird in der /etc/cron.weekly/chkrootkit das Kommentarzeichen vor der einzelnen Kommandozeile entfernt.
Auch wenn diese Tools sinnvoll im Kampf gegen Eindringlinge sind, einen 100%-igen Schutz können sie nicht garantieren.

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 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…

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