[gelöst] SSH Problem: sudo: no tty present and no askpas....

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

[Pedder007]

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

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.

Und deswegen gibt's da bei mir natürlich jetzt auch einen 'pi', habe ich mangels Phantasie mal einfach von den Raspis so übernommen
Und einen iobroker, weil der Container läuft ja auch schon als Slave

[Pedder007]

@oliverio said in SSH Problem: sudo: no tty present and no askpas....:
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

keine weiteren Ideen? Ich stehe auf dem Schlauch

Oder evtl. alles zurück auf Start, und dann das Ganze direkt mit dem User iobroker umsetzen?
Im Script ist die Änderung ja nur marginal

Edit:
Ich habe mir jetzt nochmal die Fehlermeldung (oben) in der Ubuntu Doku durchgelesen. Demnach existiert also schon ein iobroker Key auf dem Zielsystem (welcher verändert uwrde), was aber komisch ist, da es auf dem Zielsystem in /home/iobroker/ gar kein .ssh Verzeichnis gibt in welchem ja der Key liegen müsste
Entsprechend schlägt dann auch (aus der Ubuntu Doku)

root@raspberrypi:/# ssh-keygen -f "/home/iobroker/.ssh/known_hosts" -R 192.168.188.179
Host 192.168.188.179 not found in /home/iobroker/.ssh/known_hosts

folglich fehl,
Ich versteh' gar nix mehr

[Thomas Braun]

@pedder007

Du nutzt immer noch den falschen User....
Gewöhn dir den Scheiss ab!

[Pedder007]

@thomas-braun

das hilft mir jetzt nicht gerade weiter, ich bin ja nur oben @OliverIO 's Anweisungen nachgekommen.

und im übrigen arbeite ich sonst nie unter ROOT und deswegen ist das in der Form gerade etwas unpassend!

[Thomas Braun]

@pedder007

Und warum tust du es jetzt? Man arbeitet NIE als root. Nie wie in gar nicht.

Die Keys sind zunächst mal an den User gebunden, der die kreiert. Als ist der root hier noch mehr tabu als grundsätzlich ohnehin schon.

[Pedder007]

@thomas-braun
na' dann wäre dieser Hinweis ja wohl schon weiter oben fällig gewesen und vor allem dann vielleicht auch mit einem weiteren Hinweis, wie man das ansonsten (ohne ROOT) in den Griff bekommt.

Ich habe hier ja schließlich um Hilfe ersucht und nichts anderes

[Thomas Braun]

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

dann wäre dieser Hinweis ja wohl schon weiter oben fällig gewesen

Da es absolute Grundlage ist, nicht als root herumzuzappeln sollte es eigentlich keines weiteren Hinweises dazu bedürfen.