Posts by theus

    Noch einfacher gehts mit docker-compose. Hier alles in einer docker-compose.yml:

    Wenn man einen pi mit armv7 hat kann man auch das offizielle telegraf image nehmen anstatt mik9/telegraf:armv6.

    Grafana könnte man im docker-compose.yml file leicht ergänzen.

    Starten so:

    Code
    docker-compose up -d && docker-compose logs -f

    Die beiden EZO Module laufen seit einigen Wochen im Dauerbetrieb an einem ESP32. Sehr stabil und hochpräzise wenn man gut kalibriert. Die verwendete PH Probe macht wenig Unterschied bisher - aber ich beobachte noch. Habe eine günstige PH Probe (~10€) im direkten Vergleich mit einer teuren PH Probe (60€). Die EZO Module sind zwar ein wenig teuer aber lohnt sich definitiv und scheint aktuell das beste am Markt zu sein.

    Hi malaga ,

    Ich werde mich nächstens auch an ein solche Projekt machen - brauche aber hier tatsächlich nur den ph-Wert , also keine /(zusätzliche) Temperatur.

    Für präzise PH Werte kommst du nicht drum herum auch die Wassertemperatur zu messen und als Faktor in die Berechnung des PH Werts einzuarbeiten. Zu Ungunsten der Präzision der PH Messung kann man hier auch einen Kompensationswert von ~25°C annehmen, je nach Umgebung.


    Ich habe super Erfahrungen mit den Umweltsensoren von EZO gemacht.

    Die Module können sowohl über die serielle Schnittstelle als auch über i2c angesprochen werden und im Datenblatt sind die Kalibrierungskommandos (1,2 oder 3 Punkt Kalibrierung) übersichtlich gelistet.

    Interessanterweise funktioniert der letztgenannte ssh Befehl auch endlich auf meinem Buildserver, wenn ich die Option StrictHostKeyChecking setze.

    Code
    ssh -v -o StrictHostKeyChecking=no -p ${port} -i ~/.ssh/git_key ${user}@${host} echo "payload"

    Beim äquivalenten scp Befehl mit dem selben Parameter habe ich immernoch kein Erfolg. SSH reicht mir an der Stelle jedoch. Die Datei kann ich auch als Command übertragen - von daher ist das Thema für mich erledigt. Danke für eure Hilfe!

    Der gleiche User?!

    Nein, der scp Befehl wird vom Client aufgerufen auf dem entfernten Server.

    ${user}@${host} beschreibt dabei den existierenden User (in dessen ~/.ssh/authorized_keys der pub-key steht) auf dem Zielserver (Pi). Das cat zeigt eine Ausgabe vom Server (Pi).


    Teste mal bevor Du scp benutzt, eine ssh-Verbindung mit diesem Schlüsselpaar, vom Client zum Server.

    Wenn ich eine ssh Verbindung versuche, was mir im Prinzip auch schon reichen würde, erhalte ich den selben Fehler, jedoch mit exit code 255 anstatt 1.


    Client:

    Code
    ssh -v -p ${port} -i ~/.ssh/git_key ${user}@${host} echo "hello"
    
    debug1: read_passphrase: can't open /dev/tty: No such device or address
    Host key verification failed.
    Error: Process completed with exit code 255.

    Im /var/log/auth.log des SSH Servers (Pi) finde ich dann:

    Code
    Disconnected from xxx.xxx.xxx.xxx port 14433 [preauth]
    Connection closed by xxx.xxx.xxx.xxx port 1024 [preauth]

    <- beides mal die selbe IP maskiert.



    Edit: Konkret benutztes Skript des Clients




    Edit:

    Von einem interaktiven terminal client (Git Bash für Windows) eines anderen Rechners funktioniert die exakt gleiche ssh Verbindung mit dem privaten Schlüssel, ganz ohne Passwort. Es liegt also definitiv nicht an der Konfiguration des SSH Servers.

    Code
    ssh -v -p 22 -i ~/.ssh/git_key someuser@xxx.xxx.xxx.xxx echo "hello"

    Es sollte eigentlich egal sein auf welchem Gerät das Schlüsselpaar erzeugt wird nehme ich an. Ich habe daher mal auf einem 3ten Gerät ein Keypair erzeugt ohne passwort. Den pub-key habe ich dann einmalig am SSH Server (Pi) hinterlegt in der Datei

    Code
    $ cat ~/.ssh/authorized_keys
    ssh-rsa AAA.....== user@host


    Der Client server möchte jetzt mit zugehörigem private key das file senden:

    Code
    scp -v -p ${port} -i ~/.ssh/remote_private_key ${file} ${user}@${host}:/home/${user}

    Daraus folgt immernoch:

    Code
    debug1: read_passphrase: can't open /dev/tty: No such device or address
    Host key verification failed.
    lost connection
    Error: Process completed with exit code 1.

    Ich habe soweit ich es erkenne euer Feedback beachtet. Finde im Netz vereinzelt ähnliche Fehlerbilder von anderen, z.B hier ohne Lösung: https://serverfault.com/questi…pen-dev-tty-no-such-devic

    Hi rpi444,

    richrig, der Server A soll hier der ssh-Client sein.

    Kannst Du die einmal erzeugten/generierten keys, zur Laufzeit auf den Server A kopieren/übertragen.

    Ja, ich habe wie gesagt den auf dem Server B erzeugten private key zur Laufzeit des Skripts auf Server A zur Verfügung. Du schreibst keys im Plural - muss ich also noch irgendetwas mit dem public key von Server B machen?

    Server A ist stateless, wird also für jeden Build komplett neu erzeugt. Ich könnte dort zwar zur Laufzeit Keys erzeugen, bekomme die erzeugten Keys dann aber aber ja nicht an den Pi Kommuniziert.


    Ich habe den Pi (Server B) mit Port 22 Freigabe ins Internet. sshd lauscht dort auch:


    Wenn Server A jetzt also den private key von Server B kennt, muss er doch problemlos ohne Passwortabfrage eine Verbindung aufbauen können, oder nicht? Dass Server A vertrauenswürdig ist, belegt er ja dann genau dadurch, dass er den privaten key kennt.

    Hi zusammen,

    ich erzeuge automatisiert in meiner build pipeline auf Server A eine Datei, die dann über SCP auf einen Server B (Raspberry Pi) kopiert werden soll.

    Hier eine Beschreibung meines Vorgehens, in der Hoffnung, dass jemand erkennt was ich falsch mache:


    Auf Server B erstelle ich ein keypair mit leerem Passwort:

    Code
    ssh-keygen -t rsa -b 4096

    Der Inhalt der erzeugten private key datei ~/.ssh/remote_private_key ist über ein github secret zur Laufzeit auf Server A verfügbar.

    Auf Server A wird zur Buildzeit folgendes Skript ausgeführt, um eine beliebige Datei auf Server B zu kopieren:

    Das Fehlerbild ist mit allen meinen Versuchen (1-3) das selbe:

    Hat jemand eine Idee was ich falsch mache? Habe viel gelesen und versucht, aber komme auf keinen grünen Zweig.