Aufgabe: Transportiere Daten von einem Host auf den anderen über eine ssh-Verbindung. Dafür kann man scp oder sftp verwenden, wenn der eigene Account auf der anderen Seite die Daten lesen darf:
myuser@$TRGHOST$ scp $SRCHOST:$PATH/file .
Interessanter wird das dann, wenn die Daten auf der anderen Seite vom eigenen Account nicht gelesen werden können, man also erst einmal sudo bemühen muss, um die Daten lesen zu können. An dieser Stelle versagt scp bereits - es sei denn, man kann sich auf der anderen Seite als anderer User einloggen:
Beim magentafarbenen UMTS/GPRS-Internet lautet der korrekte String für den APN "internet.t-mobile" und nicht "internet.t-mobile.de".
Trägt man den falschen APN ein, landet man in einem Netz, aus dem man surfen kann, aber sonst nichts: Außer TCP/80 und TCP/443 habe ich nichts gesehen was funktioniert hätte. Ich war schon ziemlich stinkig, wie Vendor T es wagen kann, sowas kastriertes als Internetzugang zu verkaufen, aber nach Korrektur des APN tat es dann auch mit OpenVPN, ssh und nntp.
tippt, gibt man - da man ja gerade vorher schonmal sudo gemacht hat - nur das ssh-Passwort der Gegenseite ein.
Da die Gegenseite komplett leer ist, dauert das dann eine Weile. Und weil man nach dem Ablauf des rsync sicherheitshalber den Befehl gleich nochmal absetzt, gibt man das Passwort er Gegenseite nochmal ein.
Um sich dann zu wundern, warum es nicht funktioniert.
Bis es einem dämmert, dass der Password:-Prompt gar nicht vom sshd kommt.
Sondern vom sudo.
Und man das Benutzerpasswort des lokalen Rechners braucht.
Der VLAN-Beauftragte rät: Ja, hp ProCurve Switches 2650 haben für die Dual-Personality-Ports zwei Registersätze. Und nein, es ist deswegen nicht zielführend, zuerst den Port zu konfigurieren, dann den GBIC reinzustecken und das Ding so dann zum Kunden zu shippen. Weil, mit einem Port, der untagged im Default-VLAN ist, kann der Kunde nicht so viel anfangen.
Es ist generell ratsam, wenn man schon am packen ist, und den USB-Hub schon aus dem Notebook gezogen hat, das noch
fällige Ende-Kommando an ein im Netz stehendes System nicht auf der soeben abgetrennten USB-Tastatur eintippen zu
wollen.
Außerdem ist es empfehlenswert, bei Nichtreaktion der ssh-Session nicht gleich Zeter und Mordio auf den Billighoster zu schreien, sondern erstmal zu gucken, ob das Problem nicht viel lokaler liegt.
Admintipp des Tages: Willst Du /var umounten, sieh zu, dass Du eine root-Shell offen oder das wirkliche root-Passwort parat hast. sudo wird Dich ohne /var nicht wirklich mögen, und der verbleibende Lichtblick ist der, dass Dein MTA die "security warning" ohne /var auch nicht wird verschicken können.
