Bernds Blog

Wer einen Account auf einem Server hat, dem kommt ab und zu das Verlangen, sich in der Fremde einfach mal dort einzuloggen um eine vertraute Umgebung vorzufinden. Seit es um den perfekt konfigurierten »mutt« zu benutzen, schnell im »screen« dem laufenden »irssi« zu zu schauen oder einfach um eine vorher dort hinterlegte Datei zu lesen.

Praktisch ist es natürlich gefährlich, sich von einem nicht vertrauenswürdigen Rechner auf einem Server einzuloggen. Bei der Eingabe des Passwortes auf einem fremden Rechner besteht immer die Gefahr, dass ein böswilliger Admin, ein Schäuble oder die Werbeindustrie einfach alle Tastendrücke aufzeichnet und damit sehr einfach das Passwort für den sicher geglaubten Account erhält.

Um diesem Problem generisch, also für alle fremden Rechner brauchbar zu begegnen, gibt es Einmalpasswörter. Mit diesem Verfahren (das in etwa den TANs vom PIN/TAN-Onlinebanking nahe kommt), gibt es eine Liste von Passwörtern, die jeweils nur einmal gültig sind. Sind die verbraucht, sind sie ungültig.

Unter unixoiden Systemen hat sich dafür das S/Key-System einen Namen gemacht. Es läuft auf den meisten Plattformen und lässt sich sauber z.B. mit PAM einbinden. Das Verfahren ist sehr transparent und die Einmalpasswörter lassen sich mit dem challenge, das vom Server beim Login genannt wird auch extern berechnen. So braucht man keine Papier-Liste mitnehmen sondern kann z.B. mit einem Java-fähigen Handy die Einmalpasswörter (auf einem vertrauenwürdigen Gerät) errechnen lassen.

Sehr edel das ganze, daher haben wir das auch gleich auf schokokeks.org eingebaut. Als Anleitung verweise ich hier mal auf unseren Wiki-Artikel zu Einmalpasswörtern.

Sei noch erwähnt, dass es mehrere Möglichkeiten gibt, S/Key unter SSH zu benutzen. SSH bringt eine solche Funktionalität selbst mit (Gentoo-USE-Flag skey) und es gibt alternativ dazu das PAM-Modul pam_skey.

Wir haben uns für letztere Variante entschieden, da die SSH-Lösung für den Benutzer weniger transparent ist. Bei SSH wird erst nach dem normalen Passwort gefragt und wenn dies leer oder falsch ist, dann wird nach dem S/Key-Einmalpasswort gefragt.

Bei pam_skey dagegen wird, sofern der Benutzer skey für sich aktiviert hat, gleich nach »S/Key response or system password« gefragt. Ist skey für den Benutzer nicht aktiviert, wird das PAM-Modul einfach übergangen und das normale Passwort abgefragt.

Wie vor einer Weile schon einmal schrieb, hat mein Handy (oder obexftp, keine Ahnung wer schuld ist) leider besondere Anforderungen, wie man Dateien für den OBEx-transfer spezifizieren muss.

Da ich ein Freund der Konsole bin und daher meine GPX-tracks immer mittels obexftp auf meinen Rechner kopiere, ist das doch etwas lästig.

Aber jetzt gibt es Abhilfe. ;-)

Um mir diese Aufgabe zu erleichtern, habe ich ein kleines Python-Programm erstellt, das zuerst obexftp aufruft um ein Verzeichnis-Listing zu erhalten und dann alle Dateien mittels obexftp -G herunterläd (-G bedeutet, Dateien werden auf dem Handy gelöscht).

Zur Verwendung muss zuerst das Python-Modul »ElementTree« installiert werden. Danach müssen die Bluetooth-Hardware-Adresse des Gegenüber und der OBEX-Datei-Pfad im Script eingetragen werden.

Download: obexget
Lizenz: GPL >= 3

Seit einiger Zeit habe ich ein Nokia 6230i und kann das auch per Bluetooth nutzen. Seit wenigen Tagen merke ich, dass gammu mit der Konfigurationsdatei die ich hier geklaut habe elendig langsam funktioniert. Jede Aktion dauert erstmal 2 Minuten für den Verbindungsaufbau.

Anhand der Gammu-Doku habe ich jetzt gesehen, dass mittlerweile offenbar ganz andere Namen für die selben Optionen eingeführt wurden. Nach einigen ausprobieren kam ich auf folgende Konfiguration:

[gammu]
model=6230i
port=00:17:E3:8E:FA:BC
connection=bluerfphonet
synchronizetime=no
use_locking=no
startinfo=no

Ergebnis: Der Verbindungsaufbau dauert jetzt ca. 3-4 Sekunden. nicht vollkommen perfekt aber erträglich.

Für die besserwissenden Hacker: Das Einschalten von use_locking erzeugt als User einen »permission denied«-Fehler. Das Einschalten von synchronizetime verstellt jedes mal die Uhr, da es nur Stunden und Minuten synchronisiert, nicht aber die Sekunden. Sekunden werden immer auf Null gesetzt. Nein, ich habe den Bug nicht reported.

Diese Woche erschien die neue Version der Handy-Java-Software »Mobile Trail Explorer«, Version 1.8.

Mit dieser Software und einem Bluetooth-GPS-Empfänger ist es möglich, GPS-Tracks aufzuzeichnen. Das größte manko der Vorversion war, dass die Software gelegentlich beim Speichern abstürzte (die berüchtigte "OutOfMemoryException") und damit der komplette Track weg war. man durfte also nicht vergessen, nach spätestens 500 Trackpoints zu speichern, da sonst die Datenmenge zu groß wurde.

Nicht so mit der neuen Version!!

Jetzt gibt es die Option "GPX-Stream". Dabei wird sofort begonnen, die Datei zu schreiben. Die Software schreibt Punkt für Punkt in die Datei und hält nicht einfach alles im Speicher. Dadurch gibt es keine Wartezeit und kein Speicherproblem nach Abschluß der Aufzeichnung.

Kurzanleitung:

• Menü
• Manage Trails
• Option
• New GPX stream
• Dann kommt die Frage des Telefons ob auf die Speicherkarte geschrieben werden darf
• Danach noch »Start/Stop recording«
• Nach Abschluß der Aufzeichnung (»Start/Stiop recording«) kommt der üblicher Speichern-Dialog, mit der zusätzlichen Option am Ende »Close GPX Stream«
• Der Name der resultierenden Datei beginnt mit »stream_«

Besonders erwähnenswert:
Wenn das Programm abstürzt oder versehentlich beendet wird, geht nichts verloren! Beim nächsten Start fragt das Programm ob der alte GPX-Stream fortgesetzt werden soll. tut man das nicht (»Forget about it«), hat man aber auch trotzdem noch eine Datei, bei der man nur das XML manuell schließen muss, die Punkte sind dennoch alle drin.

Noch nicht getestet habe ich, ob in diesem GPX-Stream auch die Waypoints drin sind.

Nach diesem ersten Eindruck der neuen Version: Prädikat »Absolut empfehlenswert!«

Ja, die wesentlichste Neuerung war, dass das Program OSM-Tiles als Hintergrund anzeigen kann und damit die eigene Route live visualisieren kann. Aber ohne vernünftige Daten-Flatrate und ohne schnellere Verbindung ist das für mich etwas sinnlos. Ich freu mich einfach über die neue GPX-Stream-Funktion.

Als ich mein Nokia-handy 6230i gekauft habe, konnte ich sofort und ohne die von Hanno mehrfach beklagten Probleme mit dem Programm obexftp auf Handy-Speicher und die mitgelieferte 32-MB-MMC-Karte zugreifen.

Mit Erwerb einer neuen Karte mit 1 GB (Da Nokia denkt, das Handy kann mit solchen Karten gar nicht, bieten die solche Karten erst gar nicht an), trat bei mir aber das selbe Problem auf: Ich konnte auf Daten auf der Speicherkarte nicht mehr per obexftp zugreifen.

Gestern habe ich durch Zufall die Lösung gefunden: Aus irgendwelchen Gründen schafft es das Handy mit dieser Karte nicht, den Verzeichnistrenner semantisch zu verstehen sondern will da unbedingt einen Backslash (\) haben. mit der Nokia-Karte ging auch ein normaler Slash (/).

Ich lade jetzt also mit dieser Kommandozeile meine Daten herunter:

obexftp -b 00:17:E3:8E:FA:BC -o stream_20071207_1638.gpx -G 'Speicherkarte\Tracks\stream_20071207_1638.gpx'

directory-listing geht mit

obexftp -b 00:17:E3:8E:FA:BC -l 'Speicherkarte\Tracks'

Die Besonderheit dabei: obexftp versteht den Backslash nicht als Verzeichnistrenner. So geht z.B. das da nicht:
obexftp -b 00:17:E3:8E:FA:BC -c 'Speicherkarte\Tracks' -G stream_20071207_1638.gpx

Daher das Konstrukt mit -o, da sonst die Backslashes in den Dateinamen der Zieldatei übertragen werden.

Leider beziehen sich gefühlte 99,9% aller Bluetooth-unter-Linux-Anleitungen zur Zeit auf BlueZ 2. Gentoo bietet aber im unstable-Bereich seit langem BlueZ-3-Pakete.

Da dieser Versionssprung sehr umfangreiche Änderungen mit sich bringt, funktioniert das koppeln nicht mehr anhand der bisherigen Anleitungen. Insbesondere das Eingeben der PIN ist nicht ganz trivial unter BlueZ 3.

Daher hier der entscheidende Tipp:
Zuerst wie gehabt mit hcitool scan die Hardware-Adresse des Gegenüber herausfinden. Dann mit passkey-agent 1234 00:17:E3:8E:FA:BC die PIN in Stellung bringen (1234 ist die PIN, das dahinter die Hardware-Adresse des Gegenüber).

Sobald dieses Programm wartet, kann man mit dem anderen Gerät (z.B. Handy) die Kopplung einleiten. Nach Erfolgreicher Kopplung beendet sich passkey-agent von selbst und die PIN ist für das gekoppelte Gerät gespeichert.

(Ja, es gibt 2 oder 3 Gnome-Tools, die die PIN live abfragen, aber warum sollte man Gnome-Programme installieren wenn es auch ohne geht.)

Manchmal fragt man sich doch echt: In welcher Welt leben wir eigentlich?

Mein treues, altes Siemens ME45-Mobiltelefon hat seitlich eine kleine Taste. Die Anleitung nennt dies "Diktiergerät". Man kann da draufdrücken, dann zeichnet das Gerät auf. Das geht auch während des Telefonierens. Man könnte dies "mitschneiden" nennen. Weil damals Speicher Luxus war und Luxus teuer ist, hat das Gerät leider nur ~400 KB Speicher und kann selbst in der hundsmiserablen Qualität nur etwa 2 Minuten aufzeichnen. Außer, man hat mit dem mitgelieferten PC-Anschlusskabel schon ein paar Bildchen auf das Handy geladen, dann war noch weniger Platz.

So war das früher.

Heute haben Handys mindestens einen größeren eingebauten Speicher, oft sogar einen Karten-Slot wie etwa SD-Card (1-GB-Karten sind grade ziemlich billig). Unbestritten stehen ungleich größere Speichermengen zur Verfügung.

Doch der heutige homo telefonicus schließt daraus nicht den Schluss: »Ja prima, dann kann man die Qualität ein bisschen verbessern und dennoch praktisch unbegrenzt lange Gespräche aufzeichnen« sondern der Schluss ist anders:
Man kleistert sich den Speicher mit Jamba-Sounds, Videos, Bildern und Java-Anwendungen voll (nur ~5 Euro das Stück im Abo!) und hat dann keinen Platz mehr für Telefon-Mitschnitte, wenn man sie mal braucht. Zum Glück gibt es auch da ein Geschäfts-Modell, das hilft: Eine Firma bietet einen Telefon-Mitschnitt an, der per Konferenzschaltung realisiert ist. Ein eigenes Programm (sic!) muss auf dem Handy laufen und baut dann auf Knopfdruck eine (gebührenpflichtige) Verbindung zum Big Brother Hersteller auf, der das dann als MP3 wieder per E-Mail zuschickt.

Brüller: Der Hersteller träumt davon, dass zukünftig eine separate Taste für sein Programm auf Handys angebracht wird, sodass die Bedienung noch einfacher wird. Vielleicht kann man, wenn man nicht telefoniert, das Handy mit Hilfe dieser Taste dann als Diktiergerät benutzen.

Via Golem.