Wenn das der Fall ist, liegt die Vermutung nahe, dass Nautilus verantwortlich ist. Abhilfe schaffen gleich zwei Methoden:

gconftool -t bool /apps/nautilus/preferences/show_desktop -s false

oder falls das nicht funktioniert:

sudo touch /usr/local/bin
sudo chmod +x /usr/local/bin/nautilus
sudo echo -e "#!/bin/sh\n/usr/bin/nautilus --no-desktop" > /usr/local/bin/nautilus

Kurz zur Erklärung:

Die erste Methode sagt Nautilus, dass es sich nicht mehr um den Desktop kümmern soll. Die zweite Methode macht das auch, nur bei jedem Start von Nautilus aufs Neue. Dafür wird ausgenutzt, dass /usr/local/bin vor /usr/bin im PATH steht und somit beim Aufruf von “nautlius” die dort angelegte Datei ausgeführt wird. Diese ruft dann Nautlius mit dem Parameter “–no-desktop” auf.

Man öffnet eine ssh-Verbindung, gibt seinen Benutzernamen ein, dann das Passwort und ist schließlich angemeldet. Aus Sicherheitsgründen hat das Passwort 18 Stellen oder mehr, oft genug kommt es vor, dass man sich vertippt, im schlimmsten Fall so oft hintereinander, dass die eigene IP-Adresse vom Server gesperrt wird. Zugegeben, das ist ein übertriebenes Horror-Szenario, aber ausschließen, dass es schon passiert ist, möchte ich nicht.

Warum also nicht ganz ohne Passwort anmelden?

Die Möglichkeit besteht durchaus, ist noch dazu sicherer als die Anmeldung per Passwort und natürlich gemütlicher. Die Rede ist von der Authentifizierung mit einem Schlüsselpaar (z.B. RSA). Dieses Schlüsselpaar muss für jeden Client einmal generiert werden. Der öffentliche Schlüssel wird dann auf dem Server abgelegt, damit er weiß, dass der Client sich anmelden darf. Nun ist der öffentliche Schlüssel des Clients aber, naja, öffentlich, also wird der Anmeldevorgang signiert. Dies geschieht mit dem privaten Schlüssel des Clients, der natürlich nur dem Client bekannt ist. Wie genau die Überprüfung funktioniert, weiß ich nicht, eine simple Möglichkeit wäre aber folgende (evtl. ist es auch die tatsächlich genutzte):

Der Server sendet eine zufällig generierte Zahl an den Client,  die auch nur einmal verwendet wird (nennt sich NONCE). Der Client verschlüsselt diese Zahl mit seinem privaten Schlüssel und schickt das Ergebnis wieder an den Server. Dieser versucht, die empfangene Nachricht mit dem öffentlichen Schlüssel des Clients zu entschlüsseln. Gelingt ihm dies, so ist es (nahezu) unmöglich, dass jemand anderes als der richtige Client gerade versucht, sich mit dem öffentlichen Schlüssel anzumelden.

Das Verfahren wird allgemein als sicher angesehen und wenn man sich die am häufigsten benutzten Passwörter ansieht, so ist dieses Verfahren im Gegensatz dazu die Definition von Sicherheit.

Zur Einrichtung begibt man sich zunächst an den Client. Hier wird mittels

ssh-keygen -t rsa

ein Schlüsselpaar generiert. Es ist vermutlich empfehlenswert, eine Passphrase für den Schlüssel zu vergeben, allerdings entfällt dann der Vorteil, dass man sich ohne Passwort anmelden kann. Vergibt man keine, so muss man sicherstellen, dass niemals der private Schlüssel öffentlich bekannt wird.

Es werden zwei Dateien erzeugt, eine mit dem privaten Schlüssel und eine mit dem öffentlichen. Letztere hat die Endung .pub (für public).  Der Inhalt dieser Datei muss auf dem Server an die Datei /home/[user]/.ssh/authorized_keys angefügt werden.

Dieses Vorgehen muss für jeden Client einmal wiederholt werden. Die Clients müssen, wie bereits erwähnt, entsprechend geschützt sein, damit der private Schlüssel nicht bekannt wird.

Unter Windows ist die Erzeugung des Schlüsselpaares etwas umständlicher. Will man diese Art der Authentifizierung z.B. mit PuTTY verwenden, so benötigt man zunächst das Programm PuTTYgen. Hier kann man als Typ SSH2-RSA mit 2048 Bits wählen. Klickt man auf Generate, so muss die Maus erst einige Zeit bewegt werden, damit der Schlüssel möglichst zufällig ist.

Anschließend muss der Inhalt des Textfeldes an die Datei /home/[user]/.ssh/authorized_keys angefügt werden. Dies ist der öffentliche Schlüssel. Den privaten Schlüssel speichert man (save private key), wo man ihn wieder findet.

In Putty muss diese Datei unter SSH->Auth als Private key file ausgewählt werden. Anschließend sollte die Verbindung ohne Passwort funktionieren.

Nach dieser Anleitung könnte man auf die Idee kommen, auch die Anmeldung an einem ssh-Server, der z.B. über cygwin unter Windows läuft, durch RSA zu ermöglichen. Vorab: Nein.

Warum das nicht so einfach möglich ist, wird schnell klar, wenn man verstanden hat, wie diese Anmeldung unter Linux überhaupt funktionieren kann. Wir melden uns an einem Rechner mit einem Benutzernamen aber ohne dessen Passwort an. Auch in den Dateien, die wir dafür angelegt oder geändert haben, ist das Passwort nirgends gespeichert.  Alles andere wäre auch irrsinnig.

Unter Linux ist das möglich, weil root eine Shell für einen beliebigen Benutzer öffnen kann – ohne Passwort. Nun läuft der ssh-Server unter dem Benutzer root, also hat der Server dieses Recht. Wir versichern dem Server durch unsere Authentifizierung, dass wir ein bestimmter Benutzer sind und er öffnet für uns die entsprechende Shell. Unter Windows ist es selbst dem Administrator nicht möglich, sich einfach als ein anderer Benutzer auszugeben. Eine Anmeldung ohne Passwort ist ohne weitere Eingriffe also nicht möglich. Natürlich darf der Administrator das Passwort eines Benutzers zurücksetzen und kennt dann das neue Passwort – aber das wollen wir wohl kaum als Anmeldeprozedur implementieren.

Falls doch jemand voreilig etwas in die authorized_keys eines Windows-Servers eingetragen hat, so ist die Anmeldung von dem eingetragenen Client aus nicht mehr möglich. Also entweder einen anderen Client benutzen oder lokal anmelden und den Eintrag aus der Datei wieder löschen.

Kurze Antwort: gar nicht.

Seit ein paar Monaten bin ich stolzer Besitzer eines Servers. Auf diesem laufen verschiedene Dienste, unter anderem ein WWW, E-Mail und FTP. Eingerichtet wird alles über die Kommandozeile, eine graphische Oberfläche existiert nicht.

Wie alles begann

In den ersten Tagen stand ich einem System gegenüber, mit dem ich auf diesem Weg noch nicht gearbeitet hatte. Ein entfernter Rechner, auf dem zunächst nur eine minmale Version von Debian installiert war. Mit verschiedenen Hilfsmitteln gelang es einfach, eine Version des Betriebssystems zu installieren, die schon alles beinhaltete. Der Nachteil: Ich hatte keine Ahnung, was da alles installiert war, wie man es richtig einrichten konnte und ob ich es überhaupt brauchte.

Der Nächste Schritt war also die Neuinstallation des Systems, diesmal wieder mit einer Minimalversion von Debian. Nach und nach installierte ich die benötigten Anwendungen, bis nach einigen Tagen mein Server in der Lage war, E-Mails zu empfangen, Internetseiten darzustellen und Dateien per ftp zu übertragen. Das alles ließ sich über eine einfache Web-Oberfläche bedienen. Doch dann kam Quassel.

Sind Sie sicher, dass Sie Ihr System zerstören möchten?

Da ich an verschiedenne Orten von verschiedenen Geräten aus im Internet surfe und auch über ICQ chatte, kam ich bisher nie in den Genuss einer vollständigen Historie. Einzelne Gesprächsfetzen waren auf verschiedenen Geräten verteilt. Meldet man sich auf einem Gerät an, wird man auf dem anderen automatisch abgemeldet. Meldet man sich wieder ab, so ist man offline. Offline funktioniert der Erhalt von Nachrichten allerdings nur unzuverlässig. Also suchte ich nach einer Alternative.

Quassel ist ein IRC-Client, bestehend aus einem Server und einem Client. Der Server baut die Verbindung zum IRC-Netz auf und beliebig viele Clients können sich am Server anmelden und diese Verbindung nutzen. Mit Bitlbee wird eien Verbindung zwischen Quassel und ICQ möglich, so dass dort dasselbe Prinzip angewendet werden kann.

Es war also naheliegend, den Quassel-Server und Bitlbee auf meinem Server zu installieren. Das Problem: In den den vordefinierten Paketquellen war Quassel nicht enthalten. So suchte ich nach einer anderen Quelle, fand sie, ergänzte die Paketquellen und installierte Quassel.

Während der Installation musste ich – wie das bei Linux üblich ist – bestätigen, dass einige weitere Pakete installiert oder aktualisiert werden. “Mach du mal, du wirst schon wissen, was du tust.”

Was für mich nicht ganz klar war: Die Frage nach der Aktualisierung eines Pakets war gleichzusetzen mit der Frage “Möchten Sie dieses Paket, welches bei Ihnen schon auf dem neuesten sicheren Stand ist, durch eine Version ersetzen, die sich zurzeit in der Entwicklung befindet, wodurch Probleme auftreten könnten, zukünftige Updates immer auf dieser unsicheren Version basieren und auch andere Pakete betroffen werden können?” oder eben “Sind Sie sicher, dass Sie Ihr System zerstören möchten?”.

Wenn man keine Ahnung hat…

Jetzt weiß ich nicht, ob mir die Gelben Seiten geholfen hätten, was allerdigns geholfen hat, war jemand, der sich mit Debian auskennt.  Nach ein paar Stunden Arbeit war der Server neu aufgesetzt. Diesmal mit einem 64-Bit-System (ein weiterer Anfängerfehler…), einer vernünftigen Konfiguration – und Quassel.

Es gibt also noch viel zu lernen. Diese Erfahrung hat jedenfalls bewirkt, dass ich immer dann, wenn ich nicht weiß, was ich da eigentlich bestätigen soll, zuerst in Erfahrung bringe, welche Folgen es hat.