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“.
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.
Wenn man bei einen normal konfigurierten Dovecot einen IMAP-Ordner mit dem Namen „“ anlegt, wird man im Mailprogramm folgende Ordnerstruktur zu sehen bekommen:
test@example
org
Der Grund ist darin zu finden, das der Punkt im Falle einer Maildir-Konfiguration standardmäßig als Trennzeichen eingerichtet ist. Möchte man trotzdem IMAP Ordner mit einem Punkt anlegen, so hilft das Dovecot-Plugin „Listescape“. Die Handhabung ist dabei denkbar einfach. In der „conf.d/20-imap.conf“ wird dazu die auskommentierte Zeile:
#mail_plugins =
durch
mail_plugins = listescape
ersetzt. Nun muss in der Datei „10-mail.conf“ im vordefinierten Namespace „inbox“ der Seperator neu definiert werden:
namespace inbox {
# Namespace type: private, shared or public
#type = private
separator = /
...
}
Er darf hier nicht auf einen Punkt gesetzt werden, da das ganze sonst nicht funktioniert. Nach einem anschließenden:
service dovecot restart
können dann auch neue Ordner mit einem Punkt im Namen angelegt werden. Auf bestehende Ordner wirkt sich das ganze allerdings nicht aus. Diese müssen bei Bedarf neu angelegt werden.