Donnerstag, 22. September 2016

Mac OS Sierra und SSH

Mit dem Sierra Update von Mac OS unterstützt SSH  keine DSA Schlüssel mehr. Das hat zur Folge, dass die Authentifizierung mit diesen Schlüsseln nicht mehr funktioniert und man nach dem Passwort gefragt wird, oder die Authentifizierung scheitert, wenn der Server keine Passworte akzeptiert.

Auf jeden Fall sollten alle DSA Schlüssel durch RSA Schlüssel ersetzt und die neuen PubKeys dann auf dem Server installiert werden.

Um eine Verbindung mit den nun nicht mehr unterstützen Schlüsseln aufbauen zu können, reicht es in der Kommandozeile den Algorithmus zu erlauben.

ssh -o PubkeyAcceptedKeyTypes=+ssh-dss usern@example.com

So kann eine SSH Sitzung mit den alten Schlüsseln aufgebaut werden. Diese Sitzung kann man verwenden, um die neuen Schlüssel in die authorized_keys einzutragen.

Sonntag, 3. Januar 2016

Owncloud Kalender und Kontakte migrieren

Die Migration von Kalendereinträgen und Kontakten zwischen einem alten und einem neuen Owncloud Server oder zwischen inkompatiblen Versionen in meinem Fall von 7.0 nach 8.2.2 ist einfacher, als es sich nach einer einfachen Googlesuche darstellt. 
In meinem Fall versagte das occ Upgrade Utility und ich konnte den Server nicht upgraden.
Hier eine kurze Beschreibung, wie der Transfer von wenigen Personen einfach und schnell durchgeführt werden kann.
Die folgenden Schritte haben bei mir funktioniert:

  1. Export
    Sowohl an den Kalender CalDAV Link (verborgen hinter dem Kettensymbol), als auch bei dem CardDAV Link der Kontakte kann ?export angehängt werden. Den CardDAV Link findet man im Settingsmenü der Kontakte (Zahnradsymbol unten in der ersten Spalte) ebenfalls hinter dem Kettensymbol.
  2. Jeweils einen der Links in die Adresszeile des Browsers kopieren und ?export ohne Leerzeichen hinter den kopierten Link schreiben und die Seite aufrufen.
  3. Es wird jeweils eine Datei heruntergeladen. In der .ics Datei befinden sich alle Kalendereinträge in der .vcf Datei alle Kontakte.
  4. Für die Kontakte verwendet man die Importfunktion, die sich ebenfalls hinter dem Zahnradsymbol im Settingsmenü der Kontakte befindet. Nach dem Hochladen der .vcf Datei dauert es eine ganze Weile bis der Fortschrittsbalken etwas anzeigt, also Geduld.
  5. Bei den Kalenderdaten ist die Import Funktion nicht so offensichtlich. Die .ics Datei in den Dateibereich des Owncloud Servers hochladen. Der Server zeigt dann für die Datei ein Kalendersymbol. Wählt man jetzt die Datei aus beginnt der Importprozess. Auch dieser erscheint eine Weile regungslos, so dass man Bedenken hat, der Prozess sei abgestürzt, auch hier braucht man Geduld.
Das wars auch schon. Das Verfahren hat bei meinen 10 Benutzern gut funktioniert.

Freitag, 6. März 2015

RS-232 mit Java und Mac OS Yosemite

Auch wenn die serielle Kommunikation über RS-232 aus der Mode ist, gibt es immer noch eine Reihe von Geräten, die sich darüber einfach steuern lassen. Um eine serielle Kommunikation über Java zu ermöglichen wird seit Jahren die RXTX Library verwendet. 
Die Mac OS Binaries die auf der Homepage angeboten werden sind leider i386 Binaries, also etwas aus der Mode. Für alle Besitzer eines 64Bit System bleibt nur der Weg die Bibliothek selbst zu kompilieren und Java zur Verfügung zu stellen.

Da dies mit einigen Hürden verbunden hoffe ich, dass die folgenden Schritten anderen Fans der seriellen Kommunikation mit Java ein paar Minuten sparen.

Die folgenden Schritte sind notwendig:
  1. Xcode installieren.
  2. Aktuelles JDK installieren. Ich verwende JDK 1.8_40.
  3. Einen Shell Export für JAVA_HOME erstellen mit: export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home
  4. Macports installieren.
  5. Mit dem Kommando sudo /opt/local/bin/port install libtool glibtool installieren.
  6. RXTX Source Package herunterladen und entpacken.
  7. Im Ordner in dem das RXTX ZIP entpackt worden ist  das Kommando ./configure ausführen.
  8. Im Makefile müssen ein paar Anpassungen durchgeführt werden:
    die Zeile:
    LIBTOOLC = $(GLIBTOOL) --mode=compile $(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(VERBOSE_IOEXCEPTIONS) -c
    muss durch die Zeile:
    LIBTOOLC = $(GLIBTOOL) --tag=CC --mode=compile $(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(VERBOSE_IOEXCEPTIONS) -c
    ersetzt werden.
    Die Zeile:
    JAVAINCLUDEDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/../../../Headers
    muss durch die Zeile:
    JAVAINCLUDEDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/include
    ersetzt werden.
    Jetzt muss noch die Zeile:
    JAVANATINC = -I$(JAVAINCLUDEDIR)/
    durch:
    JAVANATINC = -I$(JAVAINCLUDEDIR)/darwin
    ersetzt werden.
  9. mit dem Kommando make wird der Buildprozess gestartet an dessen Ende zwei relevante Dateien erzeugt worden sind.
  10. In dem Ordner in dem das make Kommando ausgeführt worden ist befindet sich die Datei RXTXcomm.jar.  Im Unterordner i686-apple-darwin14.1.0 befindet sich die Datei librxtxSerial.jnilib
  11. Beide Dateien müssen in den Ordner /Library/Java/Extensions kopiert werden und das Setup ist komplett.
Ich hoffe das es euch hilft.

Dienstag, 6. Januar 2015

Grails 2.x Debugging in Netbeans

Wenn man eine Grails Applikation in Netbeans 8 erstellt und diese mit dem Debugger bearbeiten möchte stellt man fest, dass das nicht geht.
Der Debugger startet zwar und die Oberfläche stellt sich so dar als ob man die Applikation debuggen könnte, allerdings spricht keiner der gesetzten Breakpoints an.

Wenn man in die BuildConfig.groovy schaut stellt man fest, das in allen Forkkonfigurationen debugging disabled ist.

grails.project.fork = [
    // configure settings for compilation JVM, note ...      

    //  compile: [maxMemory: 256, minMemory: 64, de ...

    // configure settings for the test-app JVM, ...
    test: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256, daemon:true],
    // configure settings for the run-app JVM
    run: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256, forkReserve:false],   
    // configure settings for the run-war JVM
    war: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256, forkReserve:false],
    // configure settings for the Console UI JVM
    console: [maxMemory: 768, minMemory: 64,
debug: false, maxPerm: 256]
]



Die naheliegendste Änderung wäre es, true statt false in die BuildConfig.groovy einzutragen. Leider ist das nicht wirklich gut umgesetzt. Der Debugger startet zwar, verbindet sich aber nicht automatisch mit der geforkten JVM.
Der Debugger kann nachträglich attached (localhost:5005) werden und arbeitet dann korrekt. Dieses Vorgehen benötigt aber immer den Schritt des nachträglichen Verbindens mit der JVM.


Die komfortabelste Methode ist es den Fork zu deaktivieren. Dann erhält Netbeans die Kontrolle und die Gralsapplikation verhält sich wie jede andere Applikation in Netbeans.

Zum Deaktivieren des Forks die Zeile:

run: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, forkReserve:false],   

durch:

run: false,   

ersetzen.

Danach kann einfach über das Kontextmenü eine Debugsession gestartet werden.

Samstag, 28. Juni 2014

pyotherside für Jolla

Für alle die kein C++ können, aber trotzdem mehr wollen als sich mit Javascript realisieren lässt, ist pyotherside eine gute Erweiterung der Möglichkeiten von QtQuick.

pyotherside ist ein QML Objekt, mit dem sich in direkt QML Python Code embedden und ausführen lässt. Da pyotherside vom Jolla Harbour akzeptiert wird können Apps in Python entwickelt und in den Harbour deployed werden.
Wenigstens äußert sich das MER Wiki dahingehend optimistisch.

Die Verwendung von pyotherside ist denkbar einfach. pyotherside gehört zwar nicht zum Standardumfang eines Jolla Telefons, is aber in den offiziellen Repositories enthalten.

Um bei der Installation der eigenen App sicherzustellen, das pyotherside auf dem Jolla mit installiert wird, muss das Paket in die Liste der von der Software benötigten Pakete eingetragen werden.

Durch diesen Eintrag wird sichergestellt, dass während der Installation des RPMs das pyotherside Package automatisch mit installiert wird,

In der Datei <projektname>.yaml im Abschnitt Requires muss der Eintrag:

... 
# Build dependencies without a pkgconfig setup can be listed here
# PkgBR:
#   - package-needed-to-build

# Runtime dependencies which are not automatically detected
Requires:
  - sailfishsilica-qt5 >= 0.10.9

  - pyotherside-qml-plugin-python3-qt5 >= 1.2.0

# All installed files
Files:
  - '%{_bindir}'

...


eingefügt werden.

In der QML Datei reicht das Hinzufügen einer import Anweisung, um Python in QML verfügbar zu machen:

    import io.thp.pyotherside 1.2

Der Python Code selbst wird mit einer nach dem Import verfügbaren Python Componenten in das QML embedded.

Ein einfaches Kochbuch mit den notwendigsten Anweisungen zur Erstellung von Apps mit Python findet man hier.

Sonntag, 29. Dezember 2013

Jolla - SailfishOS einfacher Konfigurationsspeicher für QtQuick/QML Apps

Die meisten Apps müssen Konfigurationsdaten wie Servernamen oder Benutzerpräferenzen speichern. Diese Daten sollten von jeder Stelle der App zugreifbar sein, um sich die Übergabe von langen Parameterlisten sparen zu können. Natürlich muss die Speicherung persistent erfolgen, so dass die Konfiguration nicht nach dem Beenden der Applikation verloren geht.

Mein Ansatz besteht aus einem kleinen Javascript, das in alle QML Dateien importiert werden kann und die Daten in einer Datenbank speichert.

Vor dem ersten Start muss der Platzhalter <your app name> durch den Namen der jeweiligen Applikation ersetzt werden.

Die Funktion intialize() muss beim start der App aufgerufen werden. Danach kann mit getSetting() und setSetting() ein Key/Value Pair in der DB gespeichert werden.

Javascript:

Qt.include("QtQuick.LocalStorage")

function getDatabase() {
     return LocalStorage.openDatabaseSync("<your app name>", "1.0",  

            "StorageDatabase", 100000);
}

function initialize() {
    var db = getDatabase();
    db.transaction(
        function(tx) {
            tx.executeSql('CREATE TABLE IF NOT EXISTS'+

                   ' settings(setting TEXT UNIQUE, value TEXT)');
      });
}


function setSetting(setting, value) {
   var db = getDatabase();
   var res = "";
   db.transaction(function(tx) {
        var rs = tx.executeSql('INSERT OR REPLACE INTO settings'+

                       ' VALUES (?,?);', [setting,value]);
        if (rs.rowsAffected > 0) {
            res = "OK";
        } else {
            res = "NOK";
        }
   });
   return res;
}

function getSetting(setting) {
   var db = getDatabase();
   var res="";
   db.transaction(function(tx) {
     var rs = tx.executeSql('SELECT value FROM settings WHERE'+

                        ' setting=?;', [setting]);
     if (rs.rows.length > 0) {
          res = rs.rows.item(0).value;
     } else {
         res = "";
     }
  });
  return res;
}


Ein dazu passender QML Preferences Dialog könnte dann so aussehen:
import QtQuick 2.0
import Sailfish.Silica 1.0
import QtQuick.LocalStorage 2.0
import "storage.js" as Storage


Dialog {
    id: preferencePage
    DialogHeader { title: "Save" }
    anchors.fill: parent

        TextField {
            y:200
            id:serverName
            width: parent.width
            label: "Server URL"
            placeholderText: "Enter Sever Name"
            focus: true
            horizontalAlignment: left
        }

        TextField {
            id:deviceId
            anchors.top:serverName.bottom
            width: parent.width
            label: "REMSY Device Name"
            placeholderText: "Enter Device Name"
            focus: true
            horizontalAlignment: left
        }


    Component.onCompleted: {
        Storage.initialize();
        serverName.text=Storage.getSetting("serverurl");
        deviceId.text=Storage.getSetting("deviceid");
    }
    onAccepted: {
        Storage.setSetting("serverurl", serverName.text)
        Storage.setSetting("deviceid", deviceId.text)
    }
}

 

Dienstag, 2. Juli 2013

ePass 2003 Token für OpenVPN Tunnel einrichten

Der französische Anbieter gooze bietet die kostengünstigen und Open Source kompatiblen Smartcard Systeme des chinesischen Herstellers Feitian an. Die Smartcards und Tokens sind vergleichsweise preiswert und enthalten nicht die üblichen Abos, NDAs und andere Hürden, die einem bei anderen Anbietern für einen einfachen Einsatz im Weg stehen.

Darüberhinaus ist die Lieferung relativ schnell, wenn die Smartcards nicht irritierenderweise beim Zoll festsitzen oder die Lieferung aus China sich verspätet.

Das Token ePass2003 ist ein USB-Stick mit integrierter Smartcard und  Kartenleser. Die Einrichtung des Tokens für die Verwendung mit opnevpn unter Mint 14 LMDE ist wird im Folgenden beschrieben.

Die aktuellen Debian Distributionen enthalten nicht die aktuellsten OpenSC Treiber. Auch wenn der Sicherheitsimpact abgewägt werden muss habe ich mich entscheiden das Repository von Gooze zu verwenden um passende und geprüfte OpenSC Pakete zu bekommen.

Um dies zu erreichen muss das Repository von Gooze der sources.list hinzugefügt werden. Da Mint 14 im Wesentlichen auf debian Wheezy basiert, wird das Wheezy Repo der sources.list hinzugefügt.

Als erstes müssen diese zwei Zeilen der Datei /etc/apt/sources.list hinzugefügt werden:

deb http://apt.gooze.eu/debian/ wheezy main
deb-src http://apt.gooze.eu/debian/ wheezy main 

Mit:

# wget -q "http://apt.gooze.eu/257FF7B2.asc" -O- | sudo apt-key add -

wird der Schlüssel für die Gooze Packages dem Keyring hinzugefügt.
Im Ordner /etc/apt/preferences.d/ die Datei gooze mit folgendem Inhalt anlegen:

Package: *
Pin: origin o=apt.gooze.eu
Pin-Priority: 1001 


Nach der Ausführung von apt-get update können alle notwendigen Pakete mit der Anweisung:

# apt-get install pcscd pcsc-tools libccid libpcsclite1 openvpn opensc/staging

installiert werden.

Das ePass2003 ist im Auslieferungszustand für die Feitian Windows-Treiber vorbereitet. Das verhindert die korrekte Erkennung unter Linux. Um das Token unter Linux "sichtbar" zu machen muss das Token neu initialisiert werden.

Während der Initialisierung werden die PIN und die PUK (SuperPIN) vereinbart, sowie ein Label, das verschiedene Programme bei der Nachfrage nach der PIN als Text verwenden.


$ pkcs15-init -E
$ pkcs15-init --create-pkcs15 --profile pkcs15+onepin \
    --use-default-transport-key --pin 123456 \
    --puk 7891011 --label "Peter Mustermann"


Ist die Initialisierung erfolgreich sollte die Anweisung:

$ pkcs15-tool --dump

ungefähr die folgende Ausgabe liefern.

PKCS#15 Card [Peter Mustermann]:
    Version        : 0
    Serial number  : 1234567890091101
    Manufacturer ID: EnterSafe
    Last update    : 20120630083313Z
    Flags          : EID compliant

PIN [User PIN]
    Object Flags   : [0x3], private, modifiable
    ID             : 01
    Flags          : [0x32], local, initialized, needs-padding
    Length         : min_len:4, max_len:16, stored_len:16
    Pad char       : 0x00
    Reference      : 1 (0x01)
    Type           : ascii-numeric
    Path           : 3f005015

...


Damit ist das Token betriebsbereit und kann mit Schlüsseln und Zertifikaten bespielt werden.

Wie man sich einen Schlüssel und ein Zertifikat für SSL erstellt ist erschöpfend im Netz beschrieben, weswegen ich diesen Punkt überspringe und davon ausgehe, das sich der Leser im Besitz einer gültigen PKCS#12 (.p12) Datei befindet.

Mit den Anweisungen:

$ openssl pkcs12 -in cert.p12 -clcerts -nokeys -out petercert.pem
$ openssl pkcs12 -in cert.p12 -cacerts -nokeys -out root.pem
$ openssl pkcs12 -in cert.p12 -nocerts -out peterkey.pem


werden die notwendigen Dateien aus der PKCS#12 Datei extrahiert.

Mit:

$ pkcs15-init --store-private-key peterkey.pem --auth-id 01 --pin 123456

wird der Schlüssel auf dem Token gespeichert. Während dieser Prozedur wird dem Schlüssel eine ID zugewiesen die ausgelesen werden muss, um das Zertifikat mit diesem Schlüssel zu assoziieren.

$ pkcs15-tool --list-keys

Listet alle Schlüssel des Tokens mit deren Ids:

Using reader with a card: Feitian ePass2003 00 00
Private RSA Key [Certificate]
    Object Flags   : [0x3], private, modifiable
    Usage          : [0x4], sign
    Access Flags   : [0xD], sensitive, alwaysSensitive, neverExtrac
    ModLength      : 2048
    Key ref        : 0 (0x0)
    Native         : yes
    Path           : 3f0050152900
    Auth ID        : 01
    ID             : 012347050ef750567872b7e7aa80539110b0e921
    GUID           : {0abc494d-2712-32dc-b64d-be218b23ce90}


Die ID muss beim Speichern des Zertifikates angegeben werde:

# pkcs15-init --store-certificate petercert.pem --auth-id 01 \
   --id  012347050ef750567872b7e7aa80539110b0e921 --format pem


Das Token ist jetzt vollständig eingerichtet.

Um das Token für openvpn nutzbar zu machen muss eine Client Konfiguration im Ordner /etc/openvpn angelegt werden. Openvpn erzeugt seine eigenen IDs mit denen es Schlüssel auf dem Token identifiziert. Diese ID wird mit:

# openvpn --show-pkcs11-ids /usr/lib/opensc-pkcs11.so

ausgelesen und sieht ungefähr so aus:

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Certificate
       DN:             /C=DE/ST=Berlin/L=Berlin/O=Foobar GmbH/OU=FooSecurity/CN=Peter Mustermann
       Serial:         09
       Serialized id:  EnterSafe/PKCS\x2315/6257011116091101/Peter\x20Mustermann\x20\x28User\x20PIN\x29/0
012347050ef750567872b7e7aa80539110b0e9211


Der gelb markierte Hinweis ist unbedingt zu beachten, da ansonsten die \ Zeichen falsch interpretiert und das Zeritifkat nicht mehr zugeordnet werden kann.

Eine minimale /etc/openvpn/client.conf könnte dann so aussehen, wobei hierzu unbedingt die Dokumentation der OpenVPN Website konsultiert werden sollte.
Außerdem hängt der Inhalt der Datei von den Einstellungen ab, die auf der Serverseite durchgeführt worden sind. Für einen einfachen minimalen Test reicht das angegebene Beispiel in jedoch aus.

client
dev tun
proto udp
remote vpn.foobar.com
nobind
persist-key
persist-tun
ca /etc/openvpn/certs/foobar-ca.cert
pkcs11-providers /usr/lib/opensc-pkcs11.so
pkcs11-id '
EnterSafe/PKCS\x2315/6257011116091101/Peter\x20Mustermann\x20\x28User\x20PIN\x29/0012347050ef750567872b7e7aa80539110b0e9211'
comp-lzo


Mit der Anweisung:

# openvpn --config /etc/openvpn/vpn.sourcepark.biz --verb 2

beginnt der Aufbau der Tunnelverbindung. Sobald der Server kontaktiert wurde und der SSL Handshake begonnen hat wird die PIN abgefragt. Nach Eingabe der korrekten PIN wird die Tunnelverbindung etabliert und kann verwendet werden.

Das Erstellen der Zertifikate und die korrekte Verwendung verlangen etwas Übung. Sollte das Token nicht wie gewünscht arbeiten, kann man den Tunnel testweise nur mit den Zertifikaten aufbauen, und anschlie0end die geprüften Zertifkate auf das Token übertragen.

Eine OpenVPN Client Konfiguration, die mit der Zertifkats- und Schlüsseldatei arbeitet würde so aussehen:

client
dev tun
proto udp
remote vpn.foobar.com
nobind
persist-key
persist-tun
ca /etc/openvpn/certs/foobar-ca.cert
cert /etc/openvpn/certs/petercert.pem
key /etc/openvpn/private/peterkey.pem
comp-lzo

Kann mit dieser Konfiguration kein Tunnel etabliert werden liegt es an den Zertifikaten. Lässt sich mit der Angegebenen Konfiguration ein Tunnel aufbauen, arbeitet der Treiber oder das Token nicht korrekt.