The 101 Uses of OpenSSH: Part I
It's story time here in the Paranoid Penguin. Don't worry—the story is a preface to the nuts-and-bolts sort of stuff you've come to expect in LJ. In fact, there are so many nuts and bolts to play with in OpenSSH that this article spills over into next month's issue!
This month we'll cover ssh's background and architecture, how to build and/or install OpenSSH, how to use ssh as an encrypted replacement for Telnet, how to set some basic ssh configuration options and how to use scp for encrypted file transfers. Next month I'll cover RSA/DSA authentication, local port-forwarding, remote-command-execution and other more advanced, and extremely powerful functions of ssh/OpenSSH.
In order to do this magnificent software justice, I'd like to begin by talking about how it got here and some of the people who brought it to us.
One of the coolest things about UNIX has been that there is not one but several different ways to administer systems from remote consoles. Sad to say, most of these methods (Telnet, rsh and X, to name a few) send everything over the network in clear text, including passwords. The combination of our reliance on the Internet with the proliferation of script kiddies and other packet-sniffing deviants has made administrative clear-text network applications obsolete.
But a few years ago Finnish über-hacker Tatu Ylonen created a mind-blowingly cool thing called the Secure Shell, or ssh. ssh is a suite of tools that roughly correspond to Sun's rsh, rcp and rlogin commands, but with one very important difference: paranoia. ssh lets you do everything rsh, rcp and rlogin do, using your choice of libertarian-grade encryption and authentication methods. But wait—there's a catch—ssh version 1 relies heavily on RSA, an excellent, but as we say, encumbered (patented) technology that requires any application that uses it to be licensed (paid for) unless it's used in noncommercial settings (even in noncommercial use ssh's legality has always been murky, especially in the US). But wait, you say, RSA's US patents expired in September 2000—problem solved, right? Almost: Tatu's got to earn a living, so by the time RSA became less encumbered, ssh itself had become more so as his company F-Secure tightened the licensing reins. In fact, beginning with ssh version 2.0, unlicensed/free commercial use (regardless of RSA issues) was no longer permitted. All this despite Tatu's sincere desire that ssh become an Internet standard, one of the requirements of which is that at least one free implementation be available.
Enter Theo de Raadt and the OpenBSD team. OpenBSD, of course, is the ultra-secure offshoot of NetBSD, a free version of BSD UNIX. Theo and our open-source brethren in the OpenBSD project wanted to include ssh in OpenBSD 2.6 but were wary of ssh's various encumbrances. When they learned that the Swedish programmer Bjoern Groenvall had released an improved version of ssh, 1.2.12 (the last completely free-except-for-RSA version of Ylonen's ssh), the OpenBSD guys rapidly got to work on updating and adapting it for a larger audience. OpenSSH has been part of OpenBSD ever since and is now portable to most version of UNIX.
OpenSSH built on Groenvall's work (his version, called OSSH, is still available), adding support for later versions of the ssh protocol and modularizing its cryptographic mechanisms in such a way that it's possible to compile OpenSSH without any patented algorithms whatsoever (i.e., without support for ssh v.1 protocols, which depend on RSA). The other innovation the OpenBSD team brought is the forking of the OpenSSH code-base into a “clean” version, which is kept as simple and platform-independent as possible, and a “portable” version, which can be compiled for a variety of versions of UNIX besides OpenBSD.
This last innovation is of particular note to us Linux geeks: the clean version is kept that way to maximize the code's “auditability”, ensuring that it's fundamentally stable and secure. Only after this code is blessed by Theo (a righteous paranoiac) are portability enhancements added. Thus, we benefit from a software package that is both extremely secure and 100% Linux-compatible.
By the way, less than two months passed between the time the OpenBSD crew discovered OSSH and the time they released OpenSSH 1.2.2; and only six and a half months after that they released the fully-portable and ssh v.2-compatible OpenSSH 2.0. Even considering that they were building on Ylonen's and Groenvall's work, this is a remarkable achievement, especially considering the quality of the end product and the fact that nobody gets paid for it!
So that's the story of ssh and OpenSSH so far. I hope you agree that it's a pretty compelling one, as notable as OpenSSH itself, which in all likelihood will very rapidly become the preferred version of ssh for open-source versions of UNIX.
Are you all fired up about OpenSSH and ready to install it on every UNIX system you control? Good. Let's get busy!
By the way: “ssh v.1.x” and “ssh protocol v.1” refer to ssh's software-release and protocol, respectively, and are not really synonymous. But since the package and protocol major version numbers roughly correspond, from here on in I'll use “ssh v.1x” to refer to RSA-based versions of ssh/OpenSSH and “ssh v.2x” to refer to versions that support both RSA and DSA. And if you don't know the difference between RSA and DSA, suffice it to say that both do the same thing but DSA has no patent- or license-restrictions.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide