Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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" ... :sweat: 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 :cry:

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

[Pedder007]

@thomas-braun
ich glaube wir stellen das hier mal ein, dass hat ja nichts mehr mit der eigentlichen Frage zu tun ... :-(

[Thomas Braun]

@pedder007

Ja schon. Du wunderst dich, dass Account-gebundene Keys nicht funktionieren, wenn sie mit dem falschen User angepackt werden.

[OliverIO]

@pedder007

so jetzt mal von grundauf

wir haben 2 Systeme

System A
auf dem läuft der iobroker
da gibt es den user root,pi,iobroker

System B
da läuft motioneye
da gibt es den user pi

von System A soll per SSH von system B was abgerufen werden.

1. zu prüfen ist, ob auf System A bereits ein Schlüsselpärchen für benutzer iobroker erzeugt wurde. das ist bei skriptaufrufen durch iobroker auch zwingend notwendig und nicht durch einen anderen usernamen ersetzbar.

falls ein Schlüssel existiert, dann sollte die folgende datei bereits vorhanden sein

/homer/iobroker/.ssh/id_rsa.pub

wenn nein, dann muss ein neuer schlüssel generiert werden

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

alles im standard bestätigen. wen gewünscht kann die passphrase eingegeben werden, aber der dateiname sollte nicht verändert werden
danach nochmal prüfen ob die datei is_rsa.pub nun existiert

2. user auf system B erzeugen, ich nenne ihn mal scriptuser um es klar zu unterscheiden

sudo adduser scriptuser

man wird nach einem passwort gefragt, welches wir auch erst einmal setzen, da wir es später noch benötigen
die anderen fragen sind alle optional und können durchbestätigt werden

3. schlüssel von System A nach System B kopieren

der Public Schlüssel des users iobroker muss nun als gültigen Schlüssel für user scriptuser auf System B registriert werden

dazu wechselt man auf System A zum user iobroker

sudo -u iobroker bash

im Anschluss kopiert man den Schlüssel auf den anderen Rechner mit folgendem Befehl

ssh-copy-id -i ~/.ssh/id_rsa.pub scriptuser@192.168.x.x

Der Befehl verbindet sich dann mit System B, fragt nach dem Passwort des scriptusers und trägt dann die Schlüssel alles richtig dort ein.

Anmerkung zu unseren bisherigen versuchen. Dieser Befehl kann nur so ausgeführt werden. den Befehl mit einem sudo -u iobroker davor in einem schritt auszuführen schlägt fehl. auch als root die datei absolut zu benennen funktioniert nicht. das war mein fehler oben.

4. test der ssh verbindung
   Auf system A, als user iobroker
   (man ist ja durch schritt 3 noch als iobroker angemeldet, also kann man direkt weitermachen)

ssh scriptuser@192.168.x.x

Im Anschluss sollte das prompt von
iobroker@IP oder Hostname von System A
nach
scriptuser@IP oder Hostname von System B
wechseln.

diese schritte habe ich soeben selbst mit 2 docker container nachvollzogen und erfolgreich getestet.

Mit dem root-Thema gebe ich @Thomas-Braun recht. wobei ich es nicht ganz so kritisch sehe, wenn man weiß was man tut.
Allerdings gilt das für 98% der Forumsbeteiligten nicht. Daher ist die strikte Haltung in diesem Forum schon OK. Wer denkt er kennt sich aus, der setzt sich ja sowieso darüber hinweg, weiß aber, das er dann nicht meckern darf.
Du brauchst bei dieser root verwendung keine Angst haben, das was kaputt gegangen ist, da der obige Befehl auf dem iobroker rechner nur gelesen und nix geschrieben hat.
Das hier auch bei root eine besondere Behandlung des Verzeichnisses .ssh erfolgt und der Befehl nicht so funktioniert wie erwartet, obwohl man explizit die schlüsseldatei angegeben hat, war für mich auch neu

[Thomas Braun]

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

Allerdings gilt das für 98% der Forumsbeteiligten nicht.

Und die anderen 2% tun es nicht, weil sie verstanden haben das es viel komplexer ist und zu mehr 'komischem Verhalten' des Systems führt, wenn man dauerhaft als root herumzappelt.