Table of Contents

• The Necessity of an Encrypting Shell-Client
• Technical SSH Basics
• Symmetrical Encryption
• Asymmetrical (Public/Private Key) Encryption
• Key Exchange
• Static Port-Forwarding
• Dynamic Port-Forwarding
• Other SSH Client Features and Requirements
• ZOC Terminal: A Modern SSH Client for Windows

The Necessity of an Encrypting Shell-Client

In the context of client/server computing, the transmission of data between the host and a terminal is facilitated through the utilization of a general terminal or a terminal emulator. In this scenario, it is imperative that the terminal or the personal computer executing a terminal emulator is appropriately linked to the server or mainframe computer.

Various methods exist for establishing the connection between the terminal and the server; historically, the prevailing approach for networked terminal-to-server connectivity was the utilization of telnet.

Nevertheless, the contemporary security landscape deems unencrypted transmission via telnet as a substantial security vulnerability.

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 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.

Technical SSH Basics

The basics of the secure shell (SSH) protocol are laid out in RFC 4253. The document describes SSH as a secure transport protocol that is provided by a server on tcp port 22 that provides strong encryption, cryptographic host authentication, and integrity protection.

Or, as RFC 4253 states in its intro:

The RFC defines ways to create an encryption key (that later serves to encrypt the traffic between client and server) in the possible presence of a listener. It also definesw host and user authentication methods (i.e. ways in which users and server can prove that they are who they claim to be), and possible data compression to more effectively transmit data.

An especially challenging part of encrypting such communication, is the need to negotiation a shared secret (an encryptino key) over a channel that might already be monitored. SSH answers this challenge through the initial key exchange phase of the connection using the older Diffie-Hellman kex method. Never versions now also support ED25519 elliptic curve kex. It is a specific implementation of the Edwards-curve Digital Signature Algorithm (EdDSA), which itself is a variant of Schnorr's signature system with Twisted Edwards curves (math heavy details can be found in the upcoming IETF standard for ED25519).

Symmetrical Encryption

Symmetrical encryption is a type of encryption where a key can be used to encrypt messages to the other party, and also to decrypt the messages received from the other participant. What makes the encryption symmetric the fact that the same key is used for encryption and decryption.

Symmetric encryption usually requires little computing power and is hence used to encrypt larger blocks of data. With SSH, it is used to encrypt the whole data stream.

Asymmetrical (Public/Private Key) Encryption

Asymmetrical encryption differs from symmetrical encryption in the fact that two different keys are used. One (any) of those two is used to encrypt the data and then the other is used to decrypt it. The benefit of this technique is that one party can give the other party a key to encrypt messages to you, but anyone knowing that key will still not be able to decrypt the message again. Such a key is called the public key. The other key, which is not shared and which is then used to decrypt the data block is called the private key.

This also works in the other direction. Data that was encrypted using the private key can only be decrypted using the public key. With SSH this fact can be used to prove identity. If a message is decryptable using the public key, it proves that whoever encrypted the message, is in possession of the private key.

Public/private key pairs are generated using the ssh-keygen tool or ZOC's built in key generator.

Key Exchange

An especially challenging part of encrypting such communication, is the need to negotiate a shared secret (an encryption key) between the ssh client and server, while the negotiation has to be initially performed on a channel that might already be monitored by a third party.

Think of the problem as such: You need to agree with someone else on a password, but you can only talk to each other about it over a phone line which you know could be tapped by the enemy.

SSH answers this challenge through the initial key exchange phase of the connection using the older Diffie-Hellman kex method. Newer versions now also support ED25519 elliptic curve kex. It is a specific implementation of the Edwards-curve Digital Signature Algorithm (EdDSA), which itself is a variant of Schnorr's signature system with Twisted Edwards curves (math heavy details can be found in the upcoming IETF standard for ED25519.

Static Port-Forwarding

Static port-forwarding (or tunneling) refers to situations where the desitination host and port are known in advance.

Programs and protocols which do not use data encrpytion (e.g. ftp or rsh) can connect to the tunnel's port on the local computer and the ssh client will transmit their data through the encrypted ssh connection to/from a final destination that is already known at the time when the ssh-connection is made.

For example, a user can set up a port-forwarding on the client software, listening on the client port 5514 and forwarding traffic to the address of an older device with a fixed IP address on the remote network that only supports the unencrypted rsh protocol.

Dynamic Port-Forwarding

As outlined above, static port-forwarding feature requires the client to set up the tunnel source port and destination before making the connection.

This problem is addressed by secure shell's dynamic port forwarding. With dynamic port forwarding, the client sets up a listening port (as with normal port fowarding), where a software that connects to the port can tell the client which host and port it wants to connect to. This is done in the same way that client software can request connections from a SOCK5 proxy.

The ssh client will then forward the connection request to the secure shell server which makes the connection to the destination host. This way, the ssh client could let an unencrypted rsh software access arbitrary rsh servers on the remote network through the encrypted data channel.

Other SSH Client Features and Requirements

In other words, there are many benefits to using SSH for connections. On top of the encryption of the data transfer and secure key exchange, the secure shell protocol also offers verification that you are 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 role of the computer which you actually wanted to connect to (this is called a man-in-the-middle attack), and could either display fake data or obtain information from the client computer. A feature called known_hosts can prevent this.

The SSH terminal should also support a variety of 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.

To be able to connect to various different servers, the ssh client it has to support latest key exchange and encryption protocols, because what seemed unbreakable five years ago, is considered less so today. Most server continually switch to more advanced encryption methods, ssh clients need to support these as well.

Other typical must have features for would be:

• ECDSA, ED25519, RSA and DSA public key authentication
• Port forwarding (tunneling connections from client to server through the ssh channel)
• Dynamic port forwarding (SOCKS like)
• Connection through proxy
• SFTP ans SCP file transfer
• X11 forwarding (allows to run x-windows programs on the remote server)
• PKCS#11 authentication (this allows authentication through hardware, e.g. smart cards)
• UTF8 support in terminal emulation

 
SSH Connection via Proxy
In some environments, end user computers are not allowed to access the outside internet directly. In those cases, connection and data exchange is made by way of a ssh proxy which handles the actual connection to the outside network (internet).

 
X11 Forwarding
X11 is a communication protocol which allows a remote computer to run programs with a graphical user interface on a remote computer. SSH supports a way to tunnel this type of communication between ssh client, thus allowing the user to run X11 software on the server and see the ouput on his computer.

ZOC Terminal: A Modern SSH Client for Windows

The secure shell protocol covers the actual transmission of data between the client and server. But the secure shell client is usually a terminal emulator, i.e. a software that allows a remote computer to receive keyboard input from, and send formatted text (color, cursor placement, etc.) to the user's computer.

Thus, in addition to secure connection and encrypted transmission of raw data, the client still needs to be able to perform the functions of a terminal emulator (supporting various terminal emulations), but also extra functions like printing, logging, script-automation and so on.

Together with ssh features like latest encryption and public key authentication, port-forwarding, tunneling, smart card authentication, etc. this makes ZOC the ideal SSH client.

ZOC Terminal Download

Read more about our ZOC Terminal Emulator, check its feature list, look at our screenshots or start your free 30 days of evaluation today and download ZOC Terminal V8.09.0 now.