Da der Leidensdruck mangels aktueller Dateien auf meinem Laptop jetzt aber doch stark Richtung “Ich kann so nicht arbeiten” schnellte, habe ich in einer ruhigen Minute eine Lösung zu folgender, sich mir offenbarenden Fehlermeldung gefunden:

Fehler: Überprüfung des Server-Schlüssels fehlgeschlagen Bitte wählen Sie einen anderen Betrachter und versuchen Sie es erneut.

Soll heißen: Ubuntu glaubt, jemand würde versuchen, ihm einen geklauten oder ungültigen SSH-Schlüssel unterzujubeln.
Woher Ubuntu das weiß?

Im Verzeichnis

~/.ssh/

gibt es eine Datei, die sich

known_hosts

nennt, also so viel wie “bekannte Hauptcomputer”. Hierin legt Ubuntu bekannte Schlüssel von bereits akzeptierten Hosts ab und kann so ankommende Anfragen abgleichen.

Um das Problem nun zu lösen, habe ich besagte Datei einfach gelöscht. Umbenennen tut’s im Zweifelsfall übrigens auch.

Die Folge ist, dass Ubuntu beim nächsten Verbindungsversuch, z.B. auf ssh://user123@192.168.1.42:443/ über Nautilus, den Benutzer darum bittet, den unbekannten Schlüssel zu akzeptieren (oder abzulehnen). Ist das Akzeptieren vertrauensvoll geschehen, läuft wieder alles wie am Schnürchen.

Jetzt stellte sich mir noch die Frage nach dem “Warum”, zumal bislang alles sauber funktionierte.

Kurzfassung:
Zu verdanken habe ich diesen Umstand offenbar meinem Router, der DHCP-Einstellung meines Fileservers und einem weiteren Laptop.

Aber langsam:
Bislang hörte der Fileserver auf eine IP-Adresse mit der Endziffer 20, der Rest der Rechner reihte sich dann per DCHP artig dahinter ein. Über die DCHP-Einstellung auf dem Fileserver (Debian) war die “20″ fest in der dhclient.conf verdrahtet, so dass trotz abgelaufener Lease-Time immer wieder die “20″ an ihn vergeben wurde.

Offenbar überschnitt sich aber in den letzten Tagen die Lease-Time des Fileservers mit einem Bootvorgang des oben genannten Laptops, der daraufhin die “20″ als IP-Adresse abstaubte, nun von meinen Sync-Tools  belästigt wurde, diesen aber die kalte Schulter zeigte.
Der Fileserver indes begnügte sich nach dem nächsten, allmorgendlichen Bootvorgang mit der “33″ (da die “20″ ja nun belegt war), was jedoch die gesamte IP-Adress-Landschaft in meinem kleinen Netzwerk durcheinander warf (ich nutze keinen DNS-Server…wäre wohl mal angebracht).

Die Erklärung:
Nachdem ich im Router-Log die IP-Adresse mit der Endziffer “33″ dem Fileserver zuordnen konnte, versuchte ich einen SSH-Connect auf diese Adresse – und scheiterte kläglich – eben weil Ubuntu wohl dachte, jemand wolle ihm da etwas unterschieben…