Once upon a time, there were only Unix machines on the Internet. In those far-off days, we had tools such as rsh (remote shell), rlogin (remote login), telnet and FTP so we could sit at one machine and use the facilities on another.
All was well in the online kingdom and the neighborhood was generally genteel and academic. However, this was not to last.
Oh, no.
In next to no time the rowdy barbarians appeared – the commercial elements moved in along with the hackers, the whackers, the spammers and the phishers. The result was that the Net was no longer a nice, safe neighborhood where you could let the kids – your users – play with their friends where they pleased. No longer could you expect them to turn up before dark, tired and ready for dinner with nothing more than a few scrapes and bruises to show for their adventures.
Now when they set off, any bad guy with enough smarts to listen out for idle, unguarded chatter could steal their account names and passwords. By the time the little ones got home, their piggy banks and your wallet could easily be emptied, your living room defaced and your property hijacked for any number of nefarious purposes. A sad, sad state of affairs.
So how to protect the kids? The answer was . . . Secure Shell (SSH).
SSH provides an encrypted communications channel between a client and a server over TCP/IP connections. Using SSH you can safely log on to a terminal session on another computer, and no one can “listen in.”
Originally the protocol was only for *nixen and Vaxen. But that quickly changed and versions for other operating systems appeared. Today, we have a number of “industrial-quality” implementations (as in being commercially supported) from which to choose.
So what does this paragon of privacy provide? To start with, SSH prevents IP spoofing – that’s when a remote host sends forged packets to appear to come from another, trusted host. It also prevents DNS spoofing, which is when an attacker forges name server records. It also prevents the interception of clear text exchanges (passwords and other data) and data manipulation using intermediate hosts. The only thing bad guys can do to SSH communications is force SSH sessions to disconnect.
But just like watching a Ginzu knife being pitched on TV, you must wait! There’s more! Not only does it slice and dice, but turn it over and it’s a chain-saw!
Yes, folks, along with safe terminal access SSH gives you secure file transfer, provides secure X connections and supports secure forwarding of arbitrary TCP connections. It is the communications equivalent of a secure Swiss Army knife.
Under the hood, SSH implementations are based on the SSH1 or SSH2 protocol – the latter being a more secure and complete rewrite of SSH1. These two versions are very different from each other and incompatible. SSH2 is the standard used in most commercial implementations today.
The SSH protocol is founded on a secure transport protocol. This low-level functionality provides strong host-based server authentication, and optionally, compression. On top of this is the connection protocol that multiplexes channels over the encrypted tunnel created by the transport protocol.
The final component is the client authentication protocol, which must be distinguished from a user authentication protocol to verify the identity of a user – a service that has to be added on top of SSH.
The goal of SSH was to support parameter negotiation for the key exchange method, the public key algorithm to be used, the message authentication algorithm and the hash algorithm while minimizing the number of protocol exchanges. Under SSH, data integrity is assured by including a message authentication code based on a shared secret, the packet sequence number and the packet contents.
For encryption, SSH2 supports AES, Triple-DES, Blowfish, Twofish, Arcfour and Cast128-cbc, and for authentication it employs passwords, public keys, digital certificates, smart cards, PAM and SecurID methods.
Discuss your secrets with gearhead@gibbs.com.