People's Newsroom


A variety of popular tools that allow access to remote hosts (such as telnet, rsh, and rlogin) or that provide means for file transfer (such as rcp or ftp) exchange user credentials and data in plain text. This makes them vulnerable to eavesdropping, tampering, and spoofing attacks. Although the tools mentioned above could have also been built upon SSL/TLS, a different protocol suite called Secure Shell (SSH)has been developed which follows partial overlapping goals. The SSH Transport and User Authentication protocols have features similar to those of SSL/TLS. However, they are different in the following ways.

  • TLS server authentication is optional and the protocol supports fully anonymous operation, in which neither side is authenticated. As such connections are inherently vulnerable to man-in-the-middle attacks, SSH requires server authentication.
  • TLS does not provide the range of client authentication options that SSH does – public-key via RSA is the only option.
  • Most importantly, TLS does not have the extra features provided by the SSH Connection Protocol.

The SSH Connection Protocol uses the underlying connection, aka secure tunnel, which has been established by the SSH Transport and User Authentication protocols between two hosts. It provides interactive login sessions, remote execution of commands, and forwarded TCP/IP as well as X11 connections. All these terminal sessions and forwarded connections are realized as different logical channels that may be opened by either side on top of the secure tunnel. Channels are flow-controlled which means that no data may be sent to a channel until a message is received to indicate that window space is available.

The current version of the SSH protocol is SSH 2. It represents a complete rewrite of SSH 1 and improves some of its structural weaknesses. As it encrypts packets in a different way and has abandoned the notion of server and host keys in favor of host keys only, the protocols are incompatible. For applications built from scratch, SSH 2 should always be the preferred choice. Using the means of logical channels for interactive login sessions and remote execution, a complete replacement for telnet, rsh, and rlogin could be easily implemented. A popular site that lists open-source implementations which are freely available for many different platforms can be found under [14]. Recently, a secure file transfer (sftp) application has been developed that makes the use of regular FTP-based programs obsolete.

Notice that it is possible to tunnel arbitrary application traffic over a connection that has been previously set up by the SSH protocols. Similar to SSL/TLS, web and mail traffic could be securely transmitted over an SSH connection before reaching the server port at the destination host. The difference is that SSH requires that a secure tunnel is created in advance which is bound to a certain port at the destination host. The set up of this secure channel, however, requires that the client that is initiating the connection has to log into the server. Usually, this makes it necessary that the user has an account at the destination host. After the tunnel has been established, all traffic sent by the client gets forwarded to the desired port at the target machine. Obviously, the connection is encrypted. In contrast to that, SSL/TLS connects directly to a certain point without prior logging into the destination host. The encryption is set up directly between the client and the service listening at the destination port without a prior redirection via the SSH server. The technique of tunneling application traffic is often utilized for mail transactions when the mail server does not support SSL/TLS directly (as users have accounts at the mail server anyway), but it is less common for web traffic.

Back to top button