Wenn man sich auf einem Ubuntu-Server einloggt, bekommt man meist folgende Zeilen zu sehen:
Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-31-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Thu Oct 3 11:23:01 CEST 2013
System load: 0.0 Processes: 95
Usage of /: 71.0% of 969.52GB Users logged in: 0
Memory usage: 1% IP address for eth0: 192.168.1.50
Swap usage: 0%
Graph this data and manage this system at https://landscape.canonical.com/
0 packages can be updated.
0 updates are security updates.
Last login: Sat Sep 28 15:26:35 2013 from localhost
Unter Umständen kann es aber auch passieren das man diese Meldung nicht sieht. Den auszugebenen Text findet man dabei in der Datei „/etc/motd“. Dort kann man das Verhalten beim Login allerdings nicht konfigurieren. Um die Meldung zu aktivieren, muss stattdessen die Datei „/etc/pam.d/login“ im Editor angepasst werden. Dort findet man die Zeilen:
# Prints the message of the day upon succesful login.
# (Replaces the `MOTD_FILE' option in login.defs)
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic noupdate
session optional pam_motd.so
welche je nach Bedarf ein oder auskommentiert werden können. Sind diese Zeilen bereits einkommentiert, so liegt das Problem am Fehlen des Kommandos „landscape-sysinfo“. Sobald das passende Paket „landscape-common“ nachinstalliert wurde, funktioniert das Anzeigen der Systeminformationen nach einem Login wieder.
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.
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:
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:
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.
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:
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:
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“.