Episode 4, OpenBSD

PodCast Feed


Links:
OpenBSD.org
Theo's site
Theo de Raadt on Wikipedia
Theo and the NetBSD team
OpenBSD FAQ
OpenBSD Installation Guide
BSDtalk Interview with Joris Vink, developer of OpenCVS
OpenBSD: Common Address Redundancy Protocol (CARP)
How to generate and use SSH keys
A usefule OpenBSD site

Sub-projects:
OpenSSH
OpenBGPD
OpenNTPD
OpenCVS

RYOS, Episode 4 - OpenBSD

Thud: The RunYourOwnServer podcast for July 2nd, 2006.

Tom Cote: Here is a little song about caffeine. Poets like caffeine. Politicians like caffeine. Beatniks like caffeine. Everybody likes caffeine. I like caffeine, I like caffeine. It can bring you up when everything has got you down. Sometimes you get sleepy when the caffeine can't be found. I like caffeine.

Thud: In this episode. : OpenBSD. Why is OpenBSD a good server OS? Some information on the installation of ObenBSD, basic lockdowns, OS updates, and a moment of Sec.

Thud: This episode's reverse sponsor is freshmeat.net. Freshmeat maintains the web's largest index of Unix and cross-platform software, themes, related eyecandy, and PalmOS software. Thousands of applications which are preferably released under an open-source license are meticulously cataloged in the Freshmeat database. For more information, please visit freshmeat.net.

Gek: OK, Thud, you've used OpenBSD more than Seg and I have. Tell us a little bit about the project.

Thud: Well, the project was started when one of the developers on NetBSD, Theo de Raadt, got upset with the way that NetBSD was concentrating on other things besides security. If you want to see the whole background of it, there is actually a link for all of the email threads that Theo was on that he was having a conversation back-and-forth with the NetBSD developers when they finally kicked him out of NetBSD.

He then checked out the entire NetBSD source code and added his patches which he had built up over months which they would not accept and then started OpenBSD, and it's just been going on from there.

Gek: What would you say is the main idea behind the project?

Thud: The main focus seems to be security. On their website, they try to emphasize portability, stability, correctness, which is kind of interesting for a project like this, and proactive security with integrated cryptography. The main focus has always been security. They try to do things in a secure way. Whether that's making the cryptographic side of a particular project, like OpenSSH for example, better, or if it's just modifying the code for vi so that it's more readable so it's easier to spot bugs when you have a problem. You can just run through and see exactly what's going on in the code.

As we know, developers in all these different projects have different ways of writing code. OpenBSD just has a certain standard, so they will accept patches that don't change the code at all except in formatting. It still does the same thing, it still runs the functions the same way, it's just formatted in the way that they want. They actually have a very detailed doc of how they want the code written just from a looks standpoint, not even from a functionality standpoint.

Gek: Would you say that that style makes the code easier to maintain long term?

Thud: Yeah, one of the things with OpenBSD is that most of the developers are in the project for a long time and they get used to that style of code. So if somebody submits something that's completely new but they can't understand the code because the style is completely different, they'll reject the code. It may even be a great idea, it may be perfectly secure from a programming standpoint, but it just becomes hard to maintain.

If all of the code they have is written with the same basic style, then anybody in the project can pick up that code and continue to work on it, even if the original developer leaves the project or decides to move on to something else. That's actually happened a couple of times. They've had people that were working on SCSI drivers, for example, that, after many years of doing that, have decided to move on to other things. A new developer can come right in, he is used to that style of coding, and can pick it up right where the other guy left off and can keep on going and add new drivers and new modifications to make things better or faster.

Gek: Sounds like it's better organized than some corporation development teams that I've heard of.

Thud: Oh, absolutely.

Gek: So, we know a little bit about Theo. Who are the other maintainers, and can you talk a little bit more about him, I know he is a pretty interesting character.

Thud: Well for the most part, he's the main guy. He's in charge of the project. Whenever it comes down to an argument as to whose code is going to go in for a particular function, he is the tie-breaker, he is the one who makes the decision. He is usual pretty vocal about it. Not only in coding, but in the philosophy behind the project as well.

As far as other developers, none of them are nearly as vocal or as public. There are many guys, especially on the network side of it. Recently they've been working a lot on the network code with pf for the firewall, support for BGP for being able to set up a router with OpenBSD. I don't remember their names right off hand, but they've been in the network side of the project for quite a while.

Theo is the main guy because he's the one that all the news reporters like to interview. As an example of what I'm talking about when it comes to Theo's philosophy for the project, a few years ago there was a DARPA grant that was given to a university. Part of that grant money went to the OpenBSD project to support the project for making secure code for a Unix system on a variety of different platforms. Because DARPA is a US government thing, they can't, or at least at the time they couldn't, just give the money directly to OpenBSD because it's run out of Canada, so they gave it to this university, and the university gave it to Theo for his project.

It paid for a lot of the hackathons that they do. They get together a few times a year, take a theme for that code, for an example the BGP that I mentioned. The code for the BGP daemon that the developed was started and was made functional in less than a week during one of their hackathons. But as you can imagine, getting a bunch of developers from all over the world together at the same time and the same place can get pretty expensive, even if you try every cost-cutting measure that you can come up with, it's still pretty expensive. A lot of the developers can't even afford the laptops they're developing on, they're donated by the project.

So the money from DARPA was sorely needed to keep the project going at the level of development they wanted, and Theo said something that was, basically, anti US government, anti President Bush, and within a week, DARPA had pulled the funding, they said for other reasons, but it was clearly obvious that it definitely had something to do with what Theo said, and a lot of people in the project got upset with Theo for not keeping his mouth shot. Theo's response, which by the way if you ever have a chance to look at some of his responses to a lot of arguments are generally straightforward and very funny.

In this particular case, to sum it up basically said, "Look, if you don't like the OpenBSD project, there are plenty of other projects. Go elsewhere. We want to keep the code out of the political light. We're going to code the stuff we want in the way we want and make it as secure and usable as possible, and if you don't like the way we do it, move on to something else." That's plain and straightforward and in a lot of cases makes a whole lot of sense.

Gek: One of the things that I've also noticed about a lot of the things Theo says, he is usually right. I don't think he's always right, but he's usually right.

Thud: Yeah, exactly. He has an interesting way of making his point, but generally his points are correct.

Gek: OK, I personally have used OpenBSD for a firewall for a brief amount of time, so I'm familiar with pf. I saw a demonstration at OSCon 2005 of a fail-over firewall in place where there were two firewalls set up using carp, they communicated between each other to keep session state information current, and the demonstrator actually just yanked a cable right out of one firewall and showed an FTP transfer going flawlessly through the break in service. It paused for one second and then it picked right up where it was going. What do you like to use OpenBSD for? What do you think it makes a good server platform for?

Thud: Well, I definitely think if you want to do a firewall, especially for a small office or a home office, OpenBSD is the way to go. Pf, which is their firewall setup is, I would have to say, the best that I've ever used. They keep adding more and more features. You had mentioned about CARP, which is their way of handling fail-over firewalls. They've come a long way with that.

They've got it to the point now where you can use an IPSec tunnel, which is a way of encrypting your data over a whole connection, it's basically a secure VLAN you could say, they've gotten it to the point to where, with pf and CARP and their built-in IPSec daemon, you can have a firewall explode, be completely off-line, and the backup firewall will come up so quick with all of the sessions open that your tunnel will not collapse.

Right now, even $100,000 NetGear and Cisco equipment cannot do that. They do have fail-over firewalls, they do have fail-over IPSec tunnels, but they do not fail-over instantly like that, the session has to be reconnected. It just blows me away some of the features that they're building into this. They are really only doing this for home offices. You could use it as a router if you wanted to, but it's nice that the firewall works much better than anything out there, and it's still free.

On the other side of it for just general server stuff, right now I use it as web servers, I've used them for email servers. Once I got into it and got used to the way that it worked, there is really no reason for me to look at using anything else, whether it's for a web server or anything like that.

If there's a specific application that requires Linux, for example, obviously I would Linux, but everything I've ever wanted to do in the last couple of years, I've been able to do with OpenBSD. It's just a good general purpose server.

Gek: At OSCon, one of the things that the demonstrator talked about was the firewall features. It was that you could actually make a gigabit firewall or even a 10 gigabit firewall by bundling 10 servers together running pf, and replicate millions of dollars worth of equipment that you would buy from Cisco or NetScreen.

Thud: Yes, that's one of the things they've been trying to work on. That's one of the reasons why CARP was invented. Cisco has a proprietary technology, I can't remember what it's called right now, but it basically allows two pieces of network equipment to communicate back and forth to keep state among sessions and to keep track of which one of them is currently up and is the primary.

Even though Cisco has never charged anybody for it and they have never even sold a license for the technology and it is publicly available, they were unable to write down specifically what license it was covered under, because all of these projects want to use it, and in fact there is a version of it for OpenBSD, but all of these projects want to use it, but Cisco was not willing to put down in black and white what the license was, so OpenBSD could see how free it was and whether or not their license was compatible with it.

Since Cisco wouldn't do that, they just went ahead and wrote their own. As it turns out, their own, in the beginning, was much much worse, but it's come a long way, and like I said, they've just recently added in this IPSec thing so you can do your secure tunnels with CARP so that you can keep everything in sync. They are adding more and more features to it.

They have even gone one step further in the last version, and you can now use it as a load-balanced firewall in front of a bunch of servers, so that you can actually not only keep track of which firewall is up, but you can keep track of which servers are up behind it and use it as a real load balancer.

Gek: There are other things I know they are working on also. You had mentioned to me before that they wrote their own version of Apache.

Thud: Yeah, at one point, Apache came out with Apache 2.0. Up to that point, everybody was using version 1.x, including OpenBSD, it's in their default install. Their default is very stripped down. It basically only serves web pages and graphics, and that's it.

So when Apache came out with 2.0, they also came out with a new license, which was still technically GPL, but OpenBSD did not like some of the license features. They didn't think it was still as free and open as it was earlier. So instead of upgrading to Apache 2.0, they created a fork of the old version that they were using. They had actually kept from doing that before so that if Apache would release a patch for their project, it would easily integrate into OpenBSDs. Once they decided, for licensing reasons, to stick with the old version and not upgrade, the first thing they did is they went through and completely reformatted it so that it was in their coding style so that it was easier for their developers to work on.

That has one downside in the fact that if there's ever a patch released for the main Apache project, they have to manually create a patch for OpenBSD's Apache project, because the code is not laid out exactly the same anymore. But that also means that they were able to add some security fixes to Apache which they had submitted to the Apache project but were never put in for one reason or another. So it allows them to still have a web server that everybody is used to, just about everybody on the Unix platform uses Apache as their web server, so the configuration is exactly the same, but the internal code can be different. It can meet OpenBSD's security standards as well as their coding style standards.

Gek: There is a podcast I listened to, I don't remember the name of it but I'll include it in the show notes, they just recently interviewed the guy who does OpenCVS, and I found it interesting that OpenBSD doesn't actually use their own OpenCVS product yet. I guess they're not happy with where it is currently. They still use the GNU CVS.

Thud: They actually had a couple of offshoots from OpenBSD. The main one is probably OpenSSH. They have OpenBGP, the have OpenNTPd, which is a time server, and then OpenCVS. The youngest of those is OpenCVS. They started it because they didn't like the coding style for CVS and they didn't like all of the cruft that goes with it. There are a lot of security issues, especially if you are trying to set up a CVS server.

So what their goal is with OpenCVS is to make an exact copy without using any of the original code of CVS. So if you are used to a particular CVS command running a specific way, it should run exactly the same in OpenCVS. CVS is one of those things that has just got so many options tacked on to it. There are literally thousands of options that all have to work together in exactly the same way in order to replicate it.

So being the youngest of the projects, it's not there yet. For basic stuff, it seems to work great. But it's not feature-complete, it doesn't support every option that GNU CVS supports. They are working on it and once it gets there, there are plans for OpenBSD to switch over.

I just think it's cool that they're taking something that everybody uses and apparently nobody has any big problems with and redoing it themselves just because they think they can do it better in a more secure way, and then later on down the road, they can add their own features.

Gek: So, I've installed OpenBSD a couple of times, and even though it's pretty well documented, it can be confusing if you're not familiar with the process. What would you say are the common gotchas in an installation of OpenBSD?

Thud: Well, the documentation is actually pretty good. The only gotcha that I've run into on a regular basis is during the partitioning section, when it brings up the fdisk partitioner so you can create your partitions, they give you suggestions on how to partition things out.

There is actually a security reason for that that I'll get into in a moment, but by default you'll end up with two partitions, but it looks like three. You have the A partition, which is generally all of the disk space except the B partition, which is always swap space, and then they show a C partition which actually isn't a partition, that's just the full disk of whatever disk you are working on.

The gotcha is that in the documentation, it's not really clear that the first thing you need to do is to delete the A partition. Because the way it's set up, it just assumes that you want to use the entire disk during the installation. If it's the first disk, like your boot disk, you don't want to use the entire disk, you want to lay it out in a specific pattern for all of the mount points. They don't make it clear in the documentation that you need to delete that first, otherwise you don't have any available space. So as long as you delete that A partition, you are good to go. You can set up the partitions exactly as they suggest.

The security reason for following what they suggest, which is to have your root partition which doesn't need to be really big, especially if you are coming from a Linux system, just your basic / partition doesn't need to be very big at all. Half a gig is plenty. Then you have /usr and /var, /home, /tmp.

And the reason why you want to divide it up that way is because during the install, if all of those mount points are there, then the install actually can do some additional lock-down. One good example is for the /tmp partition. You don't necessarily want to mount that so that code is executable from there. It should just be reading and writing temporary information, it shouldn't write temporary information there and go execute the code. There are actually a lot of exploits that work that way.

So one of the security features you can do is mount it so that it's not executable. Even if there's code on there that is executable, if somebody tries to set it for execute permissions or tries to execute it, it won't run. So by dividing it up that way, you can get additional security features.

But other than that, I think the install documentation is laid out pretty well and the process is actually pretty quick. Once you've gone through it two or three times, just about everybody I've talked to has said that it's the easiest install once you understand it. There are not a whole lot of options. It's pretty much, set up your partitions, yes you want these things to start, there is only a very short list, there's SSH, OpenNTP and a couple of others. The rest of it is just a plain install. It installs a very minimal installation with only a few tools, everything else you have to add onto, so there are not a whole lot of options during the install process.

Gek: That makes locking it down pretty easy. If you are going to lock it down, if you're going to, say, install, if you wanted to put Apache and Postfix and mySQL on it, what would you do for lock-downs? I understand the basic install is pretty much as locked down as you can get.

Thud: Yeah, even the tools that are installed. A good example is Apache. Apache is installed by default but it's not turned on by default, so you have to manually go in and do that. The only lock-downs I do on every OpenBSD that I set up are really just my paranoid lock-downs. I have never ever had a security issue by not doing these, but they're just things I found later on that make me feel more secure. if nothing else.

One of them is all of the inetd things. It's /etc/inetd.conf. There are some things in there like echo and time and daytime and things that are on by default. I generally go through that file and comment out everything that is not already commented out, because I never use any of that stuff. I'm a big believer in that if you don't use it, even if you know it's secure, you might as well just turn it off. If you have no use for it, it doesn't need to be running. It's taking up some system resources.

The only other thing I do is I edit the configuration for SSH so that it only accepts protocol two and that it doesn't permit root logins. There are a lot of other things that you can do, but those are the two main ones for SSH.

If I'm doing Postfix or something like that, I generally try to do something from ports, because with OpenBSD even though their security standards aren't as high on the ports tree, because it's not actually run by the main developers of OpenBSD, there are a lot of guys that are using OpenBSD specifically because they like the security, so they try to add additional patches into the port-tree to add some more security. Patches that add some security but necessarily weren't accepted upstream from Postfix or whatever, though Postfix generally doesn't have any security issues.

The other reason to use ports, or packages for that matter, is because they install in the acceptable OpenBSD manner. There are a lot of projects that want to be installed in /usr/local/ then whatever the project name is and then you have /etc and /var and all that mess under there. A lot of the patches do nothing but just change the destination for all of those things so that it's installed on every OpenBSD box, and it all makes sense. The logs go in /var/log, the configuration files generally go in /etc, so it just makes using the entire system much easier to deal with when you know that everything's going to be put into the same place.

Gek: What is the process for keeping the OS current?

Thud: Well, I have to say that among all of the OS's, OpenBSD is probably the most difficult to keep patched. It's really because they don't release binary patches. It's not like on a Red Hat or Fedora box where there's an RPM that just patches whatever has the problem. If it's an OS-level patch, the OpenBSD way of doing it, which is well documented, so these steps are actually easy to deal with, is just a long process.

There are three basic versions of the OS. There is RELEASE, which is what is on the CDs or is on the FTP sites when they come up to a release, which is generally every six months. There is STABLE which is RELEASE plus any patches for bug fix - or security issues. And then there is CURRENT, and CURRENT is basically the beta. It's the current work-flow for the next release, so generally you want to stay away from CURRENT unless you want to test something specific that they are working on.

So what you want to do is upgrade from RELEASE to STABLE, and what that involves is doing a CVS checkout of all the source code or downloading, they actually have a source code tarball that is on the CDs or is made available on the release day, so you can download that so you don't have to check out all of it. But you do have to check out the patches, then you have to rebuild everything. You start by rebuilding the kernel, it gets installed, you do a reboot, then you have to rebuild all the userland stuff, because there are certain files that are in the kernel tree that are used in userland stuff. So it's really best to not only do the kernel, but do all the userland. Depending on your box, that could be a six-hour process.

But for the most part, it's run a couple of commands, keep an eye on it while you're doing other stuff. When it gets done, you can reboot the box, run a couple of other commands to start the next compile set and then go check other stuff, work on other things, come back, reboot, and you are done. So it's a long process, but it's not a busy process.

Gek: And a lot of it depends on the speed of your machine, like you said.

Thud: Right, and for the most part, when they release a patch, they give a lot of detail as to what the patch fixes, what possible security problems there could be with it. So as an example if you are running it as a mail server and they release a security fix for Apache and you don't even have Apache running, there is no point in even bothering.

Once they stop supporting a version that they don't release any more patches for, I've never ever had an OpenBSD system get hacked because of an OpenBSD security problem. When it does happen, it's always, I was using sendmail, and it wasn't the OpenBSD sendmail, it was the standard sendmail from the sendmail people, and it had a security issue and my box got hacked into. Or I was using a specific version of Apache. Those are what caused the problem.

For the most part, the system level patches, for it to be exploited, you'd already have to be on the box or be using it in a specific way. If there's an exploit in the network code, then you have to be using a specific network feature for that to work. So for the most part, it's not something you have to do when a patch is released. If it's something that affects you, then yeah, you probably should go patch right away, but if it's something you already have to have root on the box to use anyway, or at least access to the box, anyway, you just do it on your regular patch schedule. Every couple of months see if there are any patches for the box, and do an update then.

Gek: Speaking of updates, they use the same or a similar ports system as FreeBSD. How do you go about updating the third-party software that's on your box?

Thud: Well, even though it is called ports and functionally at one point they worked exactly the same, FreeBSD over the last few years has put a lot of effort into making their ports tree much, much easier to work with and to maintain all your ports that are installed. OpenBSD's is now completely different. It still works basically the same way. You go to a specific directory where the port is, usually in /usr/ports, you go in there, you just type make install, and it goes and it grabs everything that it needs, and it builds everything that it needs and then installs the package. They don't really have a good way to keep things upgraded.

As a matter of fact, the last RELEASE version of OpenBSD was the first time they had any way of doing an upgrade besides removing all of the old ports and then reinstalling with all of the new ones. They have a process now, I've used it a couple of times and I'm still more comfortable with just removing the old port and then reinstalling the new one, but they are working on making it a little bit easier. The basic ports-system works by building from source code all the stuff that needs to build a package, and then that package is stored in a location within /usr/ports, where the package is then installed with just a regular pkg add.

If you actually watch as it's building a port, towards the end during the make install, you can actually see it build the package in a test environment, then build the package for real, then do a test install, and then do a real install of the package. So like I said, it's different from FreeBSD's way of doing it, it still has an issue where upgrading is difficult because you have to remove the old package to install the new package, even though it's built by ports. But because the packages, once they are built, are always kept on the box, it's not that hard to reinstall an old version of something.

Gek: Something we should probably mention here is how a lot of people lump together Linux and the BSDs into one similar category, when really they are very different, and OpenBSD is a very good example of that. It is not only different from the Linux distributions, it is very different from the other BSDs, and not just in license, but like you said, the way they code. They want their code to be written a certain way. And while it sounds like something minor, if you are used to reading your code with a certain format and you go to a different format, it can be very alien.

Thud: Yeah, in a way, I guess the best way to describe it is that you have the Linuxes and the BSDs, and you have different distributions of Linux, Red Hat, Fedora, Debian, Ubuntu, and you have the same thing with the BSDs. The base of all of them is the same, but they're extremely different now. So you have FreeBSD, OpenBSD, NetBSD, there is also Dragonfly BSD and PCBSD and a couple of other small ones. I think the main difference is that in the Linux community, for all the distributions, they all have different ways of handling patches and things like that, but the basic code is always the same. Linux releases a new kernel, and eventually everybody makes it up to that kernel. In the BSDs, the only similarity that they have is whichever project they forked off of, they were identical at that point, and then they have moved completely away from each other. So that internally, they are almost unrecognizable.

A good example is NetBSD, they generally do a really good job of getting drivers out for new hardware very quickly, although recently OpenBSD and FreeBSD have been doing a pretty good job, too. If a driver comes out in NetBSD, it's not just a simple plug-in to get it to work on OpenBSD and FreeBSD, there actually has to be a lot of work involved. In the end, parts of the code are brought in to the other projects unmodified, but large chunks of how it actually talks to the kernel and plugs in to the userland area, all of that has to be completely different because now the projects are that different between each other.

Gek: Just recently, one of the things that hit the news was that the OpenBSD project wanted some money, some funding from bigger companies who use their products, like OpenSSH. What can you tell us about that?

Thud: Well, one of the biggest problems with OpenBSD is that the main developer, unlike a lot of other projects, the main developer Theo doesn't do anything else. His job is OpenBSD. So the only income he has, and the only extra money he has in order to send a laptop to a developer that's over in Europe somewhere that can't afford their own laptop, the only way he can do that is out of his own pocket. His own pocket is the OpenBSD project's funding.

For the most part, the only way that they get funding right now, there are a few donations from corporations, is from the sale of their CDs.

Even though the software is free -- you can download it and even install it over the internet -- they still like people to buy the CDs and to buy the T-Shirts, and they even have posters, as a good way to fund the project. If you are willing to use the software because you think it's so much better than everything else and it's a plus that it's free, it makes sense that if you can afford to send in a few bucks that you do. Because these guys, a lot of them are doing it as a hobby, but some of them, this is their full-time job. They only work on OpenBSD. So funding has always been an issue for them.

Especially in the last few years, they've found it really difficult to get gather, to have these gatherings, these hackathons, to do all this coding, and also to... They have people who want drivers for the latest and greatest hardware, but nobody is willing to donate the hardware and the OpenBSD project can't buy the hardware. It's become pretty difficult for them. So one of the ways that Theo has actually been out there and been vocal about it is, virtually everybody uses OpenSSH now. Even Cisco has OpenSSH on a lot of their equipment now. It is one of those projects that has become ubiquitous in the Unix community, and has greatly improved security, but nobody is willing to donate.

So Theo put out the word that he wanted big corporations that use this stuff every day to step up to the plate and send them a little bit of money. And once he put the word out, a lot of people came up. I know that Google has sent in, I think it was $10, 000. There have been a lot of companies out there that have stepped up and donated some money so that they can go on and do some other things. Because even though it's OpenBSD and not everybody agrees with their philosophy, they have these subprojects like OpenSSH that everybody loves and everybody uses. So I don't see any reason why they can't donate to the main project in order to keep these little subprojects, as well.

Now a for a moment of Seg. This episode, we're going to cover OpenSSH, which is, again, a subproject of OpenBSD. So Gek, tell us a little bit about OpenSSH.

Gek: Well, the main thing I use OpenSSH for is a handy way to encrypt things that are just not encrypted. I have a VNC server running on my box at home, and I don't want to open that up to the outside world, I don't want to punch a hole in the firewall because I don't trust VNC. In fact, I don't trust most things that have to do with a GUI. So what I do instead is, I ssh into my box and I create a SSH tunnel using the option -L, then you type the port you want on your local box, the interface on the remote box that you want to connect to, that's a little confusing but I'll explain it in a minute, and then the port on the remote box that you want to forward to your local machine.

So, for instance, if I'm doing VNC, I would do ssh -L5901:localhost:5901. That will make it so that on the remote box, it's going to connect to the local host VNC port, and on my box it'll appear as if I'm running a VNC server. And then at the end of that, you attach your username and the host you want to connect to.

Once you connect a ssh into that box, you will have an encrypted session between your local host and the box that is remote, so I can fire up VNC, point it at local host instead of my address out on the net, and then tell it I want to connect to display one or port 5901, and I'll have a VNC session locally. I should mention, it's very slow. It works, but encryption adds some overhead, and VNC isn't fast to begin with, so it's pretty slow.

That's the kind of thing I use OpenSSH for. How about you, Thud?

Thud: Well, I use it mostly to log into servers to be able to get to their command line, copy things back and forth between them with scp or sftp, but I also use it in my backup scripts. They basically do a scp to get the data from one box to the other encrypted, but it's nice that you can use it with ssh keys so that you can do the authentication without actually having to deal with passwords. So you can put it in a cron-job and it can just run every night and copy data around, or synchronize data across multiple servers.

One of the things that I found out recently that you were talking about with the SSH tunnels is that Anonymizer, actually one of their products, uses SSH tunnels for the connection from your machine out to their proxies. That way if you have IPSec, which was one of the first tunneling protocols for security and actually has a lot of issue with some firewalls. SSH or SSL, for example, don't have those issues, so a lot of companies and a lot of vendors are switching to SSH or SSL for tunnels for things like that. SSH is just so much better. It gives you a lot more encryption options than just SSL alone does.

So now that I've mentioned SSH keys, Gek, why don't you go into a little bit about that?

Gek: There's a lot of instructions out on the internet, we'll link to some of them, that tell you how to actually physically generate the keys. It's pretty easy. All you need to do is run just a few simple commands. That will give you two files, your public key and your private key. You copy your public key to the server using your password. By server I mean remote machine. You copy that to the remote machine into the.ssh directory of your home directory for the user account that you want to use the key for. Then you make sure that it's attached to the proper file, which I believe is authorized_keys or authorized_keys2, depending on your implementation.

Once you have the permissions of that file correct and your public key in that file, you can then ssh to the box and you won't be prompted for a password.

Thud: One thing about that is it's very important to get the permissions right on those file. I have actually run into this a couple of times where I copied over and then spent the next 20 minutes trying to figure out why it's not working right, because ssh is actually checking for permissions on those files. It has to be owned by the user, basically the permissions have to be set so that only that user has access to it. It's just one of the built-in security features that hey have.

Gek: It also illustrates the philosophy we've been talking about that OpenBSD has where they want things to be secure, and they don't mind making it different from somebody else. There are programs besides OpenSSH that look at file permissions, but that is one thing that they put in to give an extra step of security.

Thud: Yeah, a lot of times they put in an extra piece of security just because they can. Not necessarily that it adds a whole lot of security, but even if it adds just one little speck of security, they feel it's worth it. The more locks you have in the way, the harder it is to break into something.

Gek: Something else we should talk about is, a lot of people are familiar with the OpenSSH client, but there is also the SSH server, and there are some things you can do to lock that down. One of those things is, for the most part, when I'm running a server, I go and turn off SSH1 support. I only use 2, and there are some security vulnerabilities, that I understand, just in the architecture for SSH1. There are ways that people could get access to your password or keys.

Also, you can specify whether you allow X11 forwarding, whether you allow root to log in, there are a lot of options. Generally that file is called sshd_config, and most distributions in Linux, I don't know if OpenBSD is the same way but I imagine it is, most of them include all the options, even if they're commented out.

Thud: Yeah, OpenBSD does include all the options. One of the nice things about OpenBSD is that even on older versions, they generally do release patches to get everybody up to using the latest and greatest OpenSSH, mostly because it's their own project and they add a lot of new features. It's nice to do that.

OK, now for some closing thoughts. Gek, what are your closing thoughts on OpenBSD?

Gek: OpenBSD, as we covered before, is really just a great place to start if you want to learn basic security concepts. By looking at how they lock the system down, you really do get an idea of what best practices are for securing a server. Even if you take that knowledge and go and apply it to a Linux distribution, or FreeBSD, or OS2/Warp, then you really do get some foundation to work from on turning things off that you don't need, figuring out what the options are for the applications you are going to run and making sure that you're running them in the most secure way that they can be executed. How about you, Thud, what do you think?

Thud: Well the first thing I think is everybody, even if they don't use OpenBSD, they should at least go out and buy a T-Shirt or a couple of CDs to help support the project. We all use OpenSSH, and it's just a nice little way to support the project. You can also, if you want, just send in a plain donation.

But as far as the project goes? OpenBSD is one of the best projects I've ever worked with. I just like the whole philosophy of how they try to make everything secure. They also make things simple. That adds to the security, but it makes management of the OS and configuration of specific applications very easy to deal with. I definitely think that everybody should give it a try at least once, even if it seems difficult to install the first time you run through it.

After you go through it a couple of times, it's very easy to set up, it's very easy to use, and it just has tons of options and features. Things they don't even mention in a lot of the documentation. If you dig into the man-pages, which are very well done, you can find tons of stuff that makes it very easy to use and makes it a great operating system.

Gek: Also, if you're not going to actually download and use the operating system, you should at least download the theme-songs that they release with each new version.

Thud: Yeah, absolutely. Each version that they release about every six months has a specific theme. They have a group of musicians that do a theme-song for each release that goes with the theme. Some of them are pretty funny, a few of them are actually quite bad, but they are all worth listening to.

Thud: For show notes or other details, please visit our website at runyourownserver.org.

If you would like to send us feedback or have questions you would like us to answer on the show, please send an email to podcast att runyourownserver.org.

The intro music, "I Like Caffeine" is by Tom Cote. This song, "Down the Road" is by Rob Costlow. Please visit our website for links to their websites.

This podcast is covered under a Creative Commons license. Please visit our website for more details.


Transcription by CastingWords