| « World without Jobs | Yikes! » |
Sat, Oct 01, 2011
![[Icon]](rsc/img/chain_link.gif)
I gave another talk for my local LUG this week. Which maybe wasn't the best idea, considering I had a cold & sore throat. Still, nothing some benzydamine hydrochloride couldn't help sort out..
The subject was ssh, and since the audience ranged from people who've used it for years to people who've never heard of it, I aimed to start with absolute basics and work up to the more exotic topics.
To begin with, I discussed how typically, a server on the internet is accessed via one single address. One address, one machine, one network device. And yet we may well want to run multiple services on this machine: email, web, telnet, whois, rsync, shh, ftp, and so on.
In order to enable this, computers pretend to have something called 'ports'. These are a helpful fiction: they have no hardware analogue, you won't find one by taking the machine apart. A useful analogy is to consider an office building. It may only have one address - say, '3 Main Street' - but within it there may be dozens of offices with dozens of workers. We may want to write a letter that will go specifically to the accounts department. But the building only has one address. How do we fix this? We know that the accounting guys are in office 12, so we address the letter to '3 Main Street, Office 12' and it will get to the right place. Or if we don't know that, we can just send it to '3 Main Street, Accounts Department' and it should still get there.
Port numbers are like office numbers - they help deliveries get to the right place. Some common ports and their services:
20/21 - FTP 22 - SSH 23 - Telnet 25 - SMTP 43 - Whois 80 - http 443 - https
So when your web browser goes to, say, http://google.com, it actually connects to google.com port 80. Your browser knows what port to default to: You can easily over-ride this by specifying a different port, e.g. http://www.example.com:8080/
Web servers are all well and good, but sometimes we want to actually log in to a computer and just get things done. Since the command-line allows us to do pretty much everything, a way of accessing it via the network was needed, and so we have telnet: A simple but powerful application, telnet is simply a way to connect to a specific port on a specific server and exchange text.
This is good for more than just the command line: You can access web pages and send emails using nothing but telnet. As an example, try:
$ telnet google.com 80
GET /
You'll get a bunch of text output in response: The output of google's webserver that your browser would get if it were to go to the same place.
But telnet's main use was for command-line things. But that was in the old days, when you were likely to just be using a local network connection that nobody was likely to snoop on. Nowadays, with the internet making it likely that you'll be networking around the world with any number of people able to listen in, it's not really safe to use: telnet transmits text exactly as it shows on the screen - your login name, passwords, commands, output, everything can be viewed by anyone monitoring your connection.
So the world needed a way to scramble the text before it was sent, in a way that only the machine it was meant for would be able to unscramble. And so ssh was invented, a 'secure shell'
It's a hallmark of free software that it has a lot of choice. Indeed, a criticism often levelled is that there's too MUCH choice. Somebody looking for an open-source operating system must go through a long chain of decisions:
Linux or FreeBSD or OpenBSD?
Linux. Okay. Ubuntu, red hat, debian, suse, slackware, red hat?
Ubuntu? Okay. Gnome, KDE, or XFCE version?
Gnome? Sure. Now for the applications. What browser? Firefox, chrome, konqueror, links?
Firefox. Okay. Email now: Thunderbird, evolution, mutt?
Evolution. Fine. Movies? VLC, totem, mplayer?
Maybe sticking to the command line would be easier? Hahaha! Which one? Bash, zsh, csh, ksh?
And so it goes. Practically everything has an alternative that you should consider. Even the stalwart 'LAMP' stack isn't as simple as you might think: Sure, Linux is a good server OS, but OpenBSD is more secure. Apache's the big web server, but lighttpd is worth considering. MySQL is the most well-known database, but what about PostgreSQL? As for the 'P', does it stand for Perl, Python, or PHP? 'nuff said!
So with all that said, you should appreciate what it means that when it comes to ssh, there's really only one that you need to worry about: OpenSSH.
That's not to say that there are no other ways to do SSH. There are. But the chances of you encountering them are very slim: OpenSSH, as the name implies, came from the OpenBSD project. It's used by FreeBSD too. I don't know of a single Linux distro that doesn't use OpenSSH. Even Mac OS X comes with OpenSSH by default.
OpenSSH is THE ssh to know about. It's been around since the 90's which means it's been extensively developed. And that means it's powerful, well-supported, and more feature-rich than you might first imagine.
The thing is, OpenSSH has been able to give you an encrypted, secure shell for well over a decade. They cracked that right at the start. Which means that the developers have had plenty of time to make it do other powerful and sophisticated things: Tunnels, sockets, file transfers, etc. And they've had time to make it simple and reliable too. I'd go so far as to say that it's easier to transfer a file with SSH than it is to use Ubuntu's built-in file sharing software, it's that good.
To learn more about the power of ssh and how you can bend it to your will, visit my ssh page.
![[Links]](http://geekblog.oneandoneis2.org/skins/112/rsc/img/chain_link.gif)
I'm in the Perl newsletter again. I should try and write about some other language...
21/05/12
Facebook Syndication Error
22/05/12
![]()
I last listened to:
Johann Pachelbel - Canon in D major
Most recent photo:
js.js