The Secure Shell protocol provides a secure, encrypted connection between the local host and a remote computer, ensuring that third-parties cannot decipher any intercepted network traffic. Originally SSH was used primarily on UNIX based systems as a secure alternative to the insecure TELNET protocol, in which private information such as passwords would be sent as plain text over the network. SSH provides a high level of data integrity and confidentiality over insecure and public networks (e.g.: the Internet) and is widely supported a broad range of operating system platforms. The protocol itself is defined by a set of open standards, with RFC 4251 outlining the basic structure of the protocol, and other standards documents covering the different subsystems.
With the SSH implementation in SocketTools, there is three basic functions that you can use within your applications to take advantage of the protocol:
1. Interactive terminal sessions. This is similar to how the current TELNET protocol component works, and in fact the interface to the SSH component was intentionally designed to be very similar. Our goal was to make it easy to integrate SSH support into an existing application that already used the TELNET protocol. The Terminal Emulation component can be used to provide a visual interface that supports the standard ANSI and DEC VT100/VT220 escape sequences. Alternatively, the SSH component can be used on the back-end to capture output from an interactive session and filter the data transparently.
2. Remote command execution. This is similar to how the Remote Command component works, in that a command is submitted to the remote host for execution, and the output is returned back to the caller. The SSH component makes this very easy to do, providing a single method that allows you to run a command on the server, and its output is returned in a string variable or byte array that you provide.
3. Secure file transfers. Support for secure file transfers using SFTP has been integrated into the current FTP API and components, making it extremely easy to upgrade existing applications to use SSH/SFTP. We decided to go with this approach, rather than implement SFTP support in a separate component, so that developers would be able to integrate the new protocol with minimal code changes. In most cases, all that’s required is specifying a few additional options.
For those developers who have been using SocketTools for a while, you may be wondering what the difference is between SSH and TLS. TLS is the standard for securing connections to web servers and is commonly used with other protocols such as SMTP and IMAP4. However, SSH has become popular for remote terminal sessions and secure file transfers because it’s generally less complex and has a lower cost to administrate. For example, SSH doesn’t use site certificates, so there’s no requirement to register with a certificate authority (such as VeriSign or Thawte), generate certificate signing requests and update certificates on a regular basis. Therefore one of the big differences is that SSH cannot provide information about the server itself in the same way that TLS can. For example, SSH doesn’t provide a way for you to determine what company or organization owns the server and where they are located.
However, it’s important to note that the SSH protocol uses standard public-key cryptography to authenticate the client session, and shares many of the same cryptographic algorithms used with TLS, ensuring that the data is secure. There are now millions of users that regularly depend on SSH for secure terminal sessions and file transfers, and SocketTools will allow you to easily integrate support for the protocol in your own applications.