Ich muss im Rahmen eines Softwareprojektes von einem externen Gerät ASCII-Daten per Telnet (TCP, Port 23) empfangen. Dazu muss sich meine Software mit einem TCP-Socket verbinden und dann mit unser/pass anmelden. Wie aber werden Benutzer und Passwort beim Öffnen einer Telnet-Session übertragen? Ich habe früher mal sowas für SMTP oder POP3 gemacht, da war genau beschrieben, wie diese Daten z.B. per Bae64 zu codieren sind. In der zuständigen RFC845 für Telnet kommen die Begriffe user und password aber putzigerweise garnicht vor. Ich will auch keine fette fremde Lib einbinden, ich denke, das Bisschen TCP-read und write bekomme ich auch alleine hin. Kennt jemand einen Link, wo die Kommunikation für Telnet detailliert beschrieben ist? Meine bisherigen Recherchen brachten bisher immer nur allgemeines Geschwafel und Software-Empfehlungen dazu hervor. Danke für Infos. Und bitte keinen altklugen Hinweis darauf, dass SSH viel sicherer ist, Telnet wird durch das Gerät vorgegeben.
Frank E. schrieb: > Wie aber werden Benutzer und Passwort beim Öffnen einer Telnet-Session > übertragen? IMHO gar nicht. Was man sieht, wenn man sich z.B. einloggt ist die Anwendung darüber. MfG Klaus
Frank E. schrieb: > In der zuständigen RFC845 für Telnet kommen die Begriffe user und > password aber putzigerweise garnicht vor. Das funktioniert genauso wie es bei einem seriellen Terminal funktioniert. Ob Benutzernamen oder Passwort gefordert werden, entscheidet Deine Anwendung, die eine Protokollschicht oberhalb des Telnet-Protokolls liegt. Du solltest nur vor der Passwortabfrage sicherstellen, daß das lokale Echo des Telnet-Clients deaktiviert ist.
Rufus Τ. F. schrieb: > Du solltest nur vor der Passwortabfrage sicherstellen, daß das lokale > Echo des Telnet-Clients deaktiviert ist. Das sollte eigentlich vom Server gesteuert werden. Der schickt nach dem Passwort-Prompt ein "IAC DONT ECHO". (Natürlich nur, wenn sich Client und Server sich vorher einig geworden sind, dass der Client für das Echo zuständig ist) mit einigen neueren Telnet-Erweiterungen (RFC nicht mehr dreistellig) kann der Login auch OOB mit div. Kryptoalgorithmen erfolgen und die ganze Verbindung verschlüsselt werden. https://tools.ietf.org/html/rfc2941 Viele denken "Telnet == TCP", vermutlich weil sich der Telnet-Client gut zum manuell Testen von div. TCP-Serverdiensten eignet, aber Telnet ist doch deutlich mehr.
Rufus Τ. F. schrieb: > Du solltest nur vor der Passwortabfrage sicherstellen, daß das lokale > Echo des Telnet-Clients deaktiviert ist. Da ich diesen Teil ja selber programmieren will, kann ich einfach auf das Echo verzichten. Ich hoffe schon auf simples TCP-Ping-Pong im Klartext. Konkret geht es darum, Daten-"Telegramme" aus einem Netzwerkmodul "PKE" des LCN-Hausbus-Systms zu parsen (und darauf zu reagieren). Ich hoffe, der im PKE enthaltene Server macht keine allzu exotischen Spielchen ... komme erst in der nächsten Woche an das Ding heran, wollte mich aber schon irgendwie vorbereiten. Eine Dokumentation erhält man vom Hersteller Issendorf blöderweise nur dann, wenn man einen "Musterkoffer" kauft - was für mich nicht in Frage kommt, weil ich ja sonst mit LCN nix zu tun habe ... Hat hier jemand eine solche Doku oder kennt einen Link auf diese in die dunklen Ecken des Web?
:
Bearbeitet durch User
Frank E. schrieb: > Da ich diesen Teil ja selber programmieren will, kann ich einfach auf > das Echo verzichten. Sicher, man will eigentlich nie ein lokales Echo haben. Nur gibt es telnet-Clients, bei denen das per default aktiv ist, und da muss man es tunlichst abschalten. Wie das geht, hat "Tastenklopper" beschrieben.
Mit wireshark kannst du leicht deinem system bei der telnet kommunikation zuschauen, die eingebaute protokollanalyse zeigt dir sehr detailiert den protokollaufbau Hier eine beispiel telnet aufzeichnung von wireshark: https://wiki.wireshark.org/SampleCaptures#Telnet https://www.modius-techblog.de/netzwerk-co/telnet-und-tftp-mit-wireshark-analysieren/
Hallo Frank, solange Sicherheit für Dich kein Thema ist, kannst Du das Telnet "Protokoll" (also Behandlung von Sonderzeichen) komplett ignorieren. Bei mehreren Kunden von mir haben wir seit vielen Jahren Systeme im Einsatz, die einfach nur einen TCP listener aufsetzen und (wie von Rufus dargestellt) ohne eigene Logik sämtliche (lesbare ASCII) Zeichen 1:1 in beide Richtungen durchpumpen. Das läuft mit sämtlichen Telnet Clients ohne Probleme. Hat allerdings (wie auch schon angemerkt) den Nachteil, dass der gesamte Nutzdatenverkehr (einschliesslich Klartextpasswort, wenn implementiert) mit einem Sniffer auslesbar ist. Interessanter wird es in der Tat, wenn es darum geht, den Datenverkehr Ende-zu-ende zu verschlüsseln (das wird vom Markt zunehmend gefordert).
Ruediger A. schrieb: > Interessanter wird es in der Tat, wenn es darum geht, den Datenverkehr > Ende-zu-ende zu verschlüsseln (das wird vom Markt zunehmend gefordert). Dann nimmt man ssh. Das ist etabliert, es gibt ausreichend viele Clients und Serverimplementierungen dafür, und die als Grundlage eingesetzten Bibliotheken werden auch gepflegt.
Rufus Τ. F. schrieb: > Ruediger A. schrieb: >> Interessanter wird es in der Tat, wenn es darum geht, den Datenverkehr >> Ende-zu-ende zu verschlüsseln (das wird vom Markt zunehmend gefordert). > > Dann nimmt man ssh. Das ist etabliert, es gibt ausreichend viele Clients > und Serverimplementierungen dafür, und die als Grundlage eingesetzten > Bibliotheken werden auch gepflegt. Hallo Rufus (Groucho?), ich hatte versucht, Dir eine PM als private follow up zu schicken, aber das Forum gibt mir nur den in rot geschriebenen Kommentar "wrong answer" zurück. Kann ich Dich irgendwie offline bzgl. Nachfrage zum Thema kontaktieren? Danke!
Ruediger A. schrieb: > aber das Forum gibt mir nur den in rot geschriebenen Kommentar "wrong > answer" zurück. Dein Browser ist falsch konfiguriert und zeigt deswegen das Captcha nicht an. > Kann ich Dich irgendwie offline bzgl. Nachfrage zum Thema kontaktieren? Mach das hier im Thread, dann können auch andere helfen und von den Antworten profitieren.
Angehängte Dateien:
-
LCN-PKE.png
81 KB
So, ich wollte mal über den ersten Kontakt mit der LCN-PKE berichten. Es war einfacher als ich dachte. Ich programmiere meine Projekte mit Xojo (früher RealBasic und RealStudio) für Mac, Win und Raspi. Das PKE-Modul stellt also einen simplen Telnet-Server bereit, auf TCP-Port 4114. Man connectet einfach das Socket, wartet 100ms (damit die "Begrüßung" und die Firmware-Version vorbei gehen und der Server nach dem Usernamen fragt. Im Auslieferungszustand lauten User und Password "lcn". Man schreibt nun den Usernamen ins Socket, gefolgt von LF. Dann warte ich weitere 100ms und sende das Passwort, ebenfalls gefolgt von einem LF ... Danach kommen nur noch die Bustelegramme (alle Telegramme von allen Komponenten, die auf diesem Segment unterwegs sind) im ASCII-Modus, getrennt duch LF. Die sehen z.B. so aus: M000022.A1100 ... was soviel heisst, wie "modul 22 schaltet Ausgang 1 auf 100%" ... Alles in Allem ziemlich leicht zu parsen. Mit einem vorgestellten ">" kann man die gleichen Befehle auch in das LCN-System hineinschreiben, um selber Schaltungen auszuführen. Cool.
:
Bearbeitet durch User
@TO Bin wahrscheinlich ein bischen zu spät, da Du offenbar schon was gefunden hast. Ansonsten hätte ich Dir empfohlen, das Du dir mal die Indi direkt Komponenten anschaust. Da gibt es einen Telnetclienten der recht komfortabel funktioniert - ich hatte da mal was vor längerer Zeit gemacht, das war allerdings in Delphi. Die Komponenten wurden mal für Delphi geschrieben aber es gibt sie auch für C++Builder, Freepascal und .NET. Ob es die auch für Deine Umgebung gibt kann ich nicht sagen. Evtl. könnte man auch eine DLL schreiben.
Kleiner Nachtrag: Man könnte sicher die relavanten Sachen auch in Deine Umgebung portieren. Das wie kann man sich bei diesen Komponenten bestimmt gut abschauen, da selbige im Quellcode verfügbar sind. Schau mal hier https://www.indyproject.org/
Zeno schrieb: > @TO > Bin wahrscheinlich ein bischen zu spät, da Du offenbar schon was > gefunden hast. Ansonsten hätte ich Dir empfohlen ... Ja, danke der "Anteilnahme". Ich verwende schon seit 15 Jahren dieses Xojo bzw. seine Vorgänger, weil man da aus dem gleichen Sourcecode auf Knopfdruck für Win, Mac und seit Kurzem auch für Raspi compilieren kann. Und ich brauche auf dem Zielsystem kein JRE o.ä. Als nächstes versuche ich mal das Gleiche mit einem Arduino oder ESP8266, weil diese Dinger nat. wegen des fehlenden OS eine wesentlich bessere Langzeit-Stabilität aufweisen.
Zeno schrieb: > Kleiner Nachtrag: > Man könnte sicher die relavanten Sachen auch in Deine Umgebung > portieren. Das wie kann man sich bei diesen Komponenten bestimmt gut > abschauen, da selbige im Quellcode verfügbar sind. Schau mal hier > https://www.indyproject.org/ Habs mir mal angesehen - ist für das, was ich brauche, um ein Mehrfaches zu umfangreich ... und (kann mich irren) nur für Windows. Wie schon geschrieben, mein "Problem" konnte ich mit einer handvoll Kommandos zum Lesen und Schreiben in ein TCP-Socket lösen.
:
Bearbeitet durch User
Frank E. schrieb: > Man connectet einfach das Socket, wartet 100ms (damit die "Begrüßung" > und die Firmware-Version vorbei gehen und der Server nach dem Usernamen > fragt. Im Auslieferungszustand lauten User und Password "lcn". > > Man schreibt nun den Usernamen ins Socket, gefolgt von LF. Dann warte > ich weitere 100ms und sende das Passwort, ebenfalls gefolgt von einem LF > ... Das klingt etwas ungeschickt. Einfach nur warten und dann Daten senden ist problematisch, Du solltest die empfangenen Daten schon auswerten und erst auf das "User"-Prompt (oder wie auch immer es aussieht) mit dem Benutzernamen und auf das "Passwort"-Prompt mit dem Passwort reagieren. Wenn aus irgendeinem Grund (Gefrunzel im Netzwerk durch irgendwelche Störungen o.ä.) das Gerät etwas länger braucht als die von Dir angenommenen 100 msec, kommt Dein so beschriebener Algorithmus aus dem Takt. Aber vielleicht machst Du das ja auch schon so und hast das nur etwas ... seltsam beschrieben. Wie auch immer: Du siehst, auch bei so "hochkomplexen" Geräten wird einfach nur mit Wasser gekocht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.