Kommando an laufenden SSH Client schicken...

[cndg]

Hi!

Ich habe im Wohnzimmer einen Rechner stehen, der als Internet Gateway mit Dial-up-Verbindung (ISDN) konfiguriert ist. Die Dial-up-Verbindung kann man von der Shell aus steuern. Um nun von einem anderen Rechner im Haus ins Internet zu kommen, führt man auf diesem Rechner ein kleines Skript aus, das via SSH auf dem Internet-Gateway das Dial-Skript ausführt (z.B. ssh root@linux isdnctrl dial ippp0). Dazu muss allerdings für jeden Wähl- (und Trenn-)Vorgang ein neues SSH Handshake initialisiert werden, was ein bis zwei Sekunden dauert. Was sinnvoller wäre ist eine SSH-Verbindung, die beim Hochfahren des Clients nur einmal aufgebaut wird, und der dann, während sie läuft, von kleinen Skripts aus der gewünschte Befehl übergeben wird. Damit fiele das ständige Handshake weg. Gibt es irgendeine Möglichkeit, einer bereits laufenden SSH-Verbindung automatisiert Befehle zu übergeben?

mfg
cndg

[helios]

das einzige was mir dazu einfällt sind pipes bzw. named pipes, etwa in der art:

lokales_programm | ssh ...

[cndg]

Die SSH-Verbindung muss aber auch dann immer wieder neu aufgebaut werden, wenn ich das richtig verstehe. Was ich brauche, ist eine Möglichkeit, einem laufenden ssh-Prozess (vielleicht anhand seiner ID) Kommandos zu übergeben. Der Prozess läuft dann praktisch auf Idle und ich übergebe ihm "on demand" die entsprechenden Befehle (also prinzipiell eben genau das selbe, wie wenn ich in die SSH Shell von der Tastatur aus die Befehle eintippe).

mfg
cndg

[Clystron]

Wieso so kompliziert?

Du kannst dich doch einmal einloggen und dann deine isdnctrl-befehle in der laufenden session eintippen. Damits komfortabler wirds würd ich die auf dem Router in scripts verpacken.

Wo ist der Unterschied ob du Befehle direkt in einer SSH-Session eingibst oder schweinekompliziert ein zusätzliches lokales Program startest das deine Befehle über STDIN des SSH-Clients an die SSH-Session übergibt?

mfG
Wolfgang

[cndg]

Nein. Da hast du mich falsch verstanden. Im Endeffekt sollte sich daraus ja die Möglichkeit ergeben, die Befehle von einem Desktop/Panel Laucher aus zu starten. Jedenfalls find ich es _nicht_ schweinekompliziert, ein Programm/Skript mit einem Launcher zu starten, das mit der Session kommuniziert, eher im Gegenteil. Wär ja irgendwie schwachsinnig, die Internetverbindung immer von der Shell aus mit der Tastatur zu steuern.

mfg
cndg

[Clystron]

Nein ich habe dich nicht falsch verstanden, ich finde das nur einfach kompliziert.

Die einzige Möglichkeit ist AFAIK über STDIN/STDOUT mit dem SSH-Client zu kommunizieren, das heisst du hast permanent einen SSH-Client und dein Programm das an STDIN/STDOUT des Clients hängt am laufen (von welchem OS reden wir eigenlich am Client?).

Schneller als SSH ist z.B. RSH oder brauchst du unbedingt Verschlüsselung?

Andere möglichkeit wäre auch ein kleines Programm/Script in den inetd zu hängen.

Ist Dial-on-Demand keine Alternative?

mfG
Wolfgang

[cndg]

Ja. Das Problem besteht nun darin, dass die SSH-Verbindung (RSH ist auch eine Möglichkeit, ist aber so viel ich weiß im Prinzip das selbe, auch wenn es vielleicht etwas schneller ist) als Prozess im Hintergrund läuft und daher nicht mit dem STDIN verbunden ist (behaupte ich mal). Jedenfalls suche ich nach einer Möglichkeit, dem laufenden SSH-Prozess auf ähnlichem Wege wie STDIN Eingaben zu liefern (also vom Prinzip her ganz einfach). Am Client läuft Ubuntu Linux.
"inetd" reagiert so viel ich weiß auf Verbindungen an seinen Sockets und führt entsprechende Skripts aus. D.h. ich müsste am Client ein Skript schreiben, das sich mit einem Socket am inetd verbindet?
Dial-on-Demand ist keine Alternative.

mfg
cndg

[Clystron]

RSH ist sowas wie SSH nur älter und halt viel schneller im Verbindungsaufbau da ohne Verschlüsselung und das war ja dein einziges Problem im Eröffnungspost.

Aber egal:
Linux am client eröffnet schonmal ein paar möglichkeiten...

JEDER Prozess hat seine STDIN/STDOUT/STDERR filedeskriptoren, bei Daemons werden diese aber bewusst nach dem Start geschlossen bzw. vom Terminal getrennt. Du musst halt dafür sorgen dass du den STDIN des SSH-Clients irgendwo festbindest wo du ihn wiederfindest (PTY oder FIFO/named PIPE)...

Beispiel:
Du startest "program | ssh-client" im Hintergrund, "program" öffnet eine named PIPE "/tmp/connection" und wartet auf Eingabe. Über "/tmp/connection" kannst du dann deinem program befehle schicken und das wiederum kann sie an den ssh-client weiterleiten. Blöd nur wenn der sich beendet...

Schöner wär natürlich ein tool das selbst den ssh-client startet über vfork/exec und sich da dran heftet. Ich hab sowas schonmal gemacht müsste aber den Source-Code erstmal suchen gehen...

Über den inetd ginge es z.B. so:

Am Server ein Script das nach dem starten eine Zeile von STDIN liest und je nach deren Inhalt die Verbindung aufbaut oder trennt. Das dann über den inetd an ein TCP oder UDP port hängen und für den Client das gegenstück schreiben (kleines C-Programm).

Oder du machst jeweils ein Script für den Auf und Abbau der Verbindung und hängst sie an 2 TCP Ports. Dann wirds am Client einfacher, einfach Telnet auf port xxx und das Script baut die Verbindung auf, bei port yyy wird sie getrennt.

Ist natürlich alles mehr oder weniger "quick and dirty"

mfG
Wolfgang