SSH and Telnet
Telnet is the standard terminal emulation protocol within
TCP/IP. Telnet is defined within RFC 854. Telnet allows
a user on a TCP/IP network like the Internet to login to another
computer on the network remotely. Of course this can be done
only if the user has the appropriate permissions on this remote
computer. But Telnet allows a user to access remote resources
as if the user had a local connection.
Telnet makes use of port 23.
It should be obvious that it is very important to control access to Telnet on machines and routers when setting them up.
Telnet is actually a relatively old protocol and has very little security. Information is passed across Telnet in the clear. Things that are passed in the clear includes usernames and passwords. So it should be obvious that Telnet is not something to be used in many situations.
The next discussion describes some situations where I have seen Telnet used.
SSH - Secure Shell. SSH - Secure Shell was designed to create much greater security in network functions. It relies on a set of functionalities and protocols that facilitate things such as the following.
Telnet originated quite early in the development of UNIX. In efforts to overcome the security vulnerabilities of Telnet, SSH was developed.
Efforts to improve on Telnet have included the following.
SSH has been developed to improve on these.
SSH makes use of both a client and a server that use public key cryptography to provide session encryption. SSH opens a secure transport between machines by making use of an SSH daemon running on each end. One daemon initiates communications using port 22. After this secure communications are carried out over higher numbered ports using appropriate modes. In addition, SSH includes the capabilities to forward to arbitrary/changing ports over an encrypted connection.
SSH starts the encrypted connection before a username and/or password are sent.
The security of public key encryption can be diminished considerably if a common key is used to initiate secure sessions across a variety of clients. If this key stays constant throughout a session, or even worse, stays the same for many sessions, it makes it much easier for someone to decrypt the original key. For example, think of what can happen with the WEP security approach for wireless connectivity. Each time an SSH session is established between a particular client and server a new session key for future sessions is established hidden by the existing encryption. This helps to limit the number of packets encrypted using any particular key. Unfortunately, I have yet to be able to determine a few things like the following.
Hopefully, you can think about the vulnerabilities posed by these sorts of concerns.
SSH was originally developed by a Finn named Tam Ylonen.
SSH can implement a variety of encryption approaches. SSH1 tried to make use of RSA algorithms, but they were still under patent. This helped motivate development of SSH2 which makes use of 3DES and other encryption approaches. At present, SSH can make use of a much larger variety of encryption methods such as the following.
SSH consists of the three major components listed below.
SSH is very popular in Linux and UNIX environments. It is often used to establish VPNs across networks. There are a variety of vendors who have built their own SSH solutions.
SSH has not been nearly as popular on Windows based machines. But the proliferation of SSH solutions for Windows clients demonstrates how often Windows clients interact with UNIX or Linux servers.
Establishing SSH Sessions. The following diagram represents how SSH sessions are established.
More will be added.