Server

Domainwechsel RewriteRules

So, der schon länger geplante Domainwechsel ist geschafft.
Gleichzeitig hat hier auch ein frisches, wenn auch nicht ganz individuelles Theme einzug gehalten.

Folgender .htaccess Eintrag hat noch die Umleitung von Adressen mit und ohne www auf die neue Doamin ohne www Prefix möglich gemacht:

RewriteCond %{HTTP_HOST} ^.*knevels.org$ [NC]
RewriteRule ^(.*)$ http://dropspace.de/$1 [R=301,L]

Hier die Erklärung:

RewriteCond = Bedingung um die folgende RewriteRule auszuführen
^ = Der Hostname %{HTTP_HOST} muss mit dem String www.alte... beginnen
.* = siehe unten
$ = Zeigt das Ende eines Ausdrucks an
[NC] = No case, dh.: Groß- und Kleinschreibung werden nicht beachtet
RewriteRule = wird ausgeführt, wenn RewriteCond zutrifft
() = fassen einen Ausdruck zusammen
. = jeder einzelne Buchstabe
* = jeder weitere einzelne Buchstabe (wegen des Punktes)
$1 = Hängt die gesamte restliche Adresse, die per ^(.*)$ gematcht wurde, an die Domain aus dem Redirect
R=301 = Moved Permanently Redirect
L = Letztes RewriteRule

 

 

Weitere Links zu mod_rewrite:

 

PuTTY und Pagent Shortcuts

Ich nutze jetzt schon seit einiger Zeit PuTTY für die Verbindung zu meinem vServer. Da ich gerade auf die komfortable und sicherere PublicKey Authentication umgestiegen bin, hier der passende Tip, wie man für Putty und Puttyagent die Logindaten bereits per Verknüpfung übergibt.

Wenn man in PuTTY bereits ein Profil gespeichert hat, kann man dieses später mit einem an die Verknüpfung zur putty.exe angehängtes -load wieder aufrufen. Damit auch der Loginname übergeben wird, kann man noch -l angeben. (Natürlich ohne die <> Klammern).

Bsp.:  "C:\Program Files (x86)\Putty\putty.exe" -load -l

Weitere Optionen findet man in der Dokumentation, ab Punkt 3.8.  “The PuTTY commandline”. Es ist sogar möglich, ein Passwort zu übergeben, worauf ich sicherheitshalber verzichte.

Wer sich häufig verbindet, dem ist eher zu empfehlen, den Puttyagent zu nutzen. Hier reicht es, wenn der PrivateKey einmal freigeschaltet wird. Bis der Agent wieder geschlossen wird, merkt sich pagent.exe die Passphrase und es reicht, wenn in der nächsten SSH-Session nur der Username angegeben wird.

Für Pagent sieht die Verknüpfung mit Pfad zum Key so aus:

"C:\Program Files (x86)\Putty\pageant.exe"

Gratis SSL-Zertifikat erstellen

Wer sich schon einmal ein self-signed Zertifikat erstellt hat wird wissen, dass alle Browser vor dem Aufbau einer Verbindung eine nervige, bzw. abschreckende Warnung ausgeben.

Wer ein SSL-Zertifikat von einer anerkannten Autorität haben wollte, musste dafür bisher, auch wenn es nur um ein Hobbyprojekt ging, tief in die Tasche greifen.

Einen guten Ansatz hat die spendenfinanzierte Gemeinschaft CAcert.org verfolgt, konnte es aber bisher nicht in die Stammzertifikatslisten schaffen.
Jetzt bietet der kommerzielle Anbieter StarCom mit StarSSL kostenlose SSL-Zertifikate an, die bis auf Opera allen wichtigen Browsern bekannt sind.

Die Anmeldung ist etwas gewöhnungsbedürftig. Zuerst einmal bekommt man kein Passwort, sondern ein Client-Zertifikat, mit dem man sich in seinem Account anmeldet (und was man gut aufheben sollte). Zum Anderen fand ich die Menüführung kompliziert.

Vor allem sollte man sich bewusst sein, dass die erstellten Zertifikate nach einem Jahr erneuert werden müssen und es keine kostenlosen Wildcard-Zertifikate gibt.

Während der Installation wird zwar angeboten, ein Schlüsselpaar generieren zu lassen, es ist aber empfehlenswert seinen Privaten Schlüssel selbst zu erstellen.

Eine sehr gut bebilderte Anleitung habe ich bei Lernschmiede.de – kostenfreie Zertifikate gefunden.
Bei heise.de gibt es ebenfalls eine kurze Anleitung.
Auch das StarCom Wiki bietet eine ausführliche Installationshilfe.

SSH absichern

Nach der Neuinstallation eines Servers mit Internetanbindung sollte man zuerst einmal seine SSH-Verbindung absichern.

Dazu sind folgende Schritte sinnvoll und können an der /etc/ssh/sshd_config durchgeführt werden:

  1. Default SSH Port ändern
  2. Root Login verbieten
  3. Nur einem User den Login erlauben
  4. Diesem User alle Rechte, bis auf su entziehen
  5. Fail2ban oder DenyHosts installieren
  6. Evtl. SSH Key Auth statt Passwort nutzen
  7. Evtl. SSH per IPTables nur für DynDNS IP erlauben

Die meisten der oben aufgeführten Schritte werden auf wiki.debianforum.de erklärt.

Go to Top