When you’re working with client/server computing, a general terminal or a terminal
emulator is used to send and receive data from the host. Because of this, the terminal
or the PC that is running a terminal emulator needs to somehow be connected to the
server or mainframe computer. Otherwise, data transmission is not possible.
There are several different methods that can be used to connect the two. Among
them are serial cables (directly linked to the server), modems (for dial in ports)
and existing networks (LAN, WAN Internet). In the past, the most commonly used
method of connecting a terminal to a server over a network was Telnet. Telnet is
a connection protocol (i.e. a standard or an agreement on how data is encoded
and sent) with one major drawback: all data is exchanged without any form of encryption.
Telnet may be sufficient in a corporate environment where LAN cables and
infrastructure are controlled by the owners, but it presents a serious security risk
when you’re transmitting over a wide area or using public lines. The problem is,
anybody in between with some network knowledge and tools can monitor the data
exchange – even down to details like usernames, passwords and data that is entered
via keyboard or being displayed on the screen. In fact, it can be compared to
tapping a phone line and listening in to the conversation.
Because of the ever-increasing demand for security, the SSH (Secure Shell)
protocol was developed. SSH uses advanced encryption technology to encrypt
every single piece of communication between the client (called SSH Client) and the
server. Should an unauthorized third party be able to intercept traffic somewhere
along the communication path, they will see nothing but completely useless data.
There are other benefits to using a SSH Client. On top of the encryption of
the data transfer, the SSH protocol also offers verification that you’re connected
to the correct computer. This may seem surprising, but it makes perfect sense. Keep
in mind that if somebody were able to control any part of the communication path,
they could actually reroute the traffic to another computer. This could then play
the roll of the computer which you actually wanted to connect to, and could either
display fake data or obtain information from the client computer – both of which
could be equally damaging. When you use a SSH Client, you never need to
worry about these kinds of scenarios.
A good SSH Client needs to be able to connect to various different servers.
In order to do this, it has to support two versions of the SSH protocol.
The first version, SSH v1, has been improved and is now called SSH v2. To put it
bluntly, the second version of the SSH protocol actually covers security
risks that most average users are bound to place in the realm of total
paranoia – so with SSH v2, there’s really no need to worry!
A SSH Client should also support different authentication methods. These
include username/password, public/private key, and various custom formats. The
latter might include a system where the server could obtain information that only
the authorized users know, e.g. by using a SecurID card or by sending an access
code to the user’s mobile phone.