Glossary: Secure Shell Client

There are several different methods that can be used to connect the two, but in the past, the most commonly used method of connecting a terminal to a server over a network was Telnet.

Unencrypted transmission via Telnet today presents a serious security risk, because anybody on the network with some knowledge and tools can monitor the data exchange - even down to details like usernames, passwords.

Because of the ever-increasing demand for security, the Secure Shell (SSH) protocol was developed. SSH uses advanced encryption technology to encrypt every single piece of communication between the client (called secure shell 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.

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 can then play the role 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 secure shell client, you don't need to worry about these kinds of scenarios.

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 hardware ID card or by sending an access code to the user's mobile phone.

A good secure shell client needs to be able to connect to various different servers. In order to do this, it has to support latest key exchange and encryption protocols, because what seemed unbreakable five years ago, is considered less so today. If the server switches to more advanced encryption methods, ssh clients need to support these as well.

Other typical must have features for a ssh client would be:

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

Or, as RFC 4253 states in its own words:

An especially challenging part of encrypting communication over public networs, is the need to negotiation a shared secret (an encryptino key) over a channel that might already be monitored by an adversary.

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.

Obviously, the client still needs to be able to perform the functions of a terminal - supporting various terminal emulations, printing, logging, and so on. This is why ZOC is the ideal Secure Shell Client, it does all of the above, and more.