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

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

[Pedder007]

@oliverio werde ich testen.
Habe gerade nur mal schnell im Motioneye Bestandssystem in home/pi/.ssh/authorized_keys geschaut und da sind tatsächlich auch zwei (?) iobroker Schlüssel drin. Das habe ich irgendwann vor zwei Jahren eingerichtet und somit völlig aus den Augen verloren.
Entsprechend solltest Du hoffentlich wirklich richtig liegen.

Da es auf dem aktuellen Master ja also bereits einen iobroker key gibt, muss ich diesen dann aber dann nur noch auf den neuen Slave propagieren, richtig?
Also keinen neuen mehr anlege, sondern nur noch: sudo -u iobroker ssh-copy-id -i ~/.ssh/id_rsa.pub pi@192.168.xxx.xxx

Edit:
Vergiss die Frage, habs nochmal gelseen und hattest Du ja auch geschrieben .. wer lesen kann

[Pedder007]

@oliverio
klappt nicht weil;

usr/bin/ssh-copy-id: ERROR: failed to open ID file '/home/pi/.ssh/id_rsa.pub': Permission denied

Hatte nun auf dem Zielsystem sogar noch iobroker zu den 'sudo'ern' hinzugefügt und extra auch noch einen entsprechenden Eintrag i nder sudoers vorgenommen, hilft nicht.

Edit:
Müsste es nicht eigentlich auch heißen:

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

Also mit dem iobroker user hinten im Befehl ==> nee, das Resultat bleibt das Gleiche

[wendy2702]

@pedder007 Lass doch das XXX der Internen IPs weg. Da gibt es tausende von und die nützem einem nichts weil man die in der Regel nach Aussen nicht sieht.

[OliverIO]

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

usr/bin/ssh-copy-id: ERROR: failed to open ID file '/home/pi/.ssh/id_rsa.pub': Permission denied

ah, bei sudo -u gibt es wohl noch weitere beschränkungen, das man nicht auf das ssh verzeichnis zugreifen darf
dann musst du es so machen. die beiden befehle der reihe nach eingeben

sudo bash
ssh-copy-id -i /home/iobroker/.ssh/id_rsa.pub pi@192.168.xxx.xxx

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

Müsste es nicht eigentlich auch heißen:
sudo -u iobroker ssh-copy-id -i ~/.ssh/id_rsa.pub iobroker@192.168.xxx.xxx

so hätte es heißen können wenn du das am Anfang konsistent gemacht hast, so wie du oben geschrieben hast, will sich der user iobroker auf dem iobroker system mit user pi auf dem zielsystem anmelden.

wenn konsistente umsetzung, dann müsstest du aber auf dem zielsystem auch noch den user iobroker anlegen. von daher ändere da erst mal nix, sonst wird es für dich noch verwirrender

[Pedder007]

@oliverio

Ergebnis:

root@raspberrypi:/home/iobroker# ssh-copy-id -i /home/iobroker/.ssh/id_rsa.pub pi@192.168.188.179
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/iobroker/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /root/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /root/.ssh/known_hosts:2
ERROR:   remove with:
ERROR:   ssh-keygen -f "/root/.ssh/known_hosts" -R "192.168.188.179"
ERROR: ECDSA host key for 192.168.188.179 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Muss ich den SHA256 Key evtl. noch manuell auf dem Master in die known_hosts eintragen? - wobei mir nicht klar ist, ob das dann nun die known_hosts von root oder pi oder iobroker sein muss, damit das am Ende funktionert.
Aber wahrscheinlich in die von host, für dann den einmaligen Key-Transfer, oder?

Das Thema ist echt "heavy" ... ich weiß gar nicht wie ich das damals hinbekommen habe

[Thomas Braun]

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

root@raspberrypi

räusper

[Pedder007]

@thomas-braun
na' wenn ich am prompt 'sudo bash' eingebe, lande ich da ...

Ich weiß was Du darüber denkst, deswegen will ich das auf dem Zielsystem ja auch nicht als root ausgeführt wissen, was ja bei Proxmox irgendwie der Standard zu sein scheint, wenn man nicht selber noch User anlegt

[Thomas Braun]

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

was ja bei Proxmox irgendwie der Standard zu sein scheint, wenn man nicht selber noch User anlegt

Und deswegen ist es das erste was man in einem Proxmox-Container tut. Man legt einen user an und hampelt nicht als root durch das System.

Ich weiß was Du darüber denkst

Ist auch egal was ich darüber denke, es ist allgemein so üblich. Best practice usw.