UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Pedder007]

Hallo zusammen,
ich stricke nun schon 2 Abende an einem SSH Problem und bekomme es einfach nicht hin.

Also:
Ich löse im bestehenden Setup von meinem ioBroker Master auf meinem ioBroker Slave (mit Motioneye) ein Script aus, welches mir die Config-Files der Kameras umkopiert. In Blockly gibt es bei mir dazu ein: ssh pi@192.168.xxx.xxx /etc/motioneye/motionmailon.sh

Nun versuche ich meine Slaves auf einem MiniPC in Proxmox unter zu bringen und diese Funktion wieder zu etablieren.
Das Anlegen der Keys hat soweit auch alles sauber geklappt und ein Login per ssh funktioniert entsprechend auch von der ioBroker Master Konsole ohne PW-Eingabe auf dem Proxmox Motioneye-Server.

Versuche ich aber mit dem ssh direkt oben angegebenes Script auszulösen, bekomme ich immer ein:
'sudo: no tty present and no askpass program specified' zurück.

ssh -t .... führt dazu, dass ich wieder nach dem PW gefragt werde, kann ich so also nicht gebrauchen.

Ich habe dann zusätzlich auf dem Server in die 'sudoers' noch ein:
'pi ALL = NOPASSWD: /etc/motioneye/motionmailon.sh' spendiert, was aber auch nichts bringt.

ein: ssh -v .... , sagt Folgendes:

pi@raspberrypi:~ $ ssh -v pi@192.168.xxx.xxx /etc/motioneye/motionmailon.sh
OpenSSH_8.4p1 Raspbian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type 0
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_dsa type -1
debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa type -1
debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519 type -1
debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_xmss type -1
debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Raspbian-5+deb11u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.xxx.xxx:22 as 'pi'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Host '192.168.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /home/pi/.ssh/known_hosts:4
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/pi/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Will attempt key: /home/pi/.ssh/id_dsa 
debug1: Will attempt key: /home/pi/.ssh/id_ecdsa 
debug1: Will attempt key: /home/pi/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/pi/.ssh/id_ed25519 
debug1: Will attempt key: /home/pi/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/pi/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/pi/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Server accepts key: /home/pi/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.xxx.xxx ([192.168.xxx.xxx]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/pi/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/pi/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug1: Sending env LC_ALL = de_DE.UTF-8
debug1: Sending command: /etc/motioneye/motionmailon.sh
bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2932, received 3964 bytes, in 0.2 seconds
Bytes per second: sent 16647.6, received 22507.3
debug1: Exit status 1

Ich denke das evtl. die letzten Zeilen mir etwas sagen sollten, kann diese aber mit meinen rudimentären Linux-Kenntnissen nicht deuten.

Entsprechende Bitte um Unterstützung

Edit: und natürlich gehört der User pi auf dem Zielsystem der Gruppe sudo an

[wendy2702]

@pedder007 Mal google bemüht?

Gibt ja etliche Treffer mit Lösungen.

[Pedder007]

Hi @wendy2702, ja seit zwei Abenden.
Habe mir bei dem ganzen 'Gebastel' schon 2-3 mal meine Konfiguration wieder aus dem BackUp geholt um wieder einen definierten Stand zu haben ...
Das Problem ist, dass es da 100derte Infos zu gibt, die bisher alle nicht zum Erfolg geführt haben. Das oben ist mein aktueller Stand.

[Thomas Braun]

@pedder007

Mal mit

sudo -n

probiert?

[wendy2702]

@pedder007 Das fällt mir auf:

debug1: Sending env LC_ALL = de_DE.UTF-8
debug1: Sending command: /etc/motioneye/motionmailon.sh
bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)

Wie sieht das Script aus? Bin verwundert das da kein „.“ vor dem Pfad steht, habe aber auch schon ewig nicht mehr remote ein Script ausgeführt.

Sind auf beiden Systemen dieselben env definiert?

Mal geschaut wie das bei dem funktionierenden aussieht?

[OliverIO]

@pedder007 sagte in SSH Problem: sudo: no tty present and no askpass program....:

Ich habe dann zusätzlich auf dem Server in die 'sudoers' noch ein:
'pi ALL = NOPASSWD: /etc/motioneye/motionmailon.sh' spendiert, was aber auch nichts bringt.

hast du das mit

sudo visudo

aufgerufen?
das prüft ob die datei inhaltlich korrekt ist, da man sich da sein ganzes system zerschießen kann.

was passiert wenn du dich manuell per ssh dort einwählst?
als ssh direkt von der komandozeile aus. am besten gleich als user iobroker

sudo -u iobroker bash

und dann zunächst mit ssh eine session auf dem anderen rechner aufmachen, aber ohne angabe des skripts
und dann wenn die shell offen ist dann versuchen das skript aufzurufen.
ggfs kommen da nochmal bessere fehlermeldungen

[Pedder007]

@thomas-braun said in SSH Problem: sudo: no tty present and no askpass program....:
Mal mit

sudo -n

probiert?

Meine Güte @Thomas-Braun das war's
.... und ich könnte fast dafür wetten, dass ich das auch schonmal als Option mit dazwischen hatte, aber evtl. war das noch ohne:
'pi ALL = NOPASSWD: /etc/motioneye/motionmailon.sh'
Was ich allerdings eben (bei paralleler weiterer Recherche) noch in
'pi ALL = (ALL) NOPASSWD: ALL' umgewandelt hatte,

@wendy2702, ja hatte auch alles mögliche schon Quergeschaut, bis in die Pass-Keys hinein

@OliverIO 'visudo' yep, das findet man ja dann alles wenn man recherchiert ...
Bzgl. des Restes, dass hatte dann funktioniert, wie gesagt, ssh Login (ohne Script) ohne PW ging ja schon sauber

You all made my Day - 1000 Dank!!!

[Pedder007]

Tja, da komme ich leider doch nochmal zurück.
Das ganze funktioniert aktuell nur von der Konsole aus, aber nicht als 'Exec' Blockly.

Ich habe den Textbaustein gerade sogar vom Blockly in die Console kopiert um Tippfehler auszuschließen, aber daran liegts nicht.

Zusätzlich habe das sudo -n auch gerade noch zusätzlich in mein bestehendes Setup eingefügt (im Screenshoot deaktiviert) und das macht dort keinen Unterschied, heißt klappt mit und ohne.

[OliverIO]

@pedder007 sagte in SSH Problem: sudo: no tty present and no askpas....:

pi ALL = (ALL) NOPASSWD: ALL

ich bin mit dem syntax nicht ganz vertraut, aber welchen user hast du den verwendet zum ausprobieren?
pi?

der iobroker arbeitet mit user iobroker, also musst du den ssh-key auch für iobroker kopieren und auf dem entfernten rechner auch iobroker berechtigen.

deswegen habe ich oben geschrieben

sudo -u iobroker bash

damit machst du eine shell auf als user iobroker und kannst auf der konsole alles in ruhe austüfteln, so als ob der iobroker das selber wäre

[Thomas Braun]

@pedder007 sagte in SSH Problem: sudo: no tty present and no askpas....:

Das ganze funktioniert aktuell nur von der Konsole aus

Auch als User 'iobroker'?

Setz mal vor den ssh-Befehl noch ein

sudo -H -u iobroker

[OliverIO]

@thomas-braun sagte in SSH Problem: sudo: no tty present and no askpas....:

Setz mal vor den ssh-Befehl noch ein

ne, der aufruf erfolgt ja schon als user iobroker.
bin mir sicher, das er alles gemacht hat um seinen normal user pi zu berechtigen

[Thomas Braun]

@oliverio sagte in SSH Problem: sudo: no tty present and no askpas....:

ne, der aufruf erfolgt ja schon als user iobroker.

Richtig, aber es funktioniert ja nicht. Deswegen Meldungen provozieren.

ssh pi@irgendwas

von einem anderen User aus aufgerufen durfte die Keys nicht mitschleifen, sonst könntest du ja auf ganz billige Tour die Rechte kapern.

[Pedder007]

@oliverio @Thomas-Braun

Ja, der user pi ist auf dem Zielsystem definitiv berechtigt, sonst würde das ja nicht von der Console des ioBrokers Raspis aus gehen.
Das hatte ich im bestehenden Setup auch genauso gemacht -> siehe deaktivierter SSH Befehl.

Und der neue Motioneye (im Container) ist ja auch bereits ein 'verdrahteter' Slave.

Muss denn der user iobroker, wegen Ausführung aus einem Blockly, definitiv auch berechtigter User auf dem Zielsystem sein?
Ich dachte das es reicht, wenn das der im SSH genutzte User ist.

Noch gerade nachgeschaut:
Auf dem Bestandssystem hat der user iobroker keine abgelegten SSH Keys, es gibt gar kein /home/iobroker/.ssh

Entsprechend, wie gesagt, da mache ich das nur über den user pi.

[Thomas Braun]

@pedder007

Der iobroker ist ja auch ein Systemuser und über die sudoers in den Möglichkeiten eingeschränkt.

[OliverIO]

@pedder007

also du prüfst als erstes, ob du im folgenden verzeichnis einen public key findest

/homer/iobroker/.ssh/id_rsa.pub

wenn nein, dann musst du für den iobroker ein schlüsselpaar erzeugen.

sudo -u iobroker ssh-keygen -t rsa -b 4096 

wenn der public key vorhanden ist, dann mit folgendem befehl auf den anderen rechner kopieren

sudo -u iobroker ssh-copy-id -i ~/.ssh/id_rsa.pub pi@192.168.xxx.xxx

dann kann der ssh auf der empfängerseite den iobroker authentifizierenm wenn er sich als pi auf dem anderen rechner anmeldet.

da du wahrscheinlich aktuell den pub.key im lokalen pi verzeichnis hast, kann der user iobroker da auch nicht drauf zugreifen bzw. weiß gar nicht warum, da der lokale pi und der entfernte pi was komplett verschiedenes ist.

details dazu
https://wiki.ubuntuusers.de/SSH/#Publickey-Authentifizierung

[Pedder007]

@oliverio

Das hatte ich ja gerade geprüft und in dem Bestands-Setup gibt es auf dem Zielsystem beim User iobroker keinen Key und das funktioniert ja trotzdem. Ich hatte das ja oben schonmal gefragt, ob der User iobroker auch einen Key benötigt, um das sauber aus Blockly ausführen zu können.

Egal, ich werde das ausprobieren und dann mit dem User iobroker versuchen aus dem Blockly zu SSH'en.
Aber nicht mehr heute, gestern war's schon viel zu spät

Der Mechanismus wie der Key angelegt und übertragen wird, ist mir ja bekannt, sonst würde das ja von der Console aus nicht funktionieren Wie auch schon gesagt, habe ja schon eine Menge recherchiert ...

Danke nochmal und ich melde mich morgen wieder, wie der Test verlaufen ist.

Edit:
Den hier fand' ich speziell zu dem Thema auch gut:
https://www.ssh.com/academy/ssh/copy-id#troubleshooting

[OliverIO]

@pedder007 sagte in SSH Problem: sudo: no tty present and no askpas....:

Das hatte ich ja gerade geprüft und in dem Bestands-Setup gibt es auf dem Zielsystem beim User

Auf dem iobroker rechner sollst du prüfen nur dort sollte es ein home verzeichnis für iobroker geben

ein evtl vorhandener user iobroker auf dem zielsysystem interessiert nicht, da du dich ja mit pi@... anmelden willst

[Pedder007]

@oliverio
Da gibt's natürlich einen Key für pi, klaro.
Den habe habe ich ja dann mit ssh-copy-id aufs Zielsystem befördert.

Edit:
Für iobroker finde ich ein home/iobroker/.ssh
Das gehört iobroker und da komme ich sogar mit sudo als pi gar nicht rein !?

[OliverIO]

@pedder007

auf dem zielsystem im verzeichnis /home/pi/.ssh
in der datei authorized_keys steht dann der kopierte pub key drin.
ist das der vom user pi oder vom user iobroker auf deinem iobroker system?

ich tippe auf den vom user pi

[OliverIO]

@pedder007 sagte in SSH Problem: sudo: no tty present and no askpas....:

Das gehört iobroker und da komme ich sogar mit sudo als pi gar nicht rein !?

korrekt, da steht auch der private key drin und den sollte wirklich niemand sehen. also root natürlich schon.

aber bevor es kompliziert wird. führe die befehle oben so aus wie ich geschrieben habe. dann bin ich mir sicher das es funktionieren wird ohne das du dein skript anpassen musst.
es hängt nur daran, das der user iobroker (mit dem blockly und dein skript ausgeführt wird) auf dem anderen rechner nicht bekannt ist, weil du alles mit dem user pi (also user pi auf dem iobroker rechner) probiert hast. aber nur weil der user auf beiden rechner pi heißt, ist er nicht der selbe.