Kerberos

Lately, I've been playing with Kerberos, which is an interesting protocol designed to solve a number of problems with mutual authentication. In larger networks, it's very convenient to have a central authentication database so users can use their same credentials across many machines. This would ordinarily be a simple problem to resolve; however, workstations and other services can't be trusted. Since one rogue workstation can compromise everyone's credentials, you need a system to verify both the authentication server and the client, which is where Kerberos comes in. Kerberos uses a "ticket-granting-ticket" system in which users authenticate with a password to a centralized server, which gives them a token that can be used to prove their identity to any "Kerberized" service. This is extremely convenient for single-signon applications in which it's a pain to have to enter a password for each service; additionally, users can manage a single password for all applications ins a Kerberos realm without any security risks.

One thing I've found useful is Kerberized SSH access, which lots of large institutions (e..g. university departments) happen to offer. Ordinarily, you have to install a SSH key on all machines you'd like to use or remember a password for all of those; under best-practices use, users have encrypted keys that require a password at each use. Kerberos can maintain a more secure environment while generally being more convenient, since tokens last for 24 hours and can't easily be stolen like SSH keys. Also, if a key needs to be revoked, Kerberos can destroy all tokens at once, which is beneficial if you forget which servers your key is on.

If you happen to have Kerberos credentials, it's generally fairly simple to setup with SSH. I only needed to include this line in my $HOME/.ssh/config:
Host *
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
Getting a Kerberos token tends to only require running kinit user@REALM like such :
matt@badwolf> kinit user@ECE.VT.EDU
Password for user@ECE.VT.EDU:
matt@badwolf> klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user@ECE.VT.EDU
  
Valid starting     Expires            Service principal
12/20/12 17:30:36  12/21/12 17:30:32 krbtgt/ECE.VT.EDU@ECE.VT.EDU
and then you can ssh without a password. You need to run kinit -R before your tokens expire if you don't want to have to enter a password to authenticate again. I've been meaning to daemonize this for convenience, but haven't had a need to lately. As a shameless plug, VTLUUG now offers free Kerberized shell accounts for those that come to meetings.

Second VTLUUG Meeting

Hey everybody!

I recently attended my second VTLUUG meeting. This meeting was actually very interesting and relevant to what we’ve been doing in class as we talked about the different LINUX distributions that have been released such as Fedora, Arch Linux  and Linux Mint and the advantages and disadvantages of some of these distributions over others. After using Ubuntu for one semester, I feel I’m fairly comfortable with the UI and might consider the possibility of migrating to a more developer/programmer friendly LINUX distribution such as Arch Linux which is targeted for more experienced LINUX users as I think it might possibly prove to be useful for the Applied Software Design class I’m scheduled to take next semester.

Going back to the topic of the VT LUUG meeting, this meeting was very participative with multiple people from the audience providing their input on the various distributions unlike the last meeting where the President and Vice-President seemed to be doing all the talking. After talking about the various LINUX distributions, we essentially talked about upcoming and noteworthy news in the UNIX/LINUX world. Another repeating observation that I made at this meeting was that a lot of the material that was discussed in the meeting was beyond the scope of our ECE 2524: Intro to Unix class and it might be better if VTLUUG was divided up into smaller groups based on the proficiency of the users and their past experience. In conclusion, the VTLUUG meetings were very informative and thorough with upcoming news and events in the LINUX/UNIX world but almost every member has a vast amount of experience and seems proficient with the environment so it is difficult to follow along sometimes.

Until next time!

First VTLUUG Meeting

Hello everybody!

I just attended my first VTLUUG meeting and it was nothing like what I expected. From their website, the Linux and Unix Users Group at Virginia Tech (VTLUUG or “the LUUG”) is dedicated to improving the computing skills of its members, supporting Linux and Unix use on campus, and serving the community through Free Software and open data. The first meeting was especially interesting because I felt a lot of the members were regulars and very experience with UNIX/LINUX based operating systems.

At this meeting, we talked about a simulation game that was developed in a UNIX environment similar to one of the primitive handheld console games. To be quite honest, I really felt that almost everyone in the audience who was participating in the discussion of the game was very experienced with UNIX and I couldn’t follow along in some of the subtopics of the discussion. The people who were speaking about the game did go into a fair amount of technical detail but there was an atmosphere of mutual respect and inquisitiveness all around.

One of the trends I seemed to notice at the meeting was that the same key people kept presenting new ideas and talking about developments in the world on UNIX/LINUX. A suggestion that I would encourage to be implemented is encouraged participation of some of the newer members of the organization, especially students who attend the meetings to get credit for the Intro to Unix class. This would encourage an increased level of learning and curiosity which I think would be very beneficial. It was a great experience from an overall perspective though.

Until next time!

PXE Boot Adventures

The installfest for VTLUUG was this past weekend, and I was tasked with setting up a PXE boot server. For those unfamiliar with this, PXE (Preboot eXecution Environment) is a built-in feature on most newer motherboards that allows users to obtain a bootloader over the network for remote OS installations. The only requirements on the network side are a router capable of directing DHCP clients to a TFTP server and assigning a file path. Client machines can then download a bootloader (e.g. syslinux) image which provides a menu of kernels to choose from. Typically, only the minimum number of required files are stored on the TFTP server, so that clients can download the rest via faster protocols such as NFS or HTTP.

Setting up the server was not all that difficult, but there were a few setbacks. I started with a 64-bit Debian VM on my laptop with atftp-server and followed a basic tutorial I found online. Setup for this was fairly straightforward for the more common distributions with text installers- -you only needed to mount the netinstall ISO, copy the files to the TFTP root (/var/lib/tftp in my case) and make a bootloader entry pointing to the kernel for each OS.

Unfortunately, this did not always work. Distros like Ubuntu with fancy graphical installers could not be served entirely of of TFTP and required an NFS share for the rest of the content on the ISO. This was fairly easy to do with a "nfsroot=192.168.0.154:/srv/nfs" string appended to the kernel line in the syslinux configuration. Eventually, I was able to get most common distributions (Ubuntu, CentOS, Fedora, Debian, etc) up and running on my VM, but Arch would not boot.

Since I needed a PXE server for another organization, I had everything up and running a few weeks in advance, and just rsynced all of my data to another Debian x64 server on campus. I figured I'd just open the TFTP port for the duration of installfest so everyone could boot remotely. The night before installfest, I found out that TFTP booting would not work at all over NATs, becaus e the UDP ports used were chosen randomly and therefore can't be forwarded in advance.

With less than 12 hours remaining, our options were limited to:
  • Setting up an iPXE server and handing out USB drives
  • Making another PXE boot server
  • Hauling a server across campus and up serveral flights of stairs
  • Learning IPsec and setting up a point-to-point VPN
  • Using the original (albeit outdated) VM on my laptop
We ended up picking a combination of these and had a rather interesting network configuration. I brought a router to assign DHCP leases and pointed the TFTP boot server to a bridged interface to my VM. We also setup an iPXE server elsewhere on campus, which was much easier to install (yet unsupported by nearly all motherboards). To solve this, I was able to set a menu entry on my PXE VM to point to the iPXE kernel, and we had a few flash drives with the iPXE bootloader to hand out. Unfortunately, the iPXE installation had intermittent connectivity issues, possibly due to DHCP timeouts on my router's dnsmasq server.

Installfest was a much larger success than in years past, probably due to our promotion at Gobblerfest and spamming of all the listservs. We ended up with 27 successful installations in a few hours, mainly composed of Fedora, Ubuntu, and Arch Linux. Less popular distros included Sabayon, OpenBSD, FreeBSD, DragonflyBSD, and Rebecca Black Linux (yes, that's a thing).



The little PXE boot server that could

A few days ago, the Virginia Tech Linux/UNIX Users Group held its semiannual installfest. Overall, the turnout was excellent; we installed Linux in over 25 environments (in a dual-boot or virtualized environment). This is way up from the astounding four or five installations we had last semester. Though, it didn't all go as smoothly as you would expect. We had many challenges with getting into the room (due to lack of Hokie Passport access), as well as challenges getting the router and DHCP server set up properly. However, once we were able to fix the issues we were having along those lines, we were able to turn our efforts to installing Linux and UNIX on peoples' machines.

There were quite a few people who came, a few of which who were experienced in Linux/UNIX, but were having a few weird problems. For instance, a guy simply had a desktop with a solid state drive, but neither Ubuntu nor Arch would recognize it. After a while of troubleshooting, loading drivers, etc. one of our members was able to solve the problem and successfully install Ubuntu. I, personally, took more of a teaching role throughout the installfest. 

A freshman came in around 30 minutes after we opened shop, and I put Arch on his machine as per his requests (and a few recommendations by Calvin and myself). However, he's never even interfaced with Linux or the shell. So, I took a few hours to show him some of the cool parts of Linux (i.e. user-modifiable config files, mounting partitions under directories, and pipes). He was amazed at the level of freedom that Linux offered, and said that he'd definitely come to our meeting on Thursday.

Overall, I believe the VTLUUG installfest was a big success. We had over 6 times as many installations this semester as last, and everyone seemed to be happy with the outcome. The only issue that we had was lack of pizza; there was promise of free pizza, but because there were so many people there, the 6 or 7 boxes of pizza were literally all consumed within five minutes of the pizza arriving. Aside from that, though everyone had fun, and we were able to help out the Virginia Tech community in our own unique way. :)

The little PXE boot server that could

A few days ago, the Virginia Tech Linux/UNIX Users Group held its semiannual installfest. Overall, the turnout was excellent; we installed Linux in over 25 environments (in a dual-boot or virtualized environment). This is way up from the astounding four or five installations we had last semester. Though, it didn't all go as smoothly as you would expect. We had many challenges with getting into the room (due to lack of Hokie Passport access), as well as challenges getting the router and DHCP server set up properly. However, once we were able to fix the issues we were having along those lines, we were able to turn our efforts to installing Linux and UNIX on peoples' machines.

There were quite a few people who came, a few of which who were experienced in Linux/UNIX, but were having a few weird problems. For instance, a guy simply had a desktop with a solid state drive, but neither Ubuntu nor Arch would recognize it. After a while of troubleshooting, loading drivers, etc. one of our members was able to solve the problem and successfully install Ubuntu. I, personally, took more of a teaching role throughout the installfest. 

A freshman came in around 30 minutes after we opened shop, and I put Arch on his machine as per his requests (and a few recommendations by Calvin and myself). However, he's never even interfaced with Linux or the shell. So, I took a few hours to show him some of the cool parts of Linux (i.e. user-modifiable config files, mounting partitions under directories, and pipes). He was amazed at the level of freedom that Linux offered, and said that he'd definitely come to our meeting on Thursday.

Overall, I believe the VTLUUG installfest was a big success. We had over 6 times as many installations this semester as last, and everyone seemed to be happy with the outcome. The only issue that we had was lack of pizza; there was promise of free pizza, but because there were so many people there, the 6 or 7 boxes of pizza were literally all consumed within five minutes of the pizza arriving. Aside from that, though everyone had fun, and we were able to help out the Virginia Tech community in our own unique way. :)