File über SCP kopieren mit private key authentifizierung (Host key verification failed)

  • 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.

  • 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.

    Edited once, last by theus ().

  • 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.

    Der Server A ist in diesem Fall der ssh-Client.

    Kannst Du die einmal erzeugten/generierten keys, zur Laufzeit auf den Server A kopieren/übertragen. Am PI (Server B) musst Du nichts ändern bzw. dorthin nichts übertragen, denn der kennt ja schon (von der 1. Übertragung) den pub-key des Server A (ssh-Client).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Das reicht nicht.


    Wenn Du den private key auf Server A holst, ok.


    Dann muss Server B (Raspi) trotzdem dem Schlüssel expliziert vertrauen, das geschieht über die ~/.ssh/authorized_keys

    Edit: Da wird der public key bei der ersten Verbindung reingeschrieben, nach Rückfrage! Also sollte Server A entweder einmal händisch eine Verbindung machen oder eben gleich per Hand eintragen.


    Egal wo der private key am Ende herkommt, der passende public key muss als vertrauenswürdig eingestuft/hinterlegt sein.


    Ungefähr so:

    • Server A: private key > Server B
    • Server B: kenne ich Dich? Ok, hab Dich/Deinen public key
    • Server B: Was gibts? > Server A
    • Server A: Hier ein File für Dich > Server B
  • 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?

  • Ungefähr so:

    • Server A: private key > Server B

    BTW: Der private key vom Server A (ssh-Client) muss nicht auf den Server B (sshd) übertragen werden.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • BTW: Der private key vom Server A (ssh-Client) muss nicht auf den Server B (sshd) übertragen werden.

    Ok, war vereinfacht, technisch wahrscheinlich komplizierter :)


    Hab kein passendes Flowchart der Kommunikation, Handshakes etc. gefunden, hast Du evtl. was?

  • Ja, ich habe wie gesagt den auf dem Server B erzeugten private key ...

    Wenn der Server B der sshd-server ist, dann werden die keys (private und pub) auf dem ssh-Client (hier Server A) _einmal_ generiert und nur der pub-key wird zum Server B (dein Pi mit sshd) übertragen.


    EDIT:


    Die einmal generierten keys können auf zukünftigen ssh-Clients, immer wieder benutzt/verwendet werden.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • 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

  • Es sollte eigentlich egal sein auf welchem Gerät das Schlüsselpaar erzeugt wird nehme ich an.

    Ja, es ist egal auf welchem Gerät das Schlüsselpaar erzeugt wird. Ich habe ja auch geschrieben (siehe oben), dass man das einmal erzeugte Schlüsselpaar auch auf zukünftigen ssh-Clients benutzen kann.

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

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • 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"

    Edited 2 times, last by theus ().

  • 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!

    Edited once, last by theus ().