Sollten Sie direkt auf diesen Artikel über eine Suchmaschine gesprungen sein, dann empfiehlt es sich zuerst Blog Suchmaschinenoptimierung – Teil 1: Bestandsaufnahme zu lesen.

Der zweite Teil dieser vierteiligen Artikelserie

• Blog Suchmaschinenoptimierung – Teil 1: Bestandsaufnahme
• Blog Suchmaschinenoptimierung – Teil 2: Schlüsselwörter
• (Entwurf) Blog Suchmaschinenoptimierung – Teil 3: Technische Möglichkeiten
• (Entwurf) Blog Suchmaschinenoptimierung – Teil 4: Link Popularität

befasst sich damit, über welche Schlüsselwörter potentielle Besucher Ihr Blog finden können.

Blog Suchmaschinenoptimierung – Teil 2: Schlüsselwörter

Mit welchen Suchbegriffen würde mein Blog gefunden werden?

Haben Sie sich bereits Gedanken darüber gemacht, wie Suchende zu Ihrem Blog gelangen? Was würde ein Interessent für Stichworte in einer Suchmaschine eingeben? Gibt er nur ein Stichwort oder mehrere ein? Mit welcher Suchmaschine wird er versuchen relevante Seiten zu dem Thema zu finden?

Die Schwierigkeit herauszufinden welche Suchbegriffe für Interessenten relevant wären liegt in der Tatsache, dass man als Anbieter einer Dienstleistung oder eines Produktes bereits alle relevanten Schlüsselwörter und Daten kennt. Kennt ein Interessent diese Informationen im Vorfeld auch? Nein! Stellen Sie sich einen Kunden in einem Baumarkt vor, der für eine handwerkliche Aufgabenstellung einen Artikel sucht, der ihm die Arbeit erleichtert oder sogar passend für diese Aufgabe entworfen wurde. Je nach Aufgabenstellung, Bildungsgrad oder ob derjenige vom Fach ist, wird er unterschiedliche Möglichkeiten haben, an diese Information zu gelangen. Vielleicht ist er sich über solch einen Artikel nicht mal bewusst? Also wird so jemand seine Aufgabenstellung umschreiben. Vor kurzem musste ich Löcher in Wandkacheln bohren und wunderte mich warum ich mit meinen üblichen Bohrern nicht durch die Kachel kam bzw. die Kachel beschädige. Also ab in den Baumarkt und nach „Kachel bohren“ gefragt, dass es spezielle Kachelbohrer gibt, konnte ich nur ahnen. Also bin ich von der Aufgabenstellung und nicht von der Lösung ausgegangen. Und diese Sichtweise hilft bei der Findung von Schlüsselwörtern. Achten Sie hierbei auch auf die Konkurrenz! Als Webagentur sollte man nicht auf die gängigen Begriffe wie „Suchmaschinenoptimierung“ setzen, der Markt ist zu hart umkämpft. Außerdem greifen Suchende zu umschreibenden Zwei-oder gar Drei-Wort-Suchabfragen. Auch sollte man alternative Schreibweisen des Begriffs wie Singular oder Plural, Berücksichtung von Vertippern oder Mundart Beachtung schenken.

Schlüsselwortkriterien

Die Zeiten sind für Schlüsselwortfarmen oder ähnlich dummes Zeug lange vorbei. Verpacken Sie Ihre Schlüsselwörter in sinnvollen Inhalt. Google und Co. messen Zeiten zwischen Aufruf Ihrer Seite und dem Absprung des Benutzers. Sind diese Zeiten zu kurz werden Ihre Seiten nach hinten durchgereicht und meinen Sie, dass Ihre Seiten auf Seite 21 der Suchergebnisse angeklickt werden? Ok, es sind nur 20 Klicks plus die eigentliche Suchabfrage, die Mühe macht sich jeder in den Zeiten von der digitalen Überflutung. Also so abgedroschen es klingen mag, aber Inhalt ist noch immer König und Inhalt verhilft Ihnen im Orbit der Suchmaschinenrelevanzen zu bleiben und nicht nach kurzer Zeit in der Atmosphäre zu verglühen.

Auch sollte Ihnen bewusst sein, dass Ihr Blog nicht der Nabel der Blogosphäre ist, Ihr klitze kleiner Blog ist nur einer von vielen Millionen und die haben sogar ähnliche Themen wie Sie. Also gilt es umzudenken und nicht auf Top-Schlüsselwörter zu setzen. Das Gebot der Stunden lautet Alternativen finden:

• Einzelwort oder Begriffkombination
• Plural oder Singular
• Mit oder ohne Bindestrich
• Dialekte beachten
• Laie und/ oder Fachkollegen
• Mit oder ohne Stopworte
• Vertipper

Google bietet zu dem Thema das Keyword-Tool an. Damit lassen sich relativ schnell alternative Schlüsselwörter finden, die keine hohe Bewerberdichte, aber noch immer relevant für Suchende wären. Auch eine Verknüpfung zu einem Ort kann sinnvoll sein, besonders wenn Sie Kunden in Ihrem Umkreis ansprechen möchten.

Schlüsselwortdichte

Man sagt 5-7% Dichte pro Schlüsselwort sind unschädlich für eine Webseite. Es sollte das sogenannte „Stuffing“ vermieden werden, also stopfen Sie Ihren Blog nicht mit Schlüsselwörtern voll. Die Schlüsselwortdichte kann durch einfache online Tools wie http://www.seochat.com/seo-tools/keyword-density/ oder http://www.web-promotion-tools.de/promotion-tools/keyword-dichte.htm gemessen werden.

Schlüsselwortwichtigkeit hervorheben

Wie im ersten Teil beschrieben, kann durch einfaches HTML dem Crawler die Arbeit erleichtert werden und die Relevanz eines Schlüsselworts hervorgehoben werden. Wichtige Schlüsselwörter sollten soweit wie möglich im Artikel genannt werden, also verwenden Sie den sich im Web etablierten Pyramidenschreibstil (kurz und bündig das wichtigste vorab). Nutzen Sie H-,B-,U- und I-Tags um Textbereiche hervorzuheben. Wenn Sie Icons oder Bilder verwenden, dann versehen Sie diese immer mit dem Alt-und Title-Attribut, da Crawler Bilder bzw. dessen Aussagekraft nicht erfassen können.

Fazit zum Thema Schlüsselwörter

Schlüsselwörter sind der Wichtigste Zugang zu Ihrem Blog. Sie sollten daher besondere strategische Berücksichtigung finden und stetig im Suchmaschinenoptimierungsprozess neu eingeschätzt werden.

Hinweis

Diese Artikel ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

	Grundlagen der Suchmaschinenoptimierung: It’s not a trick – It’s knowledge von Thomas Promny
	Suchmaschinen-Optimierung für Webentwickler: Funktionsweisen von Google & Co. Ranking-Optimierung und Usability von Sebastian Erlhofer
	Website Boosting 2.0: Suchmaschinen-Optimierung, Usability, Online-Marketing von Mario Fischer

Zuallererst muss man von der Vorstellung, den Suchmaschinen – insbesondere Google – ein Schnippchen zu schlagen oder gar auszutricksen, weg. Das sollte nicht Ihr sportliches Ziel sein. Sehen Sie Suchmaschinen als einen Geschäftspartner für den Erfolg Ihrer Webseite und diesem Partner möchten Sie Ihre Ware verständlich präsentieren und erläutern, so dass die Suchmaschine wiederum Ihre Produkte Interessierten zugänglich machen kann. Und hierbei ist es vollkommen egal ob Sie Bröttchen verkaufen oder Artikel zum Erlernen von Häkeln anbieten, Grundlage für alle Webseiten sind Informationen!

Der erste Teil dieser vierteiligen Artikelserie

• Blog Suchmaschinenoptimierung – Teil 1: Bestandsaufnahme
• Blog Suchmaschinenoptimierung – Teil 2: Schlüsselwörter
• (Entwurf) Blog Suchmaschinenoptimierung – Teil 3: Technische Möglichkeiten
• (Entwurf) Blog Suchmaschinenoptimierung – Teil 4: Link Popularität

befasst sich mit der Bestandsaufnahme. Um einen effektiven Handlungsrahmen zur Optimierung des eigenen Blogs zu schaffen, erfolgt als erstes die Inventur der eigenen Blogseiten.

Teil 1: Bestandsaufnahme

Wie sieht eine Suchmaschine meinem Blog?

Wer schon einmal mit einem puristischen Textbrowser (z.b. Lynx) Webseiten besucht hat, wird verstehen warum man seinen Blog durch die “Augen” eines Crawlers anschauen sollte.
Search Engine Spider Simulator und
Spider Simulation sind zwei Simulatoren die einem die nötige Erkenntnis geben. Schnell fallen umfangreiche HTML Konstrukte (bsp. Tabellen) auf oder es verschwinden wichtige Textbestandteile (Überschriften, Texthervorhebungen etc.) im Zeichensalat. Hier wird jedem klar sein, dass HTML und CSS wichtige Werkzeuge, um eine Webseite für Suchmaschinen aufzuräumen, sind. Sie werden sich jetzt fragen: “Ein Crawler ist doch ein Programm und den kümmert es doch nicht ob eine Webseite aufgeräumt ist?”, damit haben Sie prinzipiell recht, aber auch ein Programm benötigt Anhaltspunkte um Informationen zu kategorisieren. Eine Überschrift soll als Überschrift erkennbar sein, auch für einen automatisierten Crawler. Es wäre zuviel des Guten etwas an dieser Stelle über das semantische Web zu schreiben, aber für Interessierte lohnt sich eine Recherche zu dem Thema. Später dazu mehr, wie genau man Quellcode aufräumen kann.

Wie ist die Webseite intern verlinkt?

Warum sollte man das wissen wollen, man möchte doch von außen verlinkt sein? Stellen Sie sich Ihre Webseite als Wegekonstrukt durch Ihre Themengebiete vor. Eine interne Vernetzung zu artverwandten Themen ist immer sinnvoll und erhöht zudem die Benutzerfreundlichkeit Ihrer Webseite. Machen Sie sich die Mühe und prüfen Sie stetig die interne Verlinkung, insbesondere bei Veröffentlichung neuer Artikel in Ihrem Blog. Zum einen kann man mit den Google Webmaster-Tools die interne Verlinkung prüfen und zum anderen gibt es eine Desktopapplikation namens Xenu’s Link Sleuth (TM). Mit Xenu’s Link Sleuth (TM) werden unter anderem auch Broken-Links schnell aufgespürt. Broken-Links zeugen von einem nicht aktualisierten Blog und das könnte relevant für Google und Co. sein und sollte daher zu den Aufgaben der Blogpflege gehören. So wie Sie Ihre Wohnung aufräumen, sollten Sie auch Ihren Blog rein halten oder um es mit den Worten eines Kollegen zu sagen: “Die Webseite braucht kein Redesign, eher sollte hier mal Hausputz gemacht werden!” und damit meint er das die vorhandenen Informationen der Webseite neu strukturiert werden müssen.

Unter welchen Begriffen finde ich Seiten meines Blogs?

Falls Sie ab diesem Zeitpunkt bereits bei Google Analytics einen Zugang besitzen, dann schauen Sie einfach der Realität ins Auge und prüfen mit welchen Schlüsselwörtern Webseiten besucht worden. Hierbei sollten Sie streng mit sich sein und “wirkliche” Besucher, Absprungraten und Aufenthaltsdauer berücksichtigen. Es gibt Webseiten die werden unter den tollsten Schlüsselwörter gefunden, sind aber inhaltlich toter als das Hirschgulasch von gestern.
Sollten Sie noch kein kostenfreies Analytics Konto nutzen, ist Ihrer Fanatasie freien Lauf gelassen, d.h. schnappen Sie sich eine Suchmaschine und versuchen Artikel Ihrer Webseite zu finden. Mit

site: blogdomain.de

(natürlich blogdomain.de mit Ihren Domainnamen ersetzen) in die Google Suchmaske eingegeben, sehen Sie alle Seiten die in Google zu Ihrer Domain indexiert sind. Anschliessend versuchen Sie mit passenden Schlüsselwörtern ein paar dieser Seiten in Google wiederzufinden.

Fazit der Bestandsaufnahme

Die Bestandsaufnahme dient dazu, dass Ihnen bewusst wird, wo Optimierungpotential existiert und Hebel ansetzbar sind. Im kommenden Teil Blog Suchmaschinenoptimierung – Teil 2: Schlüsselwörter befassen wir uns mit den Schlüsselwörtern, und der Verbesserung derer Wirkungsfähigkeit.

Hinweis

Diese Artikel ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

	Grundlagen der Suchmaschinenoptimierung: It’s not a trick – It’s knowledge von Thomas Promny
	Suchmaschinen-Optimierung für Webentwickler: Funktionsweisen von Google & Co. Ranking-Optimierung und Usability von Sebastian Erlhofer
	Website Boosting 2.0: Suchmaschinen-Optimierung, Usability, Online-Marketing von Mario Fischer

Protonotes bieten einen Service um digitale Post Its direkt in Webseiten-bzw. projekten einzubinden. Entweder setzt man dieses Tool als “Erinner mich” ein und/ oder man möchte den Mitentwicklern eine Notiz direkt an der richtigen Stelle online im Projekt hinterlassen.
Hat man sich bei Protonotes registriert erhält man eine Gruppenummer und kann sofort, nach Einfügen von etwas Javascript,

<script src="http://www.protonotes.com/js/protonotes.js" type="text/javascript"></script>
<script type="text/javascript">
var groupnumber="xxx";
var show_menubar_default=false;
var private_database_key="xxx";
</script>

mit den hilfreichen “Sticky notes” arbeiten. Mit einer ausblendbaren Toolbar werden Notizen erstellt, aus-oder eingeblendet. Die Notizen sind leicht transparent, verschiebbar und bieten Checkboxen für “reviewed” und “completed”.

Abbildung 1: Protonotes Screenshot

Möchte man die Notizen auf seinem eigenen Server speichern, bietet Protonotes das Hinterlegen von MySQL-Zugangsdaten seiner Datenbank an. Protonotes generiert hierfür einen private_database_key den man dann als Variable in Javascript übergibt. Auch eine .csv Exportfunktionen bietet Protonotes an, um alle Notizen in eine Datei zu sichern.

Fazit

Kostenlos und praxistauglich.

Den Urpsrung der Gestaltpsychologie entstand in den 20er als Gegenbewegung zur Elementenpsychologie. Die Elementenpsychologie wandte sich gegen die Vorstellung das die Wahrnehmung aus additiven Eindrücken besteht.

Ein Objekt das aus mehreren Teilobjekten besteht, hat für uns im Ganzen einen andere Bedeutung als die Teilobjekte im Einzelnen.

Als die Begründer der Gestalpsychologie gelten:

Abbildung 1: Max Wetheimer

Abbildung 2: Wolfgang Köhler

Abbildung 3: Kurt Koffka

Max Wertheimer setzte sich der Elementenpsychologie entgegen und widerlegte die Ansichten der Elementenpsychologie durch das Scheinbewegungsexperiment:
Wenn in einer Versuchsanordnung auf der linken Seite eines Feldes ein Lichtstreifen kurz auftritt, dann eine Dunkelpause von ca. 50 Millisekunden erfolgt, bevor der Streifen auf der rechten Seite des Feldes wieder auftaucht, so nimmt unsere Wahrnehmung im gesamten Versuchsaufbau eine Bewegung von links nach rechts wahr , obwohl während der Dunkelpause keinerlei physikalische Lichtreize vorhanden waren. Ab ca. 60-200 ms nimmt der Mensch Scheinbewegung wahr.

Typische Fragen der Gestaltpsychologie sind:

• Wie entsteht der Eindruck einer Form?
• Was ist eine „gute“ Form?
• Wie sehen wir Zusammenhänge zwischen Elementen?
• Warum sehen wir Zusammenhänge zwischen Elementen?

Weiterführende Themen:

• Wahrnehmung
• Gestaltgesetze

Um den PL/SQL Embedded Gateway zu verwenden, führt man als SYS zuerst das folgende

SQL> @$ORACLE_HOME/apex/apxconf.sql;

Konfigurations-Skript aus. Dieses SQL-Skript fragt nach dem HTTP-Port, über den später PL/SQL per URL angesprochen werden kann. Mit

SQL> EXEC DBMS_XDB.SETHTTPPORT(8080);

kann dieser Port nachträglich verändert werden. Ein Aufruf mit Port 0

SQL> EXEC DBMS_XDB.SETHTTPPORT(0);

deaktivert den PL/SQL embedded Gateway und mit

SQL> SELECT DBMS_XDB.GETHTTPPORT FROM DUAL;

wird der zur Zeit verwendete Port ausgegeben.
Nach der Konfiguration durch apxconf.sql kann mit dem Listener Status-Kommando

$ lsnrctl status

geprüft werden ob der Port aktiv ist. Es sollte eine Zeile ähnlich der folgenden

$ (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=...)(PORT=8080))(Presentation=HTTP)(Session=RAW))

mit aufgeführt werden.
Um bsp. PL/SQL Prozeduren über den PL/SQL Embedded Gateway zugänglich zu machen, benötigt man außerdem einen freigeschalteten

SQL> alter user ANONYMOUS account unlock

ANONYMOUS Benutzer.
Des Weiteren wird ein Database Access Descriptor (DAD) benötigt. Ein DAD übernimmt in etwa die Arbeit wie mod_plsql für den Apache.
Sozusagen ein Servlet für den XML DB HTTP Listener. Unter http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_web.htm im Abschnitt Table 10-2 Mapping Between mod_plsql and Embedded PL/SQL Gateway DAD Attributes sieht man zum Vergleich eine Gegenüberstellung der DAD und mod_plsql Attribute.
Ein DAD wird später durch einen Teil in der URL repräsentiert bzw. angesprochen.
Mit

SQL> EXEC DBMS_EPG.CREATE_DAD('PL_SQL', '/plsql/*');

erstellt man ein DAD mit der Bezeichnung PL_SQL und dem URL-Teilpfad /plsql/.
Damit der ANONYMOUS Benutzer für das DAD als eine Art “Schnittstelle” zwischen der DB und dem DAD zu fungieren kann, stellt man mit

SQL> EXEC DBMS_EPG.SET_DAD_ATTRIBUTE('PL_SQL', 'database-username', 'ANONYMOUS');

den ANONYMOUS Benutzer für das DAD ein.
Ab hier wäre der PL/SQL Embedded Gateway grundlegend konfiguriert. Um nun eine Prozedur eines Benutzers öffentlich über den
PL/SQL Embedded Gateway zur Verfügung zu stellen, muß die Prozedur für PUBLIC per

SQL> GRANT execute on PROZEDUR_NAME to public;

die Ausführbarkeit dieser Prozedur erlaubt werden. Wird in dieser Prozedur auf andere Objekte zugeriffen, müssen auch für diese die entsprechenden
Rechte (bsp. für Tabellen GRANT select on TABELLEN_NAME to public) vergeben werden. Erst anschließend ist nach folgenden URL-Schema

http://www.domain.de/plsql/objekt_inhaber.objekt_name

das Objekt aufrufbar.

Fazit

Der PL/SQL Embedded Gateway ist eine einfache Methode um datenbanknah Objekte oder APEX-Applikationen per Browser ausführbar zu machen. Es entfällt
die umfangreiche Konfiguration eines Apache Webservers. Auch sichere Verbindungen per SSL sind möglich. Benötigt man keine Sonderfunktionen á la
URL-Umschreibung (mod_rewrite) oder einen Auslagerung des Webserver (Perormanz-und Sicherheitsaspekte) und Ähnliches, dann reicht ein PL/SQL
Embedded Gateway für die meisten Fälle aus.

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Oracle APEX und Oracle XE in der Praxis von Dietmar Aust, Jens-Christian Pokolm und Denes Kubicek
• Oracle 10g für den DBA: Effizient konfigurieren, optimieren und verwalten von Johannes Ahrends, Dierk Lenz, Patrick Schwanke, und Günther Unbescheid
• Oracle 11g: Das umfassende Handbuch von Lutz Fröhlich

Was wird benötigt?

1. Linux Kernel >= 2.6
2. dvd+rw-tools
3. ein Backupordner mit Symlinks auf die Backupverzeichnisse
4. ein Cronjob auf eine ausführbares Shell-Script
5. ein Shell-Script für das Anstossen des Brennvorgangs

Zu 1.: Warum Linux Kernel >= 2.6

Unter der Kernel Version 2.6 wird ein IDE DVD Brenner als SCSI Gerät mit einer SCSI-Emulation angesprochen. Da dies etwas umständlicher ist und man schliesslich selbst das Derivat auf dem Heimserver bestimmen kann, empfehle ich ein Kernel >= 2.6 zu verwenden.

Zu 2.: dvd+rw-tools installieren

Mit

apt-get install -u dvd+rw-tools

installieren wir das benötigte Programm-Bundle um DVDs beschreiben zu können.

Zu 3.: Backupordner mit Symlinks auf die Backupverzeichnisse

Mit

mkdir ORDNERNAME

erstellen wir einen Ordner, welche die Symlinks auf die Backup-Verzeichnisse beinhalten wird.
Anschliessend erstellen wir mit

ln -s ZIEL LINKNAME

in diesem Ordner die Symlinks auf alle Verzeichnisse welche gesichert werden sollen. Warum Symlinks? Mit Symlinks ersparen wir uns die Daten – die bereits auf der Platte vorhanden sind – zu kopieren, des Weiteren sprechen wir wie durch Zauberhand immer die aktuellen Dateien an.

Zu 4.: Cronjob auf Shell-Script

Je nachdem wieviele Daten in einem gewissen Zeitraum zu erwarten sind, sollte der Cronjob im entsprechenden Intervall aufgerufen werden. Bsp. werden über 4,7 GB (normaler DVD-Rom, Vorsicht! Die Herstellerangaben für 1 GB entspricht 1000 MB und nicht 1024 MB, d.h. eine DVD-Rom kann also mit ca. 4,3 GB gefüllt werden) in einen Monat erwartet, sollte entweder der Cronjob in kürzeren Zeiträumen ausgeführt werden oder man gestaltet das Shell-Script so, dass die Datenmenge auf mehrere DVDs aufgeteilt wird oder man benutzt andere Medien (bsp. Dual-Layer-DVD mit ca. doppelter Kapazität im Vergleich zur einfachen DVD-Rom). In meinem Fall genügt ein monatliches brennen, also sehe der Cronjob folgendermaßen aus:

# m   h     dom    mon   dow   command
0     11      15    *     *     /usr/local/bin/dvdbackup.sh >> /var/log/burning-dvd-backup.log

Dieser Cronjob wird jeden 15ten im Monat um 11:00 Uhr ausgeführt und ruft das Script dvdbackup.sh auf. Mit >> /var/log/burning-dvd-backup.log leitet man die “grundlegende” Ausgabe des Scriptes in eine Log-Datei um. Warum ich hier von “grundlegende” Ausgabe spreche erläutere ich im nächsten Schritt.

Zu 5.: Shell-Script

Mit vi oder touch erstellen wir eine Textdatei namens “dvdbackup.sh”. Diese machen wir mit

chmod 755 dvdbackup.sh

ausführbar. Anschliessend kopieren wir folgendes Listing – mit entsprechenden Anpassungen – in die Textdatei:

#!/bin/bash
cat /dev/null > /var/log/burning-dvd-backup.log

echo "$(date '+%b %d %H:%M:%S') debian-mrs creating monthly backup dvd:"
echo "---------------------------------------------------------------------------------"

#image von symlink ordner erstellen
echo "creating iso backup image"
mkisofs -f -l -iso-level 4 -o /storage/tmpbackup.iso /storage/symbackupfolder/ >> /var/log/burning-dvd-backup.log 2>&1

isosize=`ls -al /storage/tmpbackup.iso | awk '{print $5}'`

if [ $isosize -lt 4697620480 ] ; then
        echo "burning iso backup image on dvd"
        growisofs -dvd-compat -Z /dev/hda=/storage/tmpbackup.iso >> /var/log/burning-dvd-backup.log 2>&1

        echo "eject dvd"
        eject
else
        echo "can't write iso backup image, because iso is to large"
fi

echo "remove iso backup image"
rm /storage/tmpbackup.iso

echo "---------------------------------------------------------------------------------"

Download dvdback.sh

dvdbackup.sh

Was macht das Script?
1. Mit cat /dev/null > /var/log/burning-dvd-backup.log leere ich die Log-Datei.

2. Die Ausgaben mit echo sind genau die Ausgaben die ich durch den Cronjob in die Log-Datei umleite.

3. Mit mkisofs -f -l -iso-level 4 -o /storage/tmpbackup.iso /storage/symbackupfolder/ >> /var/log/burning-dvd-backup.log 2>&1 erstellt man ein ISO-File namens tmpbackup.iso von dem erstellten Backup-Ordner, der wiederum durch die Symlinks die entsprechend zu sichernenden Ordner enthält. Die “spezielle” Ausgabe von mkisofs leite ich mit >> /var/log/burning-dvd-backup.log 2>&1 auch in die Log-Datei um. 2>&1 entspricht hierbei, dass alle Standardausgaben sowie Fehlermeldungen umge-”piped” werden.

4. Die erste if-Bedinung (if [ $isosize -lt 4697620480 ] ;) prüft die Größe des Images und vergleicht diese mit der maximalen Kapazität MEINER Rohlinge! Jeder DVD-Rohling ist unterschiedlich, mit atip kann man die freien Blöcke einer DVD ermitteln und mit 2048 Bytes (Blockgrösse) multiplizieren, nun hat man die maximale Kapazität der DVD in Bytes und ersetzt diese mit 4697620480.

5. Wenn das ISO-Image grösser als die maximale Kapazität meines Rohlings ist, wird der Brennvorgang abgebrochen, da ich nach oben noch ca. 500-800 MB Luft habe, ist das für mich die einfachste Lösung gewesen. Stattdessen kann man natürlich das ISO-Image mit split in mundgerechte Stücke zerteilen und hiervon wieder ISO-Images erstellen, die dann in einer Schleife nacheinander gebrannt werden (mit manuellen DVD Wechseln) oder man legt mehrere Backup-Verzeichnisse mit unterschiedlichen Symlinks an, um so bereits zu Beginn mehrere ISOs zu planen und anschliessend zu erstellen.

6. Passt das Image auf den Rohling, wird es nun mit growisofs -dvd-compat -Z /dev/hda=/storage/tmpbackup.iso >> /var/log/burning-dvd-backup.log 2>&1 gebrannt. Statt /dev/hda muss eventuell etwas anderes eingetragen werden, in meinem Fall ist das DVD Laufwerk über /dev/hda ansprechbar. Um den Gerätenamen herauszufinden, genügt ein Blick per vi in die /etc/fstab. Der zu indentifizierende Eintrag sollte so

<b>/dev/hda</b>        /media/cdrom0   udf,iso9660 user,noauto     0       0

oder ähnlich aussehen. cdrom0 oder ido9660 sind typischen Hinweise auf ein CD-Rom oder DVD-Laufwerk.

6. Abschliessend wird mit eject die DVD ausgeworfen und mit rm /storage/tmpbackup.iso das temporäre ISO-Image gelöscht.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Linux-Server mit Debian GNU/Linux. Das umfassende Handbuch und Praxisbuch für die Versionen Etch (Debian 4.0) und Sarge (Debian 3.1): Das umfassende Praxis-Handbuch von Eric Amberg
• Shell Skript Programmierung: Kommandos, Techniken, Konzepte. Die wichtigsten UNIX-Tools. Lösungen für den Systemadministrator von Patrick Ditchen
• Linux in a Nutshell von Ellen Siever, Stephen Figgins, Aaron Weber, und Lars Schulten

Diese Anleitung basiert auf einer Debian etch Distribution. Die Installation auf anderen Linux Derivaten sollte jedoch ähnlich vonstatten gehen. Für weiterführende Informationen lohnt sich ein Blick auf die offizielle DenyHosts Webseite zu werfen.

DenyHosts installieren

Mit dem Befehl apt-get

apt-get install denyhosts

wird zum einen DenyHosts installiert und sofern noch nicht vorhanden, Python mit installiert. Da DenyHosts eine Anwendung die in Python geschrieben ist, ist eine installierte Version von Python zwingend erforderlich.
Unter /usr/share/denyhosts ist das Installationsverzeichnis nach absetzen des Befehls zu finden.

DenyHosts konfigurieren

Unter /etc/ findet man nach der Installation die Konfigurationsdatei denyhosts.conf von DenyHosts. Hier werden alle wichtigen Einstellungen für die Verfahrensweise von DenyHosts justiert. Folgend die wichtigsten Einstellungen:

SECURE_LOG = /var/log/auth.log // anhand der Beschreibungen in der denyhosts.conf, muß hier die richtige Wahl der Log-Datei, abhängig von der eingesetzten Distribution, erfolgen. Mit # kann auskommentiert werden

DENY_THRESHOLD_INVALID = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche von nicht vorhandenen Benutzern

DENY_THRESHOLD_VALID = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche von vorhanden Benutzern

DENY_THRESHOLD_ROOT = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche durch root. VORSICHT! Standardwert ist auf 1 begrenzt, wenn man mit dem root Benutzer arbeitet sollte hier erhöht werden.

DENY_THRESHOLD_RESTRICTED = 3 // Anzahl erlaubter fehlgeschlagener Einlogversuche von eingeschränkten Benutzern

ADMIN_EMAIL = mail@el-mediaagentur.com // E-Mail Adresse um über neue geblockte Hosts und/oder verdächtige Einlogversuche informiert zu werden

Alle Weiteren Einstellungen können auf dem Ursprungswert gelassen werden, ansonsten ist ein Blick in die Erklärungstexte der Konfigurationsdatei oder des Handbuches gefragt.

DenyHosts Daemon starten

Mit einem beherzten Absetzen von

/etc/init.d/denyhosts start // normaler Start
/etc/init.d/denyhosts start .purge // erlaubt die Variable PURGE_DENY zu nutzen um geblockte Hosts nach der Zeitspanne wieder aus der hosts.deny zu entfernen

auf der Konsole wird DenyHosts gestartet.

Wenn Werte in der Konfigurationsdatei geändert wurden, werden diese erst nach einem Neustart

/etc/init.d/denyhosts restart

in Kraft treten.

Hinweis

Das sportliche Ziel eines Angreifers ist sicherlich Root-Rechte zu erlangen. Wenn man mit dem Benutzer Root per SSH arbeiten muß, empfiehlt es sich über die SSH Konfiguration das direkte Einloggen des Root-Benutzers zu unterbinden. Stattdessen sollte über einen anderen Account, mit minimalen Rechten eingeloggt und dann mit su zu dem Root-Benutzer gewechselt werden. So hat der Angreifer zwei Passwörter als Barriere.

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Linux Server-Sicherheit von Michael D. Bauer
• Linux Hacker’s Guide. Sicherheit für Linux- Server und -Netze
• Praxisbuch Sicherheit für Linux-Server und -Netze von Barbara Oberhaitzinger, Helmar Gerloni, Helmut Reiser und Jürgen Plate

Das Binary Log schreibt zur Laufzeit alle auf dem Server ausgeführten SQL-Transaktionen mit, dies wiederum verbraucht Ressourcen (je nach Frequentierung >= 1% CPU), weshalb manche Administratoren die Aktivität des binären loggen eingrenzen oder gar ausschalten. Die Vorteile die das Binary Log mitbringt sind aber enorm, insbesondere wenn neue Applikationen fehlerhafte SQL-Anweisungen absetzen.

Binäres Loggen konfigurieren

Alle Einstellungen die das Binary Log betreffen werden in der /etc/mysql/my.cnf vorgenommen

log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M

Durch log_bin wird der Speicherort der Log-Dateien bestimmt. expire_logs_days bestimmt den Zeitraum, in welchen die Logs aufbewahrt werden sollen, in dem Beispiel werden alle Logs die älter sind als 10 Tage entfernt. max_binlog_size gibt die maximal zugelassene Dateigröße für ein Log-File an. Die Angabe von max_binlog_size sollte unter Debian Systemen nie ohne die Einstellung log_bin aufgeführt werden, da hier der Server abstürzen würde. Je nachdem wieviele SQL-Statements erzeugt werden ist abzuwägen welche Größe und welcher Zeitraum berücksichtigt bzw. zugelassen werden soll. Unbedacht erstellte Applikationen können manchmal riesige Mengen an SQL-Anweisungen innerhalb eines Tages erzeugen, wenn diese Anwendung auch noch von mehreren Benutzern gleichzeitig benutzt wird, kann man sich ausmalen, dass die Grenzen eines zu klein gewählten Log-Files schnell erreicht sind und dann wäre der Vorteil dahin. Um Änderungen an der my.cnf wirksam zu machen, muß der MySQL Server neugestartet werden.

Einfaches Wiederherstellen

Durch das binäre Loggen in Verbindung mit der Sicherung der binären Log-Dateien ist es möglich ein vollst. Backup-Konzept zu erstellen. Empfehlen würde ich in Hinsicht auf die mitgeführten redundanten Daten nicht. Praktikabler ist das normale tägliche Backup (bsp. per MySQL Dump oder ähnliches) in Kombination mit dem Binary Log.
Ein alltägliches Backup Szenario könnte folgendermaßen aussehen, vorrausgesetzt das tägliche Backup (bsp. immer um 00:00Uhr) und das Binary Log sind aktiv. Angenommen alle Daten gingen aus irgendeinem Grund verloren, dann ist der erste Schritt den Zugriff auf die Datenbank exklusiv für den Administrator zu setzen:

$ mysqld --socket=/tmp/mysql_restore.sock --skip-networking

skip-networking ermöglicht den Zugriff nur über SSH oder direkt an der Server Konsole.
Nach der Einschränkung des Zugriffs von außen, kann das tägliche Backup per Konsole eingespielt werden um so den Datenstand vom Vortag zu erhalten:

$ mysql -u root -ppassword  --socket=/tmp/mysql_restore.sock \
    < /var/backup/20080325.sql

Mit diesem Befehl wird das SQL Backup direkt auf den mysql_restore.sock geleitet. Anschliessend müssen noch die interim Daten wiederhergestellt werden, also die Daten die nach 00:00Uhr entstanden sind. Dazu verwendet man das Werkzeug mysqlbinlog. Vor Benutzung des Tools muß herausgefunden werden welche Log Dateien den jetzigen Tag betreffen, ein einfacher ls -la auf der Konsole im Binary Log Verzeichnis wird alle nötigen Informationen liefern. Nun kann von der kleinsten laufenden Nummer auftsteigend zum neuesten Log folgendermaßen vorgegangen werden:

$ mysqlbinlog /var/log/mysql/mysql-bin.000xxx \
   | mysql -u root -ppassword \
           --socket=/tmp/mysql_restore.sock

Mit diesem Befehl werden alle Statements die durch das Binary Log in der Log Datei aufgezeichnet wurden direkt auf der MySQL Datenbank abgesetzt und erneut ausgeführt. Wenn man alle Log-Daten so abgearbeitet hat, hat man alle Daten bis zum DB-Crash wiederhergestellt. Ein abschliessender MySQL-DB Neustart wird die Datenbank wieder zur Verfügung stellen.

Manuelles Wiederherstellen

Es kann vorkommen, dass man nicht alle Daten wiederherstellen möchte, da nur eine fehlerhafte Anweisung Daten gelöscht hat. Dazu piped (umleiten) man die Ausgabe nicht direkt auf den MySQL Socket um, sondern in ein seperate Textdatei:

$ mysqlbinlog /var/log/mysql/mysql-bin.000xxx \
    > /tmp/tmp_mysql-bin-000xxx..sql

Danach kann mit vi oder vim oder einem anderen Texteditor die temporäre erstellte Datei bearbeitet werden, eventuell fehlerhafte Anweisungen entfernt und danach erneut in die DB eingespielt werden.

Punktgenaues Wiederherstellen (Zeitstempel)

Ab MySQL Version 4.1.4 sind die Parameter –start-date und –stop-date hinzugefügt wurden. Diese ermöglichen punktuelles Recovery. Beispielsweise löschte eine Anweisung die um 12:00Uhr am 23.03.2008 ausgeführt wurde einige Daten. Die Vorgehensweise wäre die gleiche wie die eben beschriebene, man spielt das tägliche Backup zurück und führt anschliessend folgendes Kommando aus:

$ mysqlbinlog --stop-date="2008-03-23 11:59:59"
      /var/log/mysql/bin.000xxx |
    mysql -u root -ppassword \
          --socket=/tmp/mysql_restore.sock

Hiermit werden alle SQL-Statements die bis 11:59:59 aufgelaufen sind neu auf der Datenbank ausgeführt. Wenn man die fehlerverursachende SQL-Anweisung nicht exakt ausfindig machen kann, dann möchte man vielleicht an dieser Stelle alle Anweisungen die nach dem Fehlerzeitraum abgesetzt wurden wiederherstellen:

$ mysqlbinlog --start-date="2008-03-23 12:00:01"
      /var/log/mysql/bin.000xxx |
    mysql -u root -ppassword \
          --socket=/tmp/mysql_restore.sock

Mit diesen beiden Parametern kann man sehr punktuell Daten wiederherstellen und fehlerhafte SQL-Anweisungen zu umgehen.

Punktgenaues Wiederherstellen (Positionsangabe)

Nach dem gleichen Prinzip wie start-date und stop-date funktioniert start-position und stop-position. Wenn man eine binäre Log-Datei in eine Textdatei ausgibt, dann erkennt man das jedes SQL-Statement eine eindeutige Log-Positionsangabe mitführt, auf dieser Basis kann man genauso punktuell Daten wiederherstellen. Wann wird diese Vorgehensweise notwendig? Ganz einfach, wenn man den ungefähren Zeitpunkt des Problemfalles nicht kennt, dann führt kein Weg an dieser Methode vorbei.

Fazit

Die Nachteile liegen in dem Verbrauch der Ressourcen, SQL-Statement lastige Anwendungen fluten die Logs, es gilt abzuwägen, wieviel Ressourcen man hierfür als notwendig ansieht. Die Vorteile heben sich aber deutlich von den Nachteilen ab. Ich kam selbst in den Genuß eine MySQL Datenbank in 5 Minuten wieder in ordnungsgemäßen Zustand versetzen zu dürfen, seitdem ist für mich ist das Binary Log Recovery unverzichtbar um eine bessere Datensicherheit bzw. geringere Ausfallzeiten zu gewährleisten.

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Das offizielle MySQL 5-Handbuch von MySQL MySQL AB
• MySQL 5. Einführung, Programmierung, Referenz (Open Source Library) von Michael Kofler
• MySQL 5. Für Professionals von Axel Bornträger

Folgende Vorgehensweise beschreibt die Konfiguration von Spamassassin, um sa-learn per E-Mail (Spam oder Ham per Anhang) zu trainieren.

Voraussetzung

Voraussetzung ist eine intakte Installation von Spamassassin und procmail. Lassen Sie sich nicht abschrecken von der Länge des How-Tos, der Mehrwert zur Bekämpfung von Spam ist nicht zu vernachlässigen.

Schritt 1: Procmail durch procmailrc konfigurieren

Procmail ermöglicht vor Auslieferung von E-Mails diese vorzubearbeiten, bsp. als Spam zu markieren, ins Nirvana zu schicken (/dev/null) oder Tools wie sa-learn damit zu konfrontieren.
Die Datei die die nötigen Anweisungen enthält befindet sich unter /etc/procmailrc. Procmail ist sehr mächtig und ermöglicht allerhand Einsatzzwecke, es lohnt sich ein Blick auf http://www.procmail.org/ zu werfen.
An folgende Beispiel-Konfiguration verdeutliche ich die Vorgehensweise von procmail (s. Kommentare)

DROPPRIVS=yes
#Logfile für debugging
LOGFILE=/var/log/procmail
#Für debugging [ON|OFF]
VERBOSE=ON
#Welche Shell soll benutzt werden
#SHELL=/bin/sh

#Mails die kleiner als 256000 Bytes sind, sollen mit spamc -f geprüft werden
:0fw
* < 256000
| /usr/bin/spamc -f

#Wenn die Mail an spam@domain.de ausgeliefert werden soll, dann soll das Script sa-wrap.pl mit der Option - -spam ausgeführt werden. Die sa-wrap.pl ermöglicht das Anlernen von Spam (schlechte E-Mails) und Ham (gute E-Mails) als Attachment, in Schritt 3 wird dieses Script behandelt.
:0
* spam@domain.de
{
:0fw
| /usr/local/bin/sa-wrap.pl - -spam
:0
/dev/null
}

#Wenn die Mail an ham@domain.de ausgeliefert werden soll, dann soll das Script sa-wrap.pl mit der Option - -ham ausgeführt werden.
:0
* ham@domain.de
{
:0fw
| /usr/local/bin/sa-wrap.pl - -ham
:0
/dev/null
}

#Alle E-Mails, die das SPAM-Level von mehr als 7 (Sterne) erreicht haben und an domain1.de etc. ausgeliefert werden sollte, wird zu /dev/null weitergeleitet, also gelöscht. Augenmerk ist auf TO.*undisclosed-recipients zu richten, hier werden auch die Mails behandelt die keinen eindeutigen Empfänger führen, manche Spam-Mails wollten hiermit gewisse Mechanismen austricksen
:0 w
* ^TO.*@domain1.com|TO.*@domain2.com|TO.*@domain3.de|
TO.*@domain4.de|TO.*@domain5.com|TO.*@domain6.de|TO.*@domain7.de|
TO.*undisclosed-recipients
* ^X-Spam-Level:.*\*\*\*\*\*\*
/dev/null

#Ab hier kommt ein Work-Around, um ein Problem mit procmail in gewissen Konstellationen zu beheben

# Work around procmail bug: any output on stderr will cause the “F”
#in “From”
# to be dropped. This will re-add it.
:0 H
* ! ^From[ ]
* ^rom[ ]
{
LOG=”*** Dropped F off From_ header! Fixing up. “

:0 fhw
| sed -e ’s/^rom /From /’
}

Die Syntax von procmail ist gewöhnungsbedürftig, aber wenn man das Schema verstanden hat, kann man das Script prima anpassen. Es gibt einige Quellen, wenn man procmail intensiver verstehen möchte. Damit das Logging und das spätere Zwischenspeichern und Entpacken der angehangenen Spam und Ham E-Mails in Zusammenhang mit procmail funktioniert, müssen wir /var/log/procmail, /var/log/sa-lear.log und /var/spool/unpack erstellen und die nötigen Rechte und Gruppen setzen:

$ touch /var/log/procmail.log
$ chown root:mail /var/log/procmail.log
$ chmod 666 /var/log/procmail.log
$ touch /var/log/sa-learn.log
$ chown root:mail /var/log/sa-learn.log
$ chmod 666 /var/log/sa-learn.log
$ mkdir /var/spool/unpack
$ chown root:mail /var/spool/unpack
$ chmod 777 /var/spool/unpack

DOWNLOAD der Beispiel procmailrc

procmailrc

Schritt 2: Einrichten der beiden E-Mail Adressen

Die im Huckepack gesandten Spam oder Ham E-Mails werden an zwei Adressen gesandt. Hier in der Beispiel procmailrc sind es spam@domain.de und ham@domain.de. Diese beiden Adressen müssen existieren. Wie diese erzeugt werden ist egal.

Schritt 3: Einrichten der sa-wrap.pl

Die sa-wrap.pl ist das Script welche die weitere Verarbeitung der Anhänge übernimmt und sa-learn zuführt. Im Beispiel Script von procmail liegt das Script unter /usr/local/bin/sa-wrap.pl.

DOWNLOAD sa-wrap.pl

sa-wrap.pl

Wenn man das Script anschaut, gibt es nur ein paar Möglichkeiten Einstellungen vorzunehmen

#
# Thanks to: Chung-Kie Tung for the removal of the dir
# Adam Gent for bug report
#
# v1.2

use strict;
use MIME::Tools;
use MIME::Parser;

#Debugging aus- oder einschalten [0|1]
my $DEBUG = 0;
#Entpackverzeichnis
my $UNPACK_DIR = ‘/var/spool/unpack’;
#Pfad zu sa-learn
my $SA_LEARN = ‘/usr/bin/sa-learn’;
#kann vernachlässigt werden
my @DOMAINS = qw/gtmp.org winnink.org/;
.
.
.

Die Pfade sollten natürlich angepasst werden, sofern man andere gewählt hat. Um die Fehlersuche zu unterstützen ist das Debugging wertvoll. Die Logs werden pro versandte E-Mail erzeugt und stadardmäßig unter /tmp abgelegt (spam.log.16377 etc.). Des weiteren werden zusätzliche Informationen in der /var/log/procmail abgelegt.

HINWEIS

Es gibt eine neuere sa-wrap.pl namens sa-wrapper.pl auf die ich nicht weiter eingehe, da ich zufriedener mit der alten Version bin. Mit einer Suche in Google oder einer anderen Suchmaschine nach sa-wrapper.pl wird man fündig werden.

Schritt 4: Der Test

Nach einem Neustart des Spamassassin Daemons kann man einen Test durchführen. Man nehme eine leere E-Mail und setze Spam oder Ham E-Mails als Attachement ein (wieviele Anhänge ist egal, es wird iterativ abgearbeitet) und schickt diese entwerder an spam@domain.de oder ham@domain.de, wobei natürlich hier die erstellten E-Mail Adressen genutz werden sollen und keine fiktiver Domainname. Wie überprüft man nun den Erfolg?
Ganz einfach auf der Kommandozeile

$ sa-learn –dump magic

wobei magic eine Kurzübersicht bietet. Es sollte so etwas hierbei herauskommen

$ /tmp # sa-learn –dump magic
0.000 0 3 0 non-token data: bayes db version
0.000 0 13938 0 non-token data: nspam
0.000 0 12353 0 non-token data: nham
0.000 0 169414 0 non-token data: ntokens
0.000 0 1170422819 0 non-token data: oldest atime
0.000 0 1205088456 0 non-token data: newest atime
0.000 0 1205058100 0 non-token data: last journal sync atime
0.000 0 1205040158 0 non-token data: last expiry atime
0.000 0 0 0 non-token data: last expire atime delta
0.000 0 0 0 non-token data: last expire reduction count

Wenn das Lernen erfolgreich war wird der Count von nspam oder nham erhöht worden sein. Man kann natürlich auch mit Hilfe der Logs den entsprechenden Erfolg einsehen.

Voila!

HINWEIS

Nicht jeder Spam wird nach dem Anlernen erkannt werden, manchmal muss man ähnlichen Spam mehrmals senden. Auch das Versorgen mit guten E-Mails (Ham) darf nicht vernachlässigt werden, da hierüber Vergleiche gemacht werden.

Nachtrag: Bug in neueren Spamassassin Versionen

Vor kurzem stiess ich auf einen Bug in einer neuen Spamassassin Version. Die Logs führten folgendes auf

archive-iterator: invalid (undef) format in target list, 2
at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/
ArchiveIterator.pm line 727, line 1.

, wenn das Auftreten sollte muss die sa-learn unter /usr/bin/ angepasst werden. Die Hinweismeldung kommt durch ein nicht gesetztes Target auf. Was ist zu tun?

Lösung: /usr/bin/sa-learn anpassen

Index: sa-learn.raw
================================================================
— sa-learn.raw (revision 507745)
+++ sa-learn.raw (working copy)
@@ -402,7 +402,10 @@

# make sure the target list is in the normal AI format
if ($targets[$elem] !~ /^[^:]*:[a-z]+:/) {
- $targets[$elem] = target($targets[$elem]);
+ my $item = splice @targets, $elem, 1;
+ $elem–; # go back to this element again
+ target($item); # add back to the list
+ next;
}
}

- Zeile entfernen
+ Zeile einfügen

Die entpsrechende Zeilen könnt ihr an # make sure the target list is in the normal AI format erkennen.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• SpamAssassin von Alan Schwartz
• Mit Open Source-Tools Spam und Viren bekämpfen. Für Unix- und Linux-basierte Mailsysteme von Peter Eisentraut und Alexander Wirt
• Postfix Ge-Packt von Tobias Wassermann

HINWEIS:

Passwortlose Authentifizierung bürgt Gefahren, hier zwei Szenarien.
1. Ein Angreifer erlangt Zugang zum Zielhost und kann in einem fremden Account in die Datei ~/.ssh/authorized_keys schreiben.
2. Ein Angreifer hat Zugriff auf den Quellhost und dessen Dateien ~/.ssh/id_dsa oder ~/.ssh/id_rsa. Beide Dateien sind ausserdem nicht passwortgeschuetzt.

Wer die Gefahren ausschliessen kann, sollte weiterlesen.

Schritt 1: Schlüssel mit ssh-keygen generieren

Nach Ausführung von

$ ssh-keygen -t dsa

auf dem Quellhost (Ort und Passwort leer lassen und mit Return bestätigen), werden in $HOME/.ssh/ die Dateien ~/.ssh/id_dsa und ~/.ssh/id_dsa.pub erzeugt.

Schritt 2: Public Key auf Zielhost übertragen

Hier führen viele Wege zum Ziel. Der Inhalt der erzeugten Datei ~/.ssh/id_dsa.pub muß an die .ssh/authorized_keys des Zielhosts angehangen werden. Ob mit cat, ssh-copy-id oder anderen Übertragungsmöglichkeiten gearbeitet wird, ist grundsätzlich egal. Hier ein elegantes Beispiel:

$ cat ~/.ssh/id_dsa.pub | ssh user@remotehost ‘cat >> .ssh/authorized_keys’

Als remotehost ist eine IP oder Domain möglich.

HINWEIS:

Die Berechtigungen der authorized_keys müssen auf 0600 gesetzt werden. Sonst lässt der Rechner unter Umständen aus Sicherheitsgründen gar keine Verbindung per Schlüssel zu.

Schritt 3: Verbidungsversuch

Wenn ich alles hier korrekt geschildert habe und es so umgesetzt wurde, sollte folgender Verbindungsaufbau vom Client ohne Passwortabfrage funktionieren:

ssh user@remotehost

Wobei remotehost eine IP oder Domain sein kann.

Voila!

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.