Net::OpenSSH > nachfolgende, abhängige Kommandos (Netzwerkprogrammierung und Netzwerke mit Perl)

[thread]18610[/thread]

Net::OpenSSH > nachfolgende, abhängige Kommandos

Tags: perl5 ssh Ähnliche Threads

Leser: 18

Articles: hide open all | hide show old branches

+12 replies
Gast Martin

2013-09-19 18:32
Hallo,

ich habe mit Net::OpenSSH (zumindest laut eigener Beschreibung eines der besten SSH Module) eine Reihe Kommandos auf einem Remote Host abzuarbeiten. Ich kann auf dem Remote Host weder Shell Skripte ablegen, noch kann ich alle Kommandos auf einmal ausführen.

Ich habe beispielsweise diesen Code:
Code: (dl )

1 2 3 4

my $ssh = Net::OpenSSH->new( '10.10.10.10', {user => 'abc', passwd => 'geheim'} ); print $ssh->capture('pwd'); # /home/abc/ $ssh->capture('cd /tmp'); print $ssh->capture('pwd'); # /home/abc/
Das cd in der dritten Zeile hat also keine Auswirkung auf die Umgebung der vierten Zeile. Mittlerweile weiß ich auch, wieso: Net::OpenSSH nutzt die Master/Slave Funktion von ssh. new() baut eine Verbindung auf und läßt sich per socket ansprechen. Jedes capture() erzeugt einen Slave und nutzt dafür die Verbindung des Master. Generell gut, praktisch hat jeder Slave aber seine eigene Umgebung und aufeinander aufbauende Kommandos sind nicht möglich.

Kann mir jemand sagen, wie ich dieses Problem mit Net::OpenSSH lösen kann?
Um das ganze zu erschweren handelt es sich dabei nur um eine API per SSH. Das heißt, ich kann auch keine bash, Pipes oder ähnliches auf dem Ziehost erzeugen.

Viele Grüße
Martin
Last edited: 2013-09-19 18:36:21 +0200 (CEST)
- +11 replies
- pq
  
  2013-09-19 18:49
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  kannst du das in ein kommando verpacken? also:
  print $ssh->capture('cd /tmp; pwd');
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +10 replies
  - Gast Martin
    
    2013-09-19 22:24
    
    Hi,
    
    nein leider nicht. Das ist nur eine Shell ähnliche API, wie sie auch auf Routern und switches zu finden ist. Eine Handvoll Kommandos ohne logische Verknüpfbarkeit. Ich kann weder mit ; noch mit && improvisieren. Ich kann nicht mal ein ls auf ein anderes Verzeichnis als das aktuelle machen.
    
    Das Problem ist, das Net::OpenSSH im Command Mode arbeitet und nicht Interactive. Ich habe es mit zusätzlichen Gebrauch von Expect lauffähig bekommen, aber richtig gefallen tut mir das nicht.
    
    Viele Grüße
    Martin
    Last edited: 2013-09-19 22:29:59 +0200 (CEST)
    - +9 replies
    - jan
      
      2013-09-19 23:41
      
      User since
      2003-08-04
      2536 Artikel
      ModeratorIn
      
      Mh, ich habe keine Erfahrung mit Net::OpenSSH, aber Net::SSH2 ist da vielleicht hilfreicher. Das basiert auch libssh2 und funktioniert ziemlich gut (wenn man von der Komprimierung der Daten absieht, da unterstützen sie die vom Standard abweichenden Methoden von openssh nicht, ich habe dazu mal einen Thread eröffnet und GwenDragon hat's als Bug reported ... ich habe aber nicht verfolgt, ob es upstream je behoben wurde).
      
      Grundsätzlich ist's ja einfach nur, dass Du eine Shell-Session starten musst und Net::OpenSSH das offenbar nicht einfach so tut. Allerdings: reine Vermutung meinerseits.
      
      Bist Du OS-technisch irgendwie beschränkt, dass Du nur spezielle Packages installieren kannst? Sonst empfehle ich defintiv, mal Net::SSH2 zu testen.
      - +6 replies
      - martin.g
        
        2013-09-20 11:51
        
        User since
        2013-09-20
        40 Artikel
        BenutzerIn
        
        Hi, danke für die Anregung.
        Ich habe Net::SSH2 nun auch mal getestet. Abgesehen davon, dass das eher Low-Level ist und die Beschreibung ultradürftig, funktioniert es auch nicht richtig. Aus der Doku konnte ich noch interpretieren, dass ein Channel für mich das richtige ist. Wie man aber Daten an den Channel schickt konnte ich erst durch ein Beispiel, das jemand (scheinbar der Autor) bei PerlMonks gepostet hat.
        
        Das scheint soweit auch zu funktionieren. Aber while <$channel> liefert nur das Kommando und die erste Zeile zurück. $channel->read($buf,512) liefert gar nur das zuvor gesendete Kommando zurück. Selbst wenn ich eine Endlosschleife drum rum baue.
        
        Ich werde noch etwas experimentieren und wenn ich gar nicht weiter komme, dann benutze ich Net::OpenSSH in Zusammenspiel mit Expect.
        Bzw. was ich mir vielleicht gleich mal anschaue ist der Net::SSH2 Modus von Net::OpenSSH::Compat.
        Im Prinzip funktioniert das OpenSSH nämlich hervorragend. Das einzige Problem ist, dass es nicht für meine API Session ausgelegt ist.
        
        Edit: Ich bekomme bei Net::SSH2 nicht mal die erste Zeile von "ls" zurück. Ich dachte es nur, aber in Wirklichkeit war das nur der Shell Prompt nach dem Login. So als wäre ls gar nicht abgeschickt.
        Net::OpenSSH::Compat macht ebenfalls Probleme.
        
        Edit 2: ARGH, als wäre ls gar nicht abgeschickt... Das war der Schlüssel. Ich hatte print $channel "ls\n"; verwendet und die Verbindung zu einem anderen Server hatte auch geklappt. Vielleicht mal mit Windows LF probieren print $channel "ls\r\n"; und zack funktioniert es. So eine mistige API habe ich ja noch nie erlebt....
        
        Sieht also so aus, als würde Net::SSH2 meinen Ansprüchen genügen. Vielen Dank für den Tip!
        Last edited: 2013-09-20 13:31:48 +0200 (CEST)
        
        +5 replies
        
        jan
        
        2013-09-20 17:53
        
        User since
        2003-08-04
        2536 Artikel
        ModeratorIn
        
        :)
        
        Ja, die API ist schwach, aber es läuft dann recht zuverlässig.
        mein kram von damals sah ungefähr so aus:
        
        wichtig dabei: a) ->blocking(1), b) ->shell() um ne shell zu bekommen und dann lese ich erstmal leer falls noch ein banner vom server in der shell kommt o.ä.
        Dann checke ich mit waitforready, dass das ganze funktioniert und dann setze ich mein "ps axuf" ab. Das \n hat bei mir nie Probleme bereitet, Linux sei dank
        
        Edit: die längeren sleep-Times bei mir kamen daher, dass ich da auf Maschinen Kram machte, die teilweise extrem überlastet waren, daher habe ich immer ein paar Sekunden zwischen Kommando und Antwortlesen verstreichen lassen.
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
        
        $ssh2->connect($server) or die $!; if ($ssh2->auth_publickey(@auth)) { my $chan = $ssh2->channel(); $chan->blocking(1); $chan->shell(); sleep(2); while(<$chan>) {}; sleep(1); if(!waitforready($chan)) { $chan->close; $ssh2->disconnect(); next SERVER; } print $chan "ps axuf\n"; sleep(5); my %counting = (); my @lines; while(my $line = <$chan>) { push @lines, $line; } } sub waitforready { my $chan = shift; print $chan 'echo "OKCOMPUTER"' . "\n"; my $foundanswer = 0; my $lookedforanswer = 0; while($foundanswer == 0 && $lookedforanswer < 10) { if(my $line = <$chan>) { if($line =~ m/OKCOMPUTER/) { $foundanswer = 1; return 1; } } sleep(1); $lookedforanswer++; } return 0; }
        
        Last edited: 2013-09-20 17:55:12 +0200 (CEST)
        
        +4 replies
        
        martin.g
        
        2013-09-23 12:45
        
        User since
        2013-09-20
        40 Artikel
        BenutzerIn
        
        Meines sieht ähnlich aus. Ich kann kein echo auf dem Remote Host verwenden, weil es nur eine API ist, aber es gibt ein NOP Kommando, das sich dafür auch gut eignet, das Ende der Ausgabe festzustellen.
        Der Remote Host basiert eigentlich auch auf Linux (Gentoo) - keine Ahnung, was der API Programmierer sich bei dem Windows Zeilenumbruch gedacht hat. War wahrscheinlich keine Absicht. Macht aber auch nichts, jetzt, wo ich es weiß.
        shell() verwende ich ebenfalls, muss man wohl auch.
        
        Mich würde nur interessieren, wieso Du blocking(1) verwendest. Hast Du Dir dabei irgendwas gedacht? Bzw. weißt Du, was genau das tut? Ich bilde mir ein, dass es bei mir nur mit blocking(0) funktioniert hat und so habe ich es aktuell auch.
        Und die Demo, die ich meinte, verwendet in Zusammenhang mit shell() auch immer blocking(0). Irgendwer schreibt dort auch, dass sein Programm erst funktioniert, seit er das eingebaut hat:
        http://www.perlmonks.org/?node_id=569657
        
        Viele Grüße
        Martin
        
        +3 replies
        
        jan
        
        2013-09-23 15:23
        
        User since
        2003-08-04
        2536 Artikel
        ModeratorIn
        
        Ich meine, es wäre bei mir auch zu Problemen gekommen, wenn ich blocking nicht aktiviert habe.
        
        Aus der Doku kann ich das aber auch nicht wirklich erklären:
        Quote
        blocking ( flag )
        
        Enable or disable blocking. Note that if blocking is disabled, methods that create channels may fail, e.g. channel, SFTP, scp_*.
        
        +2 replies
        
        martin.g
        
        2013-09-23 16:15
        
        User since
        2013-09-20
        40 Artikel
        BenutzerIn
        
        Leider ist das der einzige Satz, der in der Doku überhaupt zu blocking() verloren wird. Ich hätte es so interpretiert, dass dann higher-level Methoden fehlschlagen können. Wir erzeugen den Channel ja aber selbst. Und ich persönlich setze blocking auch erst danach auf 0 (vorher steht es bei mir noch auf Standard).
        
        Gegen blocking(1) spricht für mich, dass der Autor blocking(0) nachträglich noch in seine Demo eingefügt hat. Ich denke, wir sind uns einig, dass die Doku insgesamt etwas dürftig ist und wenn es bei Dir so läuft, passt es ja.
        
        topeg
        
        2013-09-23 16:38
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Wie ich es verstanden habe:
        
        Blocking betrifft die Art wie die Daten Transferiert über die SSH-Verbindung transferiert werden. bei "blocking(1)" kann nur ein Programm auf dem Zielsystem Daten senden/empfangen. "blocking(0)" eralubt es das die Daten "durchgereicht" werden.
        
        Beispiel:
        Es werden mehrere Programme in der selben Shell gleichzeitig gestartet: cmd1 &; cmd2 &; cmd3 &;
        Sollte das erste auf dem Zielsystem gestartete Programm nicht von STDIN Lesen können ( close(STDIN) ) werden die Daten an das zweite Programm weitergereicht. usw. So verhält sich auch eine normale Shell.
        Mit "blocking(1)" erzwingt man, dass nur das erste Programm die Daten bekommt. Das ist bei manchen embedded Terminals wichtig, da kann es ansonsten zu Problemen kommen, weil einem "schlafenden" Prozess Daten zugeschoben werden.
        
        Die Sache mit dem "\r\n"
        Viele Embedded Linux Systeme benutzen BusyBox als Shell. Das bündelt viele Programme in einem (ls, mkdir, echo, cat und so weiter) BusyBox ist dahin optimiert möglichst sparsam zu sein. Beim kompilieren kann festlegen welche Befehle vorhanden sein sollen. Und man kann auch im gewissen Maße die "Kompatibilität" festlegen. Da gibt es auch eine Einstellung, in der sich die Shell ähnlich zur Dosbox verhält.
      - +2 replies
      - Gast salva
        
        2013-09-23 12:20
        
        Running a shell is easy:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9
        
        my $ssh = Net::OpenSSH->new(...); my ($in, $out, $pid) = $ssh->open2(); # passing no cmd will start a shell print {$in} "ls\n"; while (<$out>) { print "out: $_"; last if /$prompt_re/; } print {$in} "pwd\n"; ...
        
        Sometimes the following also works:
        
        Code (perl): (dl )
        
        1 2
        
        my $out = $ssh->capture({stdin_data => 'ls\npwd\n'}); print "output:\n$out";
        
        Last edited: 2013-09-23 12:26:53 +0200 (CEST)
        
        martin.g
        
        2013-09-23 12:56
        
        User since
        2013-09-20
        40 Artikel
        BenutzerIn
        
        Hi Salva,
        thank you for reply. I think you are the maintainer/developer of Net::OpenSSH (Salvador). Now, as you say this, it looks obvious. But I tried different possibilities and did not find this solution. I saw this in FAQ http://search.cpan.org/~salva/Net-OpenSSH-0.60/lib...
        
        Quote
        Command mode is designed to run single commands on the remote host. It opens an SSH channel between both hosts, ask the remote computer to run some given command and when it finnish the channel is closed. [...] and it is also the way Net::OpenSSH runs commands on the remote host.
        
        I did not try any more attempts as I read this. If I had seen your solution before, I would have done it in Net::OpenSSH. But now I already switched over to Net::SSH2.
        
        I know for future, thank you
        Regards Martin
        Last edited: 2013-09-23 12:58:20 +0200 (CEST)

View all threads created 2013-09-19 18:32.