XMPP Server per DNS auf der Hauptdomain betreiben

Wenn man einen XMPP-Server unter einer Subdomain wie „xmpp.example.org“ betreibt, so sehen die Kontakte dementsprechend aus – in diesem Fall „“. Möchte man Kontakte nach dem Schema „“ anlegen, so muss der DNS Eintrag der Hauptdomain auf den XMPP-Server zeigen. Dies ist aber nicht immer möglich. So kann es vorkommen das der Webserver auf der Hauptdomain seinen Dienst verichtet, während der XMPP-Server auf einem anderen Server läuft. In einem solchen Fall kann man sich das ganze mit „SRV“ Einträgen im DNS zurechtzubiegen.

_jabber._tcp             IN SRV     0 0 5269 xmpp.example.org.
_xmpp-client._tcp        IN SRV     0 0 5222 xmpp.example.org.
_xmpp-server._tcp        IN SRV     0 0 5269 xmpp.example.org.

Mit diesen Einträgen ist es dann möglich den XMPP Server unter „example.org“ zu betreiben, obwohl der A-Record auf einen anderen Server zeigt, da der anfragende Client umgeleitet wird.

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

Debugger da?

Unter .NET ist es manchmal sehr nützlich zu wissen, ob an die Anwendung ein Debugger angehängt ist. Im Namespace „System.Diagnostics“ gibt es dazu auch die passende statische Eigenschaft mit dem Namen „IsAttached“. Die Nutzung könnte dabei so aussehen:

if(Debugger.IsAttached==true)
{
    //Do something
}

Der Quelltext in den Blockklammern wird dabei nur dann ausgeführt, wenn ein Debugger an die Anwendung angehangen ist. Das kann die IDE (Visual Studio und Co.) sein, es kann aber auch ein böswilliger Angreifer sein – wobei es natürlich Verfahren gibt, die Erkennung auszuhebeln.

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.