SSH2Exec LBS 19000306

[Schmu]

Ich würde empfehlen, schnell Tastatur und Monitor am PI anschließen die Zeilen die du geändert hast wieder löschen oder eine # davor setzen.
Ich kann nur empfehlen die Einstellungen vorher mit dem starten einer weiteren Instanz auf Port 2222 zu prüfen, bevor man sie im Livebetrieb umsetzt.

[jonofe]

Tastatur und Bildschirm dran und die Änderungen via Console rückgängig machen.

[skyacer]

jonofe

besteht bei dir die Möglichkeit den LBS zu updaten mit neueren
KexAlgorithms und ciphern?

Grüße

[MauPort]

Da ich das gleiche Problem mit der SSH2 Verbindung hatte, habe ich mich nun ein wenig mit dem SSH Thema beschäftigt.

So wie es aussieht, unterstützt SSH2 ausschließlich Diffie-Hellman-Algorithmen und zwar:
diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1, diffie-hellman-group-exchange-sha256

Wie starwarsfan schon erwähnt hatte wird davon abgeraten den Algorithmus diffie-hellman-group1-sha1 zu nutzen. Wie sicher nun die anderen sind, kann ich nicht sagen, aber auf der Seite https://www.ssh.com/academy/ssh/sshd_config werden u.a. diffie-hellman-group14-sha1 und diffie-hellman-group-exchange-sha256 empfohlen zu verwenden. Nach meiner OpenSSH Installation auf meinem Remote-Rechner (Ubuntu-Mate) war allerdings nur der Letzte bekannt.
Also mit dem Befehl:

sudo sshd -T | grep "\(ciphers\|kexalgorithms\)"

um die bekannten ciphers und algorithms zu Listen.
Dabei ist mir auch gleich aufgefallen, dass die aktuelle OpenSSH Installation keine der im Baustein verwendeten Ciphers nutzt (zumindest im Default).

Deshalb habe den *-sha256, sowie die im SSH2 und auf meinem Rechner bekannten Ciphers in den LBS angepasst.

Also anstatt:

'kex' => 'diffie-hellman-group1-sha1',

,

'crypt' => '3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc',

wird folgendes benutzt.

'kex' => 'diffie-hellman-group-exchange-sha256',

,

'crypt' => 'crypt' => 'aes128-ctr,aes192-ctr,aes256-ctr',

Danach hat alles einwandfrei funktioniert.

In der Beschreibung der Funktion ssh2_connect() (https://www.php.net/manual/de/function.ssh2-connect.php) sind der verwendete Algorithmus und die verwendeten Ciphers zwar nicht gelistet, aber es steht auch dabei, dass die nutzbaren algorithms und ciphers abhängig von der verwendeten ssh2-libary sind. Diese unterstützt mittlereweile mehr. (https://www.libssh2.org/)

Ich bin, wie am Anfang geschrieben, erst ganz neu in das Thema SSH eingestiegen und heute war auch Premiere in Sachen PHP, aber eventuel wäre da eine neue LBS Version sinvoll.

starwarsfan
Was meinst du? Ist der diffie-hellman-group-exchange-sha256 besser oder ist dieser auch von der Logjam attack betroffen?
Und wie sieht es mit den ciphers aus? Hier finde ich im Netz Vor- u. Nachteile bei cbc als auch bei ctr. Zumindest werden diese auf der oben verlinkten SSH Seite empfohlen.

jonofe

Falls meine Änderungen wirklich eher dem aktuellen SSH-Stand entsprechen, wäre das u.U. einer Überlegung für Version 0.6 Wert.
Eventuel auch über einen weiteren Eingangsparameter um zwischen beiden settings umschalten zu können.

[jonofe]

Ich habe inzwischen festgestellt, dass bei mir schon lange der SSH2 LBS ohne Angabe der KEX oder CRYPT Methods läuft. Damit werden die entsprechenden Methoden frei zwischen Client und Server ausgehandelt, d.h. so wie man es von anderen SSH Clients (ssh, putty, WinScp, etc.) auch kennt. Ich werde das Update mal hochladen. Wenn es dann noch Probleme gibt, einfach hier melden.

EDIT: Ich habe zusätzlich noch einen Ausgang spendiert (A3), an dem jetzt die ausgehandelten Methoden als JSON ausgegeben werden.

[MauPort]

jonofe
Das ist natürlich eine viel bessere Lösung, da deutlich flexibler. Zudem sollten späteren Updates von php-ssh2 gleich die neueste library laden und damit die neuesten KEY und CRYPTS hinzugefügt werden ohne am Baustein was ändern zu müssen.

In der Beschreibung von ssh2_connect() hatte ich nicht gleich gesehen, dass KEX und CRYPT nur optional sind. Aber ich habe gesehen, dass einige Beispiele ausschließlich host und port als Input nutzen.

Danke fürs Update!

[eXec]

jonofe

Hi,

gibt es eine Möglichkeit die folgende Fehlermeldung zu unterdrücken?

Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000306.php | Fehlercode: 2 | Zeile: 126 | stream_get_contents(): Failure 'transport read' (-43)
Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000306.php | Fehlercode: 2 | Zeile: 91 | ssh2_exec(): Unable to request a channel from remote host

Diese entsteht, wenn ich den Server durch reboot Befehl durchstarten lasse.

Gruß A

[jonofe]

Diese entsteht, wenn ich den Server durch reboot Befehl durchstarten lasse.

Welchen Server? Edomi? Oder den SSH Zielserver?

[givemeone]

Welchen Server? Edomi? Oder den SSH Zielserver?

ssh zielderver. Der rebooted direkt, und schließt die Verbindung nicht mehr sauber.(Systemd). Das ist bei mir leider auch so.

[MauPort]

givemeone eXec
Probiert mal das:

sudo shutdown --reboot 0 && exit

mit reboot bzw. shutdown -r hat das bei mir auch nicht richitg funktioniert.

Hier mein Edomi log:

2021-05-26 19:22:36	228867	22143	debug	EXE19000306 [v0.6]: SSH2 command executed: sudo shutdown --reboot 0 && exit (1)
2021-05-26 19:22:36	241440	22143	debug	EXE19000306 [v0.6]: SSH2 execution finished (1)

[givemeone]

Das geht bei meinem Endgerät nicht, aber danke für den tip.....

[jonofe]

Vielleicht mal mit

(sleep 3 && reboot) &

versuchen

[eXec]

sudo shutdown --reboot 0 && exit

wirf nur noch den Fehler:

 Fehlercode: 2 | Zeile: 91 | ssh2_exec(): Unable to request a channel from remote host    ERROR

und

(sleep 3 && reboot) &

wirft wieder beide Fehlermeldungen:

Fehlercode: 2 | Zeile: 126 | stream_get_contents(): Failure 'transport read' (-43)    ERROR
Fehlercode: 2 | Zeile: 91 | ssh2_exec(): Unable to request a channel from remote host    ERROR

Vielleicht muss man ein Shellscript schreiben, was auf dem Zielserver, als Child den Server runterfährt (falls möglich). Dann könnte das Skript aufgerufen werden, die Verbindung getrennt werden und nach Zeit X macht der Server den Reboot. Da sind meine Unix Kenntnisse nicht so gut.

[eXec]

Ok, ich habe eine Lösung gefunden, ähnlich wie gedacht, nur ohne Script auf Server:

ssh user@192.168.0.130 "nohup sudo reboot &>/dev/null & exit"

explanation:

• you want to exit as the last command so the status of the last command is 0 (success). You can prepend a sleep if you wish, but it is not necessary
• you need to run reboot in the background, because otherwise the server will close the connection and you will get an error. It will still reboot on most systems but if you are scripting the return status will be error (not 0) even with the command executing properly
• running on the background is not enough, as the stdin and stdout are still attached to the virtual terminal through SSH, so the connection will not be closed. You need to do two extra things for the SSH session to end and leave the command running on the background.
  • 1) you need to redirect stdout and stderr to /dev/null so they are not redirected by the virtual terminal that holds the SSH session. This is the &>/dev/null part.
  • 2) you need to redirect stdin to an unreadable file in the same fashion. That is what the shell builtin nohup does.

With only a command running on the background dettached from the terminal in every way, exit will close the session and because there are no stdin or stdout left on the virtual terminal SSH will terminate the connection without errors.

[MauPort]

eXec
Kann ich bestätigen. Auch dieser Befehl geht bei mir.

Ich denke, da bist du auf den selben unix.stackexchange-Thread gestoßen, aus welchem auch ich die von mir vorgeschlagene Lösung (ein Thread darunter) habe.
Hatte einige Vorschläge von dort probiert und nur diese beiden haben bei mir funktioniert.