XMPP Server unter Ubuntu aufsetzen

Möchte man Instant Messaging mittels XMPP (früher unter dem Namen Jabber bekannt) nutzen, so kann man natürlich zu einem der vielen Dienste wie GMail, GMX und ähnliches gehen. Damit bekommt man dann neben den Vorteilen auch den Nachteil, das man sich nicht sicher sein kann was mit den eigenen Daten passiert. Eine andere Lösung ist es hier den XMPP Server selbst aufzusetzen. Dazu bietet sich „ejabberd“ an. Mittels:

sudo apt-get install ejabberd

wird das passende Paket installiert. Der Server „ejabberd“ unterstützt dabei die Verwaltung mehrerer Domains, so das eine Serverinstanz die Adressen und bereitstellen kann. Um dies umzusetzen, geht es im ersten Schritt an die Konfiguration. Dazu wird die Datei „/etc/ejabberd/ejabberd.cfg“ mittels „nano“ geöffnet:

nano /etc/ejabberd/ejabberd.cfg

Die Syntax der Datei ist dabei im Gegensatz zu anderen Konfigurationsdateien etwas gewöhnungsbedürftig, da sie auf der Programmiersprache Erlang basiert. Kommentare z.B. werden in dieser Datei mit einem Prozentzeichen eingeleitet. Im ersten Schritt werden die Domain respektive Hostnamen definiert, welche „ejabberd“ verwalten soll. Dazu wird der Punkt „hosts“ gesucht und mit den entsprechenden Domains gefüllt.

{hosts, ["xmpp.example.com", "xmpp.example.org"]}.

Die Serversprache kann man für einen deutschsprachigen Server geändert werden:

{language, "de"}.

Damit werden Nachrichten vom Server in Deutsch anstatt in Englisch ausgegeben. Standardmäßig ist der Server so eingestellt, das niemand außer dem Administrator Nutzer anlegen kann. Natürlich wäre es auch denkbar, einen Server zu betreiben, bei welchem sich jeder registrieren kann. Damit man Nutzer anlegen kann, muss ein Nutzer mit den entsprechenden Rechten definiert werden:

{acl, admin, {user, "seeseekey", "xmpp.example.com"}}.

Damit ist der Nutzer „“ ein Nutzer mit administrativen Rechten. Allerdings muss dieser Nutzer noch erstellt werden:

service ejabberd restart
ejabberdctl register seeseekey xmpp.example.com geheimespasswort

Weitere Nutzer können anschließend über die Weboberfläche angelegt werden. Zu erreichen ist diese dabei unter:

http://xmpp.example.com:5280/admin

Die Zugangsdaten entsprechen dabei denen des administrativen Nutzers.

Weitere Informationen gibt es unter:
https://wiki.archlinux.de/title/Ejabberd

Probleme mit dem SSH Zugang per Schlüssel

Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:

ssh-copy-id -i ~/.ssh/id_rsa.pub

Anschließend kann man sich mittels:

ssh

ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:

ssh -v

Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:

chmod 700 /home/seeseekey/.ssh/
chmod 600 /home/seeseekey/.ssh/authorized_keys

Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:

Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey

In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:

chmod 700 /home/seeseekey/

wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.

OpenVPN auf einem Ubuntu Server aufsetzen

Wenn man sich einem unsicheren Netz bewegt, z.B. in einem freien WLAN empfielt es sich ein VPN zu nutzen. Dafür gibt es die unterschiedlichsten VPN-Dienste, welche dies gegen einen monatlichen Obolus anbieten. Besitzt man einen eigenen Server, so kann man sich mittels OpenVPN einen solchen Dienst selber aufsetzen. Im ersten Schritt wird OpenVPN installiert:

apt-get install openvpn

Aus den Beispieldateien wird das Skript „easy-rsa2“ zum Erstellen der Zertifikate an den entsprechenden Ort kopiert:

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa2

Für die Erzeugung der Zertifikate müssen einige Parameter angepasst werden. Dazu wird die entsprechende Datei im Editor geöffnet:

cd /etc/openvpn/easy-rsa2
nano vars

Der Wert Keysize „KEY_SIZE“ wird von 1024 auf 2048 erhöht. Am Ende der Datei befinden sich dann folgende Einträge:

export KEY_COUNTRY="US"
export KEY_PROVINCE="CA"
export KEY_CITY="SanFrancisco"
export KEY_ORG="Fort-Funston"
export KEY_EMAIL=""
export KEY_CN=changeme
export KEY_NAME=changeme
export KEY_OU=changeme
export PKCS11_MODULE_PATH=changeme
export PKCS11_PIN=1234

Nach der Konfiguration sollte das ganze dann in etwa so aussehen:

export KEY_COUNTRY="DE"
export KEY_PROVINCE="MV"
export KEY_CITY="Neubrandenburg"
export KEY_ORG="Example Inc."
export KEY_EMAIL=""
export KEY_CN="vpn.example.org"
export KEY_NAME="Example VPN"
export KEY_OU="VPN"
#export PKCS11_MODULE_PATH=changeme
#export PKCS11_PIN=1234

Die „vars“-Datei wird den Umgebungsvariablen hinzugefügt und anschließend das Masterzertifikat erstellt:

source ./vars
mkdir /etc/openvpn/easy-rsa2/keys
sudo -E ./clean-all
sudo -E ./build-ca

Damit ist die Certificaty Authority (CA) erstellt. Nun geht es an die Erstellung der Schlüssel für den Server:

sudo -E ./build-key-server server

Beim Common Name, gibt man die Domain ein unter welcher der VPN Server später erreichbar sein soll (z.B. vpn.example.org). Nach der Erstellung wird man im „keys“ Verzeichnis die Dateien „server.crt“, „server.csr“ und „server.key“ finden. Für den Diffie-Hellman Schlüsselaustausch müssen entsprechende Paramater erzeugt werden:

sudo -E ./build-dh

Nun fehlen nur noch die Zertifikate für die entsprechenden Nutzer. Ein Nutzer wird dabei mittels:

sudo -E ./build-key nutzerOderClientName

erstellt. Damit sind alle benötigten Zertifikate und Schlüssel erstellt, so das nun die restliche Konfiguration des Servers vorgenommen werden kann. Als Basis wird dabei die mitgelieferte Beispieldatei genutzt:

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gunzip /etc/openvpn/server.conf.gz

Nach dem Kopiervorgang wird die Datei „/etc/openvpn/server.conf“ mittels „nano“ geöffnet. Folgende Einstellungen werden dabei angepasst werden:

ca ca.crt -> ca ./easy-rsa2/keys/ca.crt
cert server.crt -> cert ./easy-rsa2/keys/server.crt
key server.key -> key ./easy-rsa2/keys/server.key 

dh 1024.pem -> dh ./easy-rsa2/keys/dh2048.pem

;user nobody -> user nobody
;group nogroup -> group nogroup

;push "redirect-gateway def1 bypass-dhcp" -> push "redirect-gateway def1 bypass-dhcp"

Damit jegliche Kommunikaton vom Client über den Server läuft, muss die Datei „/etc/rc.local“ auf dem Server um einige Einträge ergänzt werden:

iptables -t nat -F POSTROUTING
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source IP_DES_SERVERS

Nun ist der Server konfiguriert und kann mittels:

reboot

neugestartet werden.

Weitere Informationen gibt es unter:
http://wiki.ubuntuusers.de/OpenVPN
https://de.wikipedia.org/wiki/OpenVPN

sendmail unter Ubuntu entfernen

Den MTA „sendmail“ über den Paketmanager zu installieren ist eine Sache von Sekunden:

apt-get install sendmail

Interessanter wird dann wenn man versucht „sendmail“ wieder zu entfernen. Der Logik folgend sollte ein einfaches:

service sendmail stop
apt-get remove sendmail

funktionieren. Allerdings läuft der MTA auch danach noch weiter. Abhilfe schafft hier die Deinstallation eines zweiten Paketes, so das der komplette Befehl so aussehen sollte:

service sendmail stop
apt-get remove sendmail sendmail-bin

Möchte man die Konfigurationsdateien auch entfernen, so bietet sich anstatt eines „remove“ ein „purge“ an:

service sendmail stop
apt-get purge sendmail sendmail-bin

Danach hat der MTA das zeitliche gesegnet und man verfügt wieder über eine Installation ohne „sendmail“.

Upload Limit für PHP-FPM in Verbindung mit Nginx erhöhen

Standardmäßig liegt das Uploadlimit für Dateien einer Nginx Installation mit der entsprechenden PHP-Installation bei 2 MiB. Damit stößt man natürlich bei vielen Anwendungen sehr schnell an die Grenze, so z.B. beim Upload von größeren Bildern. Möchte man dies ändern, müssen sowohl die Nginx-Konfiguration als auch die PHP-Konfiguration angepasst werden. Im ersten Schritt wird die Nginx-Konfuration bearbeitet:

nano /etc/nginx/nginx.conf

Dort wird im „http“-Block die Zeile:

client_max_body_size 1024m;

hinzugefügt. Unter Umständen muss hier auch die „client_body_timeout“-Option mit einem höheren Timeout versehen werden. Dies sollte man allerdings durch eigene Tests herausfinden. Nachdem Nginx konfiguriert ist, geht es an die „php.ini“-Datei:

nano /etc/php5/fpm/php.ini

Dort müssen folgende Parameter gesetzt werden:

post_max_size = 1024M
upload_max_filesize = 1024M

Nachdem das erledigt ist, können Nginx und der PHP Service neugestartet werden:

service nginx restart
service php5-fpm restart

Anschließend verfügt man in diesem Fall über ein neues Upload Limit von 1024 MiB.