Jump to content

Telnet - Session und ihr Feedback (manuell vs. script)

Empfohlene Beiträge

Hallo Forums-Gemeinde! :)

Ich beackere gerade ein altes Programm bei uns, das noch mit einer (altbackenen?) Telnet-Schnittstelle ausgestattet ist. Würde dort gerne das Logging verbessern, wenn diese Schnittstelle (aktuell) per Unix-Script angesprochen wird. Dabei ist mir aufgefallen, dass es irgendwie etwas tückisch ist?! :confused:

Auch wenn ich per Telnet einen FTP-Server anspreche zeigt sich das gleiche Verhalten, darum zeige ich es Euch mal mit dem Beispiel:

Wenn ich "von Hand" an der Kommandozeile die Eingaben mache:


MySystem $ telnet localhost 21

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

220 Welcome to MySystem FTP server

user abc

331 Send password please

pass ******

230 User logged in, proceed

quit

221 Logged out

Connection to localhost closed by foreign host.

Ich sehe also wunderbar meine eingegebenen Kommandos und das Feedback des FTP-Servers. Jetzt packe ich das Ganze in ein Skript:

telnet -d localhost 21 << EOF | tee ftp.log

user abc

pass ******

quit

EOF

Führe ich das Skript aus, sehe ich sowohl am Bildschirm als auch im Logfile "ftp.log" nur folgende Ausgabe:

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

Wohin "verschwinden" Kommandos und Feedback? :confused:

Habe ich irgendeine Chance zumindest das Feedback (Return Codes) des FTP-Servers aufzufangen?

Betriebssystem ist Solaris 10...

Irgendwie blicke ich gerade nicht wie das mit den Standard-Datenströmen bei so einer Telnet-Session mittels Skript-Aufruf so läuft...kann mich da eventuell jemand von Euch erhellen? :)

Links zu erklärenden Seiten oder Tools/Wrapper, die man da eventuell zwischenschalten kann/muß sind herzlich willkommen! :D

Danke vorab!!!

Viele Grüße

Flori

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hmmm - eventuell musst du die Standardausgaben (gibt ja stdout und stderr) dann ins Logfile, in die Pipe zu "tee" oder wohin auch immer du es haben willst umleiten.

Schau mal hier. Vielleicht liegt es ja daran.

Wie man in der Grafik hier sehen kann, wird zwar das stdout der Pipe übergeben, jedoch das stderr geht per default aufs Display und nicht in die Pipe.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi Crash,

danke für Deine ersten Tipps! Laut den Links verstehe ich das IMHO schon alles richtig und kann dem logisch folgen.

Leider gelingt es mir immer noch nicht, die Server-Ausgaben zu "fassen zu bekommen". :-\

Hier mal meine weiteren Findings von heute...

Den Telnet-Aufruf nochmal händisch gemacht, diesmal bewußt stdout und stderr umgeleitet. Logischerweise gab es an der Kommadozeile außer meiner Ausgaben dann nichts zu sehen, da ja "alles" umgeleitet war in Dateien:


MySystem $ telnet localhost 21 1>telnet.out 2>telnet.err

user abc

pass ******

quit

Und siehe da, ich finde die FTP-Server-Codes in der "telnet.out" - so verteilen sich die Ausgaben, die alle sonst erstmal am Bildschirm erscheinen :

::::::::::::::

telnet.err

::::::::::::::

Connection to localhost closed by foreign host.

::::::::::::::


::::::::::::::

telnet.out

::::::::::::::

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

220 Welcome to MySystem FTP server

331 Send password please

230 User logged in, proceed

221 Logged out

Allerdings, wenn ich das Ganze so wieder in ein Skript bringt, kommt wieder die Ernüchterung. :(

telnet localhost 21 1>telnet.out 2>telnet.err << EOF

user abc

pass ******

quit

EOF

Bringt leider eine andere "telnet.out" als zuvor händisch:

::::::::::::::

telnet.err

::::::::::::::

Connection to localhost closed by foreign host.

::::::::::::::


::::::::::::::

telnet.out

::::::::::::::

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

Irgendwie bleiben die Antworten beim Aufruf über Skript "auf der Strecke" oder innerhalb von "Session-into-session"-Aufrufen gefangen, so dass man die nicht bekommt. Auch das Skript über ein Skript aufzurufen (im Sinne von "Wrapper") und stattdessen die Ausgaben des äußeren Skripts zu fangen, bringen kein anderes Ergebnis.

Weiß da noch jemand Rat? Oder ist somit einfach nicht dranzukommen per Skript an den Telnet-Output ? :confused:

Danke für weitere Hinweise!

Grüße

Flori

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hmmm... man kann afaik auch die Standardausgabe generell umleiten - also nicht nur für einen Befehl sondern generell. Wie weiß ich leider jetzt auch nicht.

Ansonsten kannst du mal schauen, ob du das fehlende in /dev/stderr bzw. /proc/self/fd/2 irgendwie abgreifen kannst. (Standardziel von stderr)

Es gibt ansonsten aber auch noch die Möglichkeit, stderr dorthin umzuleiten, wo stdout JETZT hinzeigt mittels 2>&1 drangehänt. Ob das bei Scripts auch funktioniert, weiß ich aber nicht und kanns grad auch nicht testen.

Eventuell funktioniert auch das hier.

telnet -d localhost 21 << EOF |[color=red]&[/color] tee ftp.log

Das & steht dafür, dass stdout und stderr in die Pipe umgeleitet werden. Vielleicht löst das oder eine Kombination davon ja dein Problem.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Woran wohl die Wenigsten denken: Das OSI-Modell hat eine sechste Schicht (Präsentations-Ebene), über die der Client dem Server mitteilt, wie sein Terminal (d.h. die Text-Konsole) aussieht - z.B. wie viele Zeichen in einer Reihe dargestellt werden können, wie viele Zeilen es gibt, ob farbiger, unterstrichener Text etc. dargestellt werden kann neben ein paar weiteren Eigenschaften. Startet man per Telnet oder SSH eine text-basierte Anwendung, weiss der Server dadurch, wie die textbasierte Anwendung formatiert werden soll - und auch Dinge wie z.B. die Anzahl der Buchstaben, die in einem Feld bis zur nächsten Trennlinie erscheinen sollen.

Je nach dem, ob man ein richtiges Telnet-Programm benutzt oder per Skript oder mit einem rudimentären eigenen Programm auf einen TCP-Port zugreift, werden diese Daten im OSI-Layer 6 übermittelt oder auch nicht. Von daher kann davon auch die Frage danach abhängen, ob es ein Echo für Passwörter gibt doer nicht.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Mit diesem << EOF habe ich noch nicht gearbeitet. Meiner Erfahrung nach braucht telnet immer etwas Zeit. Es könnte sein, dass Deine Eingaben schon durch sind bevor telnet gestartet ist.

In der bash hatte ich immer Erfolg mit so etwas:

(sleep 1;echo root;sleep 1;echo rootpasswort;sleep 1;echo ls;sleep 1; echo df;sleep 1; echo exit )|telnet localhost |tee datei.log

Das habe ich jetzt nicht ausprobiert, sollte aber stimmen. Das ist primitiv, hat man sich aber schnell hingebastelt. Ein schönes Script kann man später immer noch machen.

Hier logged sich der Benutzer root mit dem Passwort rootpasswort ein und führt ein ls und df aus und logged sich mit exit aus. Die Kommandofolge kann mit einer while-read-Schleife aus einer Datei gelesen werden.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Rohling hat natürlich recht - man darf nicht einfach so Kommandos losfeuern, sondern muss auf die Eingabeaufforderung des Servers warten.

Fixe Zeitangaben sind allerdings nicht das Wahre - besser man nutzt z.B. das Programm 'expect':

Beispiel:


#!/bin/bash

expect << EOF

spawn telnet localhost 21

expect "220"

send "USER anonymous\r"

expect "331"

send "PASS secret\r"

expect "230"

send "HELP\r"

expect "214"

send "quit\r"

EOF

Grüße,

Sascha

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nimm an der Diskussion teil

Du kannst jetzt hier posten und Dich später registrieren. Wenn Du bereits über eine Konto verfügst, melde Dich jetzt an, um mit Deinem Konto zu posten.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


Fachinformatiker.de, 2019 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung