Autsch - Tücken der telefonischen Fernwartung

19 July 2007
Abends installiere ich einem Kunden ein Ubuntu-System auf seinem Notebook. Alles übers Telefon: ich diktiere shell-Befehle, er gibt sie brav ein. Ich kann nicht an seinem DSL-Anschluss vor Ort sein und einen SSH-Server wollen wir auch nicht laufen lassen. 3 Abende lang geht das gut. Ubuntu läuft auf seinem Acer Notebook, verschlüsseltes Volume ist eingerichtet und seine wichtigsten Nutzerdaten (Browser, Email, ein paar Proggies) sind dort gelagert. Falls das Notebook mal verloren gehen sollte ...

Dann der letzte Tag, wir wollen seine WLAN-Karte per ndiswrapper zum Laufen bringen, also stöbern wir auf der mitgeliferten Win-Treiber-CD nach den entsprechenden .inf-Dateien. Wir installieren 5 mal die falschen Treiber, bis ich auf die Idee komme, sie einfach runterzuladen und sie ihm zu schicken. Es wird spät und die Missverständnisse und Fehler häufen sich. Jetzt blockieren die 5 falschen Treiber den letzten richtigen Treiber. Wir wollen sie entfernen/löschen und was passiert? Wir löschen aus Versehen den Inhalt seines gesamten Home-Verzeichnisses und die Daten auf der verschlüsselten Partition. ARRRRGH!

Nie wieder Fernwartung übers Telefon, nie wieder sudo in die Hände von Laien. Merke: sudo ist für roots, nicht für User.

Comments

Display comments as (Linear | Threaded)

  1. Anonymous: Ich mag rm -rf. Ich mag es ehrlich. Vor allem wenn alle Arbeiten abgeschlossen sind und man, während der Drucker druckt, der Mailer mailt, einfach mal so ein wenig aufräumen will. Natürlich als root in der shell. Warum auch nicht. Man ist ja Flachmann.

    Man ist auch ein wenig übermüdet und euphorisch zugleich. Man ist ja fertig. Fix und fertig, wenn man feststellt das der rm auf / erfolgte.

    Wie alt war nochmal die letzte Datensicherung. Aus diesem oder dem vorigen Jahrhundert?

  2. fwolf: telefonische fernwartung als solches ist schon ein totaler alptraum. mit linux gehts noch so lala - mit windows wirds zum ultimativen höllentrip.

    .. dann doch lieber SSH-server, der manuell gestartet / gestoppt werden muss PLUS VNC-verbindung (also essentiell eine verschlüsselte VNC-Verbindung via SSH-Tunnel) - ist zwar lahmarschiger, aber wenigstens löscht man keine wichtigen Daten ;-)

    cu, w0lf.

  3. Sencer: > und einen SSH-Server wollen wir auch nicht laufen lassen

    Hindsight is 20/20 - aber trotzdem, dafür sehe ich ehrlich gesagt keinen nachvollziehbaren Grund. Wenn der andere Kollege lernen will, gibt es ja screen oder script welches protokolliert/mitgucken läßt. Und ein watch finger stellt sicher, dass du dich nicht himlich mehrmals einloggs/sessions aufmachst.
    Und da einmal aufgebaute ssh-sessions nicht gestört werden, wenn man den daemon wieder stoppt, sehe ich auch keinen Grund warum man sich Sorgen machen sollte, dass fremde sich Zugriff verschaffen könnten (mal abgesehen davon, dass das halbe Internet ein Problem hätte, wenn ssh so unsicher wär...).

    Ohne ssh mach ich keinen Finger krum auf entfernten linux-kisten. ^^

  4. alp: Da wurde wohl ein cd ins richtige Verzeichnis zu wenig gemacht, dann waren die Daten futsch. Ich hab jedenfalls daraus gelernt. Dieses Wochenende will ich die Shell mit eigenen Augen sehen, wenn ich wieder alles repariere. Schließe mich Sencers letztem Satz an.


Add Comment

Comment

BBCode format allowed
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA












RSS-Feed