Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

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

[Pedder007]

Hallo @oliverio erst einmal vielen Dank für Deine große Mühe, so macht die Zusammenarbeit wirklich Freude!
Nachdem ich gerade noch ein paar Devices von deConz nach ZigBee umgezogen habe und die entsprechenden Aliase und Scripte nachgezogen habe und das alles wieder gut funktioniert bin ich nun auch wieder motiviert mich dieser Herausforderung zu widmen ;-)

Ich gehe mal entlang Deiner Anleitung:

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

/homer/iobroker/.ssh/id_rsa.pub

=> haben wir

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

sudo adduser scriptuser

=> haben wir = 'pi', mit PW, alles andere leer

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

==> da bin ich mir unsicher ob wir den Schritt schon hatten, ich glaube nicht, weil da bin ich via sudo bash ja nach root 'gezappelt'

Aber leider zerlegt's uns an dieser Stelle schon wieder:

iobroker@raspberrypi:/ $ ssh-copy-id -i ~/.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"
The authenticity of host '192.168.188.179 (192.168.188.179)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/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: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
pi@192.168.188.179: Permission denied (publickey).

PW ist auch nicht abgefragt worden

Nur eine Anmerkung am Rande, da ich ja Proxmox Newbee bin:
Es ist schon richtig, dass ich die ganze Zeit immer auf die IP Adresse des Containers Ziele, ja?

[OliverIO]

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

ssh-copy-id

hattest du das anmelden per passwort auf system b deaktiviert?
bitte prüfe auf system b die folgende datei

/etc/ssh/sshd_config:

und darin diese Einstellung muss auf yes stehen

PasswordAuthentication yes

dann musst du den ssh daemon neu starten

service sshd restart

[OliverIO]

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

Nur eine Anmerkung am Rande, da ich ja Proxmox Newbee bin:
Es ist schon richtig, dass ich die ganze Zeit immer auf die IP Adresse des Containers Ziele, ja?

welche systeme hast du den als container?
bei ssh-copy-id gibst du die user und adresse von system b an, so wie oben beschrieben

[Pedder007]

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

und darin diese Einstellung muss auf yes stehen
PasswordAuthentication yes

Ja das stand noch auch 'no'.
Oben wiederholt und nun klappt auch dass ssh mit pi ohne PW, vom iobroker user aus.
Entsprechend werde ich das jetzt nochmals mit dem Blockly probieren.

welche systeme hast du den als container?
bei ssh-copy-id gibst du die user und adresse von system b an, so wie oben beschrieben

Aktuell tatsächlich erst einmal nur den Motioneye-Container (CT), sonst nichts.