7.4. Remote connection services: telnet and ssh

7.4.1. Telnet and telnetd

Telnet is a (client) command used to communicate interactively with another host that executes the daemon telnetd. The telnet command may be executed as telnet host or interactively as telnet, which will enter the "telnet>" prompt, and then, for example: open host. Once communication has been established, we must enter the user and the password with which we wish to connect to the remote system. There are various commands (in the interactive mode), such as open, logout, mode (defines the visualisation characteristics), close, encrypt, quit, set, unset, or you may execute external commands with '!'. You may use the /etc/telnetrc file for default definitions or .telnetrc the definitions of a particular user (these must be in the user's home directory).

The telnetd daemon is the telnet protocol server for the interactive connection. Telned is generally started up by the inetd daemon and it is recommended that a tcpd wrapper (which uses the access rules in host.allow and host.deny) be included in the telnetd call within the /etc/inetd.conf file (for example), include a line such as:

telnet stream tcp nowait telnetd.telenetd /usr/sbin/tcpd /usr/bin/in.telnetd)

To increase the system's security, please see the unit on security. In some distributions (Debian 3.0 or higher), inetd's functions can be replaced by xinetd, which means that the /etc/xinetd.conf file must be configured (see the unit on the network administration). Likewise, if you wish to start up inetd in test mode, you can use the sentence /etc/init.d/inetd.real start. If the /etc/uissue.net file is present, telnetd will show its contents when logging in. It is also possible to use /etc/security/access.conf to enable/disable user logins, host logins or user group logins, as they connect.


It should be remembered that, although the telnet-telnetd pair may function in encrypt mode in the latest versions (transfer of encrypted data, although they must be compiled with the corresponding option), it is an absolete command (deprecated), mainly due to the lack of security, although it can still be used in secure networks or in controlled situations.

If it has not been installed, we can use (Debian) apt-get install telnetd and then verify that it has been registered either in /etc/inetd.conf or in /etc/xinetd.conf (or in the directory in the files are defined, for example, /etc/xinetd.d as indicated in the previous file with the sentence includes /etc/xinetd.d). xinetd.conf or /etc/xinetd.d/telnetd should include a section such as (any modification in xinetd.conf must reboot the service with service xinetd restart):

service telnet
disable = no
flags = REUSE
socket_type = stream
wait = nouser = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID

Instead of using telnetd, we recommend using SSL telnet(d) which replaces telnet(d) using encryption and authentication through SSL or using SSH (next section). SSLTelnet(d) may work with telnet(d) normally in both directions, as, when beginning communication, it verifies whether the other peer supports SSL and if not, it continues with the normal telnet protocol. The advantages compared to telnet(d) are that the passwords and data do not pass through the network in the plain text mode and anyone using, for example, tcpdump will be able to see the contents of the communication. Also, SSLtelnet may be used to connect, for example, to a secure web server (for example https://servidor.web.org) by simply executing: telnet server.web.org 443.

7.4.2. Secure shell or SSH

An advisable change is to use ssh instead of telnet, rlogin or rsh. These latter commands are insecure (except for SSLTelnet) for various reasons: the most important is that all that is transmitted through the network, including the user names and passwords, is in plain text (although there are encrypted versions of telnet-telnetd, they must coincide in that both of them are encrypted), anyone that has access to that network or any segment of that network will be able to obtain all that information and then assume the identity of the user. The second is that these ports (telnet, rsh,...) are the first place at which a cracker will try to connect. The ssh protocol (in version OpenSSH) provides an encrypted and compressed connection that is much more secure than, for example, telnet (it is advisable to use version 2 of the protocol). All current distributions incorporate the ssh client and the sshd server by default. ssh

To execute the command, proceed as follows:

ssh -l login name host o ssh user@hostname

Through SSH we can encapsulate other connections such as X11 or any other TCP/IP. If we omit the parameter -l, the user will connect to the same local user and in both cases the server will ask for the password to authenticate the user's identity. SSH supports different authentication modes (see ssh man pages) based on the RSA algorithm and the public password.

It is possible to create the user identification passwords using the command ssh-keygen -t rsa|dsa. The command creates in the user .shh directory the file id_rsa and id_rsa.pub, the private and public key respectively (for exemple, for RSA encryption algorithm). The user could copy the public key (id_rsa.pub) on the remote machine in the .ssh directory of the remote user, in the authorized_keys file. This file will be able to contain as many public keys as sites from which a remote connection to the machine will be wanted. The syntax is of one key per line and is equivalent to the .rhosts file (although the lines will have a considerable size). After entering the public keys of the user-machine into this file, this user will be able to connect from that machine without needing a password.

In normal mode (without creating the keys), the user will be prompted for a password, but the communication will always be encrypted and will never be accessible to other users who could be listening in on the network. For further information, see man ssh. In order to execute a command remotely, simply:

ssh -l login name host_remote_command

For example:

ssh -l user localhost ls -al sshd

The sshd is the server (daemon) for ssh (if not installed, it can be installed using apt-get install ssh which will install the server and the client). In combination, they replace rlogin, telnet, and rsh and provide secure and encrypted communication between two insecure hosts in the network.

This will generally start up with the initialization files (/etc/init.d or /etc/rc) and wait for connections from clients. The sshd of most current distributions supports versions 1 and 2 of the SSH protocol. When the package is installed, it creates a specific RSA key of the host, and when the daemon boots, it creates another, the RSA for the session, which is not stored on disk and changes every hour. When a client initiates communication, the client generates a random number of 256 bits which is encrypted together with the two keys of the server and sent. This number will be used during the communication as the session key to encrypt the communication using a standard encryption algorithm. The user may select any of the available ones offered by the server. There are some (more secure) differences when using version 2 of the protocol. Then, some of the user authentication methods described in the client are initiated or it will ask for the password, but always with the communication encrypted. For further information, see the sshd man pages. Tunnel over SSH

Often we have access to an sshd server, but for security reasons not to other non-encrypted services (for example a POP3 mail service or X11 windows server) or simply we wish to connect to a service that can only be accessed from the company environment. To do so, it is possible to establish an encrypted tunnel between the client machine (for example with Windows, running a free software ssh client called putty) and the server with sshd. In this case, when we connect the tunnel to the service, the service will see the request as if it were coming from the same machine. For example, if we want to establish a POP3 connection on port 110 of the remote machine (which also has an sshd server) we will execute:

ssh -C -L 1100:localhost:110 user-id@host

This command will ask for the password of the user-id over the host and, once connected, the tunnel will have been created. Every package sent to the local machine over port 1100 will be sent to the remote machine localhost over port 110, which is where the POP3 service listens (option -C compresses the traffic through the tunnel).

Making tunnels over other ports is very easy. For example, let's suppose that we only have access to a remote proxy server from a remote machine (remote login) – not from the local machine –, we can make a tunnel to connect the navigator through the tunnel in the local machine. Let's suppose that we have a login on a gateway machine, which can access the machine called proxy that runs the Squid proxy server over port 3128. We run:

ssh -C -L 8080:proxy:3128 user@gateway

Once we have connected we will have the tunnel listening over local port 8080, which will redirect traffic from the gateway to the proxy to 3128. To navigate securely, all we will need to do is http://localhost:8080/