SSH was developed to enable organizations to cost-effectively secure their system administration, file transfers and application connectivity against both internal and external security risks. SSH applies a strong layer of confidentiality (keeping the data safe from prying eyes) and authentication and authorization (affirming the person is who they claim to be?) and the SSH tunneling services that are used in Opengear's Secure Desktop Tunneling includes authentication between known_hosts, password challenge, and public/private key exchanges.
History of SSH Standard
Secure Shell was originally developed in 1995 by Tatu Ylonen, the founder of SSH Communications Security, to overcome the security risks of sending and receiving plaintext data and to provide a secure means of replacing Telnet, FTP, and Unix r-series programs. Later that year, after receiving multiple requests for a feature-rich commercial version, Ylonen developed what is known today as Secure Shell. Today Secure Shell is the de-facto standard used by millions worldwide for secure server administration, secure file transfer, and secure application connectivity.
Secure Shell has already been established as a de-facto industry standard for secure system administration and file transfers, and is being formally being adopted as an IETF standard. The seven new proposed standard RFC documents are RFC 4250 - 4256.
How does Opengear use SSH
Each Opengear console server hosts an OpenSSH server enabling secure remote command line communications, and the tunneling of insecure applications in a secure manner. Administrators and remote users can use a range of free and commercial SSH clients to effect the secure connections to their IM/CM/SD4000, although a free Java SSH client is included in the SDTConnector client software. With these Secure Shell tools:
- The Administrator can remotely access the console server and configure it at the command line
- Users can use tools like PuTTY or SSHTerm to access devices on the console server serial ports
- Users can also use the Secure Desktop Tunneling to securely connect management applications (like iLO) to servers and devices attached by the local LAN or serially to the console server. In an environment of increasing IT complexity and increasing security requirements, the SSH based SDTConnector provides a solutions that can both secure and simplify data exchange across diverse enterprise networks.
Why use SSH rather than an SSL or a VPN connection?
While SSH, IPSec and SSL use the same encryption standards (AES, 3DES) to ensure data security they have each have different origins and areas of strength and weakness.
A major strength with SSL is that it is supported by all generic web browsers, and the corresponding major limitation is that the SSL client trusts the server. The client browser goes straight to https URL you enter, even though it doesn't know who you are. It only knows your default SSL certificate is valid and uses it with the site's certificate to encrypt the channel. It really only gives privacy to an un-trusted client and can't establish real identity. It then is up to a higher level application to give authentication at another level (e.g. bank acct # PIN #)
The IPSec and SSH protocols assume both client and server are un-trusted. In the SSH case, the client has a specific account/certificate/key on the server per user so it can establish real identity before any subsequent communications. So a major SSH strength is the integrity and strength of its user authentication mechanism and the many crypto algorithms that support this. With SSH you don't need a higher level application to provide proper authentication/identity. And the simple ASCII interactive nature of the shell/terminal interface is an obvious strength.
For more SSH information refer:
Comments
0 comments
Article is closed for comments.