The Mabry Software Telnet/X COM object and ActiveX control implement several client-side protocols that can connect to a remote character- based service and carry out various tasks. Supported protocols are: Telnet, RLogin (remote login), RExec (remote execution of one command), RSH (remote shell), and SSH (secured encrypted shell).

Telnet/X has implemented internal automation so you can make it fully scripted. Using the 'PromptString' property, you can make it wait for a command prompt from the remote host. You can then issue a command, wait for the result of that command, examine the result, and then either issue new commands or just disconnect. And it's all fully automated with an easy-to-use interface.

Or, if you need a manual chat with the remote server using terminal emulation, check out our samples and see how to make simple (or even advanced) applications that chat with remote servers at your request. Telnet/X supports automated logins, automated execution of commands, firing events for all needed situations. Of course, you can disable all of those options if you want raw information about the data that is transferred between your computer and a remote host.

Using SSH-1, you can be sure that your connection cannot be tampered with or examined by a 3rd person - and you do it just by changing one property value! For you, it's fully transparent - use SSH or fallback to RSH if the server doesn't support SSH. Make Telnet/X worry about that for you.

And, if speed is a real concern for you, Telnet/X supports the Fast Notification Interface instead of events, if speed is a real concern for you.

Overview

Telnet/X is a component that is able to connect to console-type remote servers. These servers usually run on UNIX based computers. Telnet/X can be used not only as a Telnet client, but also as an RSH (remote shell), REXEC (remote exec), RLogin (remote login) and SSH (secure shell).

Using Telnet/X's friendly component interface, you can configure Telnet/X for different script- like programs. You can easily connect to a server, execute specific code, wait for results, and return. You can also implement different GUI based applications, such as Terminals and Remote administration programs. You can make Telnet/X work silently and execute several different programs at once, waiting for each one to finish. Using very little VB programming knowledge, you can easily interactively connect to a server, execute commands that you specify, receive the results, etc.

With SSH mode, Telnet/X will make a completely secure, private connection that is useful for different types of network sniffers and analyzers. All that is required on the server side is any type of service running the SSH1 protocol.



Tutorial

We will attempt, in a few steps, to show you how easily you can get to know Telnet/X. Just like other Mabry components, Telnet/X contains a main COM object which actually contains all the of the Telnet/X code, plus you have an OCX wrapper that calls the COM object for you. If you want, you can use the COM object directly, but this requires a bit more work to be done on your application.



Add Telnet/X to Your Program

ActiveX: To use the Telnet/X ActiveX control (OCX) with your applications, you need to add a reference to it in your VB program. This is easy - - just open the VB application you are currently working on, click on the 'Project' menu, then on the 'Components' submenu. On the newly opened dialog, find the 'Mabry Internet Telnet/X Control' and click on OK.

COM Object: For advanced VB users, we would suggest using the COM object instead of the OCX wrapper. This requires a little more work, but it will result in a faster response from Telnet/X because one less 'step' is used in communication between your application and Telnet/X. To do this, click on 'Project', then on 'References' and find the 'Mabry Telnet/X COM Object'.



Add Telnet/X to Your Form

ActiveX: Adding Telnet/X to your form is easy. Just drag it from the component toolbox and drop it on your form. Or, click on Telnet/X in the toolbox and make a bounding rectangle for it on the form. However, Telnet/X is a Windowless component - it doesn't show any content graphically. It has no window, so no matter what you select for your window, it will always reduce itself to icon size.

COM Object: If you want to use the COM object, you have to switch to the code view. Then, in the General section, add a line like this.

Dim WithEvents TelnetX As TelnetXCom Also, in Form_Load you need to initialize the COM object, and in Form_Unload you have to release it, like this

Private Sub Form_Load()
Set TelnetX = New TelnetXCom End Sub

Private Sub Form_Unload(Cancel As Integer)
Set TelnetX = Nothing
End Sub

Setting Properties Prior to Establishing a Connection

Before you actually establish a connection with a server, you need to specify a few required properties for Telnet/X. The most basic properties are the Host and Port for the remote server. Host depends on the remote server that you intend to use, and Port varies from service to service. If you're using a Telnet server, use port 23. For RExec use 512, for RLogin use 513, for RSH use 514. Finally, if you want to use secured SSH, use port 22. Note: these are default values. It is possible that your remote server uses different ports for its services, in which case you need to contact the system administrator of that particular server.

Next, you must choose the Protocol type, as described above. The most common is, of course, the Telnet protocol. You cannot mix different Protocol types with different ports (unless the server is configured that way). However, for various tests, you can always use the Telnet protocol with other server types such as POP3 and SMTP. You cannot actually change Telnet/X to make your application POP3 or SMTP compliant - but you can manually implement commands for those protocols, which is very handy as a testing tool.



Automating Logon to a Server

All of the protocols that Telnet/X implements require authentication to the remote server, usually by responding to 'Username' and 'Password' queries sent by the server. You can easily authenticate with the server using the Send method to supply your credentials.

In addition, Telnet/X can automatically authenticate with the Telnet protocol. Set the AutoLogon property to True and put the proper values in the LogonName and LogonPassword properties. Telnet/X will send these values when the server requests them.

All of the protocols except the Telnet protocol require that authentication is set before you can actually send or receive anything else. For this purpose, when you select the Protocol Type to be RSH RExec, RLogin or SSH, the AutoLogon property is automatically set to True and you will not be able to change it back to False.



Automating Commands Executed On The Server

RExec requires it, others support it! What I'm talking about here is the LogonCommand property. If you put anything in this property, then Telnet/X will, upon a connect, immediately issue this command. It will then wait for results to complete, send you a response, and disconnect from the server. This is very handy when you need to execute something like a script. You can prepare a batch file on the server, put a few arguments in the LogonCommand script name, and just let Telnet/X do the entire job for you. Nice!



Connecting to the Server

This is the easy part. Once you set up the basic properties, you then call the Connect method with its optional Host and Port parameters. Telnet/X will attempt to connect to the remote server and will fire the Connected event if successful. If Telnet/X is unable to connect, then the LastError property will hold the error that occurred. The state will be set to StateNotConnected.



Communicating with the Server

To send and receive data from the server, you will use the Send and Receive methods. You can actually try to receive data only when the Received event is fired by Telnet/X, informing you that there is data to be read that has arrived from the server. You can use the Send and Receive methods until the connection is closed - either if you closed it with the Disconnect method, or the server closed the connection.



Using The Prompt Event To Decide When To Send The
Next

Using the Prompt Event to Decide When to Send the
Next Command

When there is scripting involved in
communication, there is always a question of
*when* to send the next command if you have more
than one in a sequence.

For instance, you may want to delete a file on a server. You will need to send the 'ls' command (list files), determine what files reside on the server, and delete 'rm' one of them. If you try to send 'ls' and then wait for some time - the question is, how many seconds/minutes of inactivity must occur until you can actually send a new command or examine data. Telnet/X has the answer for you.

If you have noticed, when you connect to a Telnet
server, it replies with a prompt like this:


testacc:~>
or

joe:/home/users/joe> The server has identified you as user 'joe' who is currently in the directory '/home/users/joe'. This is called the 'prompt string'. Telnet/X has a PromptString property where you will store a string identical to the server's. So, when Telnet/X receives this prompt from the remote side, it will fire the Prompt event - thus informing you that *most probably* the server is ready to accept a new command. With tracking of the Prompt event, you can execute several commands exactly at the right time.

The code below is an example of using the Prompt
event:

Private Sub Form_Load()


DidSendCommand = 0
' here goes code for authentication
' put prompt you expect to be received
TelnetX1.PromptString = "test@yourprompt:~"
' put telnet hostname
TelnetX1.Connect "test.server.com", 23
End Sub
Private Sub TelnetX1_Prompt()
Dim a As String

a = TelnetX1.Receive(vbString)
Select Case DidSendCommand
Case 0
TelnetX1.Send "ls -al" & vbCrLf
DidSendCommand = 1

Case 1
TelnetX1.Send "exit" & vbCrLf
DidSendCommand = 2
End Select

End Sub The above code will first execute 'ls -al' which
retrieves a directory listing. Then it will send
a command to logout from the server.



Using a Secured Connection

In SSH mode, with Telnet/X's Protocol property set to SSH1, Telnet/X can establish a secure connection with a remote server running an SSH1 service. You can optionally use the Encryption property to specify what encryption is used. After the connection is established, your data will flow 'transparently' for you - whatever you send (in plain text) will be received by the server just as you sent it. But, during transmission, the data will be encrypted and anyone who is spying on your connection will not be able to see what data has been sent, including your password.

One thing to check - when a connection is established, the SSHCheckServerKey event will fire and the ServerKey variable will hold the server key. This is a server's public key which should never change. The SSH protocol is based on 'trust' - once you trust that the remote side has a valid public key, you should verify that it is the same key on each new connection. So, store this value the first time you connect, and check it on each new connect. If the key has changed, there is a possibility that someone is spying on your connection.



Choosing the Terminal Type

Usually, most console-type servers need specific terminal implementation in order that the keyboard and screen are mapped properly. The most common terminal types are ANSI and VT100 - but there are many more types. Using terminal types like this, you are able to, for example, clear the screen on a remote console, delete one line, use backspace, delete, etc - capabilities which are not enabled if the remote terminal is only in the so-called 'teletype' mode.

Telnet/X doesn't implement any specific terminal, but allows you to define any type you need. Telnet/X has a TerminalType property that can hold 3 values - None, Manual and Automatic. If you set it to None, then Telnet/X responds to special commands (such as clear screen, for instance) with the reply 'unable to perform operation' - of course in the protocol's language. This is common behavior. It will happen every time you use the Telnet protocol, because, on primary negotiation, the server always sends a few options. Setting the Telnet/X TerminalType to None will reply with 'deny' on all such options.

If you set the property to Automatic, Telnet/X will implement the few terminal options of which it is capable (without knowing your actual needs). These options include the BS character (backspace), line speed (regular modem connection - don't worry if you're faster than that), BELL character, window size (80x25) etc.

If you set it to Manual, Telnet/X will fire the SpecialCode event each time there is some special code sent by the server. Special codes vary depending on the protocol that is used with Telnet/X. In general, these are ASCII codes that are not printable (once more - only in general). Your job is to implement those codes as you wish - which means that you will implement some sort of Terminal emulation by yourself. Please note that you must know the protocol used to be able to correctly reply to such special codes.



Using Proxy Firewalls

In case you don't have direct access to the Internet and you are forced to use a proxy, Telnet/X allows you to use several predefined proxies or to implement your own (we leave this up to you). The most common proxies are - TelnetProxy, Socks4, Socks5, HTTPProxy, and Pipe.

The TelnetProxy is the one most commonly used for Telnet protocols. When Telnet/X connects to such a proxy, the control sends the Host and Port properties. The proxy then connects to the destination server and passes all traffic between you and the server.

Socks4 and Socks5 are more general. Usually they are listening on port 1080. When Telnet/X connects to Socks4, it specifies some special codes and commands that the server interprets and uses to connect you to your destination server. It then starts relaying data.

The HTTPProxy is the most widespread. When Telnet/X connects to such a proxy, it sends the 'CONNECT' keyword and the proxy tries to connect to the remote side for you. If everything succeeds, you can talk to the remote side. Many HTTP servers also support this - you should check one running on your local network.

The PIPE relay does nothing - except it connects to that proxy and expects a real telnet server. The purpose of PIPE is that you can easily spy on your own connection and see what is actually transferred - for debugging purposes. Download Mabry Software's Firewall/X and test its PIPE SPY sample to see how this actually works.



Disconnecting From the Server

When the time comes to disconnect from a remote server, you have two options - to disconnect in the regular manner, or to disconnect with 'brute force'.

The regular way would be to send the 'exit' or 'logoff' command to the remote server and wait for the server to close the connection. If you do it this way, you will be sure that there are no processes left running on the server and that leaving the command prompt was 'clean'.

If, for whatever reason, you cannot disconnect in a regular manner, then you can use the Disconnect method that will just close the connection. Please note that sometimes the server does not know that you have disconnected and will keep you marked as 'logged on' for quite some time afterwards.



Using and Implementing the Fast Notification Interface

The Fast Notification Interface is a replacement for regular events. Its purpose is to avoid using the regular COM architecture and firing of events. The interface implements a few callback functions that you will have in your code, and Telnet/X will call them - just as it would fire an event. As a result, you will get a faster application.

Interface ITelnetXNotify (ITelnetXComNotify for the COM object) is the name of the interface that knows the structure and declaration of the callback functions. If you want to use fast notifications, you need to provide and implement *ALL* of the methods that are declared in the above interfaces. If you don't want to implement them - leave the bodies empty - but surely declare them.

So, what's the deal? Instead of having, e.g., the PromptString declared like this in your VB application,

Private Sub TelnetX1_Received(ByVal BytesCount As Long) Dim a As String

a = TelnetX1.Receive(vbString)
If DidSendCommand = 1 Then
Text1 = Text1 + a
End If
End Sub
you will have something like this

Private Sub ITelnetXNotify_Received(ByVal Object
As MabryTelnetXOCXLibCtl.ITelnetX, ByVal
BytesCount As Long)
Dim a As String

a = TelnetX1.Receive(vbString)
If DidSendCommand = 1 Then
Text1 = Text1 + a
End If
End Sub
This is what you need to do, step-by-step.
First, copy/paste this line into your code:

Implements ITelnetXNotify
If you're using the COM object instead, do this:

Dim TelnetX1 as TelnetXCom
Implements ITelnetXComNotify
Note that we don't use the WithEvents keyword
anymore - because we don't use events.

Immediately after adding this line, you will see that a new object is shown in the object list - ITelnetXNotify (ITelnetXComNotify). If you look closely, you will see that it has several methods - very similar to actual events. You need to click on all of them - at least so that their declaration is shown in the code view. If you don't do this, when you run your program you will get an error saying that 'not all methods are implemented'. Be careful here.

There is only one more thing to do - you need to let Telnet/X know that you will use the fast notification interface instead of events. You will do it like this:

TelnetX1.NotificationObject = Me You can also create new class and implement these notification methods in it, in which case you would put TelnetX1.NotificationObject = class1,

Download File Size:861.46 KB

---