Present location: Hjem --> Annet --> Artikler --> Telnet (eng)

Norsk versjon

Telnet

Written by: Peder Sverdrup, January 2013

Contents List of figures

1. Introduction

Telnet is client-server software to access and control a remote machine (the server). During a Telnet session, the client machine receives a command interpreter window from the server machine. Depending on user rights, the client can read, write and execute commands on the server. There is no graphics or mouse interaction. Telnet is an alternative to Remote Desktop (which has graphics and mouse interaction). In mixed environments, with several different operating systems, Telnet is especially useful: a UNIX client can usually connect to a windows server, etc. Telnet uses less resources than other remote management tools, because there is no graphics and no encryption. A client and server often comes with the operating system, so usually no need to install extra software.

Windows XP Professional comes with both a Telnet server and a Telnet client. Our lab consists of several Windows XP machines, and we will explore how Telnet works when connecting these machines under different network conditions.

2. The XP Telnet server and client

3. Telnet on the LAN

Setup: two Windows XP Professional 32-bit machines, on the same LAN. There is no windows network domain, and they are not in the same workgroup. In my setup, the client has IP 10.0.0.10, and machine name (NetBIOS): plutotech. The server has IP 10.0.0.11, and machine name: oes.

In my setup the client has an english XP Pro version, the server has a norwegian XP Pro version. I assume this difference in OS language does not influence this demonstration.

Initially, we want the configuration of the server and the client to be "vanilla", that is, unchanged with respect to how it comes with a new XP install.

3.1 Server configuration

You need to be Administrator on the server to change configuration. At your server, open the XP command interpreter (cmd). We use the command-line programs sc, tlntadmn and net to configure the server. To get help, you can for instance do sc, sc qc, tlntadmn /?, net help or net /?. sc is short for ServiCes (or Service Configuration?), and qc is short for Query Configuration.

We want the server to be started manually (not automatically on machine boot, because of security), and we do not want it to be disabled. Query server configuration with:

sc qc tlntsvr

Check that START_TYPE is set to 3 (Demand). If not, change the setting with the command

sc config tlntsvr start= demand

(There is a space after the =).

Check further server configuration with:

tlntadmn

The server should be listening on port 23. Both Password and NTLM should be allowed for logon authentication. If any of these settings are missing, they can be corrected with:

tlntadmn config port = 23

tlntadmn config sec = +NTLM

tlntadmn config sec = +passwd

If the server is not running (State is Stopped), manually start the server:

sc start tlntsvr

Alternatively: tlntadmn start, or: net start tlntsvr, or: net start telnet, or start the server from services.msc in the Control Panel. Two more commands to check server status: sc query tlntsvr and sc queryex tlntsvr.

I now have the following configuration:

C:\Documents and Settings\odd>tlntadmn
The following are the settings on localhost
Alt Key Mapped to 'CTRL+A' : YES
Idle session timeout : 1 hours
Max connections : 2
Telnet port : 23
Max failed login attempts : 3
End tasks on disconnect : YES
Mode of Operation : Console
Authentication Mechanism : NTLM, Password
Default Domain : OES
State : Running
C:\Documents and Settings\odd>

We now need to configure the Windows firewall.

3.2 Client configuration

On your client machine, start the client (telnet.exe) from Run. Alternatively, you can open a command interpreter and run the client from there. In both cases, you end up with a Telnet command prompt (the Telnet client has its own command interpreter). To get help in this window, type ?/help

Type d to check the client configuration (operating parameters):

d

Microsoft Telnet> d
Escape Character is 'CTRL+"'
Will auth(NTLM Authentication)
Local echo off
New line mode - Causes return key to send CR & LF
Current mode: Console
Will term type
Preferred term type is ANSI
Microsoft Telnet>

We see that the client is able to use NTLM authentication. If it were not, do:

tlntadmn config sec=+NTML

3.3 Remote login

We are now ready to log into the server. We are going to see that with both simple user/password authentication, and with NTLM authentication, we log in with the credentials of a valid server Windows account. However, there are differences in how the credentials are entered, and transmitted over the network.

On your client machine, start the client (telnet.exe) from Run. Type o to Open a telnet connection:

o

Enter the server IP (or the machine name).

You are about to send your password information to a remote
computer in Internet zone. This might not be safe. Do you
want to send anyway(y/n):

Answer y. You will get a message:

Access Denied: Specified user is not a member of TelnetClients group.
Server administrator must add this user to the above group.
Telnet Server has closed the connection
Connection to host lost.
Press any key to continue...

Now try again, this time answer n. You will then be asked for a username and password:

Welcome to Microsoft Telnet Service
login: odd
password:

For now, not worrying about security, log in with user/pass for an Administrator user on the server. You should get logged in and receive a command interpreter for the server.

*===============================================================
Welcome to Microsoft Telnet Server.
*===============================================================
C:\Documents and Settings\odd>

So, what is happening here? With Telnet, you can choose between two different ways of authenticating:

  1. Simple user/password authentication without encryption. Both user and password is sent in plaintext over the network. The client authenticates by entering
    • User/pass for an Administrator account on the server machine.
    • User/pass for a limited account on the server machine, only if this server account is member of the group TelnetClients (check lusrmgr.msc).
    If you add the server Guest account to TelnetClients, and try to log in, you get the error message "Telnet connection not allowed to the Guest account".
  2. NTLM (New Technology Lan Man) authentication. With this method, the password is never transmitted in plain text over the network. No username or password is entered from the keyboard. Telnet uses the credentials (meaning: username and password) of the Windows user at the client machine, to log into the Telnet server. This means that the client Windows account, must have its twin-account (same username and password) on the server, for login to be possible. The following rules apply:
    • On the server, the Local Security Settings (secpol.msc): Security Settings - Local Policies - Security Options - Network access: sharing and security model for local accounts. The tab Local Security Settings has two options: Classic - local users authenticate as themselves, and Guest only - local users authenticate as Guest. To get access to a running Telnet server, one needs to choose the Classic option. Because Guests do not get Telnet access.
    • A client administrator account can log into a server administrator account.
    • A client administrator account can log into a server limited account, only if the server account is member of TelnetClients group.
    • A client limited account can not log into a server administrator account.
    • A client limited account can log into a server limited account, only if the server account is member of TelnetClients group.

Now we will try to explain the login process just witnessed. When answering y to the question, one chooses NTLM. The following error message occurs because the client Windows account had no twin on the server, and/or the Local Security Settings were misconfigured. Then, when one answers n, one chooses simple user/password login. This mechanism is simpler and less secure. When the client is configured to use both NTLM and user/pass, NTLM is tried first. If NTLM does not succeed, the client tries user/pass.

3.4 Logon analysis with Wireshark

Wireshark is a program that reads individual data packets off your network card, and lets you view their raw contents. Wireshark also has advanced packet analysis tools for many different protocols, including TCP/IP and Telnet. Installed on the client machine, Wireshark monitors all packets entering and leaving the computer. When telneting to another machine, Telnet packets show up. By reading individual packets, and then collocating -- "Follow TCP Stream" in Wireshark -- it is possible to analyze the information flow. We will try to get some insight into how Telnet authentication works.

The server has an administrator account with the username "odd" and the password "kampen", and these are the credentials we will use to gain access. The server machine name is "plutotech".

3.4.1 User/password

Figure 1 shows Wireshark when logging in with simple user/password. It is clear that:

Wireshark window, Telnet login using simple user/password

Fig. 1 Wireshark, Telnet login using simple user/password

3.4.2 NTLM

Figure 2 shows what is transmitted when logging in with NTLM: Wireshark window, Telnet login using NTLM, with admin user odd

Fig. 2 NTLM, with admin user odd

Wireshark window, Telnet login using NTLM, with admin user billyboy

Fig. 3 NTLM, with admin user billyboy

Wireshark window, Telnet login using NTLM, with limited user oddlim, member of TelnetClients

Fig. 4 NTLM, with limited user oddlim, member of TelnetClients.

Wireshark window, Telnet login using NTLM, with limited user oddlim, not member of TelnetClients

Fig. 5 NTLM, with limited user oddlim, not member of TelnetClients.

4. Telnet on the WAN

So far the server and the client have been on the same Local Area Network. We will now see how Telnet works when this is not the case. The lab now consists of two geographically separate locations:

  1. Aurskog: the server location.
  2. Vinterbro: the client location.

4.1 Server configuration

4.2 Client configuration

Check that the client can initiate NTLM authorization.

4.3 Remote login

You should now be able to log into the Telnet server by using the Aurskog router WAN address and the port 1006. Remember that to authenticate with NTLM, your active account needs to have a twin-account on the server (it could be any server account, it does not have to be the account from which you started the Telnet server). If the Aurskog router has a dynamic IP address, and the router supports dyndns, you might want to sign up for a free account, and use you dyndns hostname instead of the router IP.

Windows XP is primarily a workstation, not a server, so server software may be a bit buggy. If you are not able to start the Telnet server, you may try to reboot your machine.

5 Remote configuration with sc.exe

So far in this paper it has been assumed that one has local access, or local access via Remote Desktop, to all the machines, when using sc.exe to configure. Here we will look at the possibility of directly using the configuration program sc.exe to configure a remote machine.

5.1 On the LAN

We would for instance like to run commands lik:

sc \\10.0.0.11 query tlntsvr

sc \\oes query tlntsvr

We want to sit at the client machine when running such commands.

When the client and server machines are on the same LAN, this is easy:

5.2 On the WAN

We have been trying to set up a connection where we can reach a computer on the WAN with sc.exe. However, we are not able to make this work. When trying to reach the Aurskog computer with sc.exe from the Vinterbro computer, we can see traces of the attemt in the Aurskog ruter log. We are not able to observe the attemt at the Aurskog computer. One problem is that sc.exe varies the ports it uses to connect to the Aurskog router. It does not use one fixed port. Which makes it difficult to know which ports to forward to the Aurskog computer.

From a bit of web research, it seems like the XP sc.exe version can not be used for connections outside the LAN. However, we are not 100% sure of this.

Further topics to research this:

6.0 Other Telnet clients

6.1 Hyperterminal

You can use the Windows program Hyperterminal as your Telnet client. To connect from the command line:

C:\>"c:\Program Files\Windows NT\hypertrm.exe" /t url:port

or

C:\>"c:\Program Files\Windows NT\hypertrm.exe" /t ip:port

Hyperterminal window, Telnet login

Fig. 6 Hyperterminal

7.0 Other Telnet servers

7.1 Cisco routers with IOS

To configure a Cisco router with the IOS, one typically logs into the device with Telnet. Many other routers also have similar capabilities, however with OS that is less configurable, and less adapted to command-line configuration.

8.0 References

  1. How Telnet works
    http://technet.microsoft.com/en-us/library/cc778139(v=ws.10).aspx
  2. Configure the TCP Port Number Used by Telnet Server
    http://technet.microsoft.com/en-us/library/cc771200(v=WS.10).aspx
  3. Configure the Telnet Terminal Type
    http://technet.microsoft.com/en-us/library/cc771967(v=ws.10).aspx
  4. Switch Between Session Mode and Command Mode
    http://technet.microsoft.com/en-us/library/cc725905(v=ws.10).aspx
  5. The NTLM Authentication Protocol and Security Support Provider
    http://davenport.sourceforge.net/ntlm.html
Phone: 67 20 71 21 / 92 60 51 57 Arpanet, logic map, March 1977