Ssh

Revision as of 21:18, 24 August 2004

SSH (a semi-acronym for Secure SHell), which under FreeBSD is generally the version found under the openssh-portable port, is the command-line tool used to securely access a shell prompt on a remote network computer. Doing this is commonly referred to as "shelling in" to the remote server and can be done from a computer that is not unix-based (such as Microsoft's Windows OS or Apple's OS X.

SSH distributions also typically include such as the command scp for copying files from remote computers, and/or piping arbitrary data streams through SSH tunnels.

There are many ssh programs such as TeraTerm SSH (which doesn't support the cryptographically stronger SSH2 protocol but will also allow you to connect via a serial port), MSSH, secure iXplorer, FileZilla (an SFTP GUI), WinSCP (which does SCP via a GUI), and the commercial (but free for non-commercial use) client from SSH Communications.

By far the most common non-Cygwin Windows equivalent to OpenSSH is the open source application PuTTY, although many commercial equivalents are also available.

Technical details and comparisons

In older days the cryptographically-lacking telnet and related applications such as rsh were used to control headless or remote devices. Telnet is now largely obsolete, however, surviving mostly only on distincly aging legacy equipment and for use in local serial console access on industrial routers. "Serious equipment" such as unix-like servers and heavyweight routers is moving toward access via ssh, while the smaller embedded equipment such as small-office/home-office routers and embedded printservers are moving towards embedded web-based access and configuration.

It is historically important to recall that telnet originally evolved as a standard for use over non-routable networks that were not considered very likely to be tapped, such as VT100-style serial networks, local console ports, and the like. As modern networking began drastically increasing the exposure of networked data to more and farther-flung locations, however, packet sniffing became more and more of an issue. An enterprising black hat who had access to a router, hub, or switch anywhere in between you and the machine you were trying to telnet into didn't necessarily need to know your password ahead of time - he could just log all the packets going to the machine and wait until a login sequence went by, and presto change-o, he's got root. A more patient black-hat might sit and monitor quietly without doing anything for weeks, months, or even years - the longer time went by with no alarm raised, the more sensitive data would go his way down the pike.

Ssh changed all that, by introducing automatic public/private key-based security and authentication across the channel. A black-hat lurking on the network and sniffing packets moving to and from a server controlled via ssh has much less to work with; since even the authentication challenge and response itself is encrypted against third-party interception, it is very difficult to gain much of value out of sniffing an ssh session.

Of course, things do tend to evolve, and it's always wise to make sure that your version of ssh is up to date before you decide that you're the Fort Knox of the IT world - fairly recently at the time of this writing, serious cryptological flaws were discovered in the older (version 1) ssh protocol, and so currently it is considered best practice to disable ssh1 sessions, forcing ssh2 or nothing.