Category: bsd

The bleeding-edge OpenSSH supports using an AuthorizedKeysCommand statement in sshd_config to get the authorized_keys file for a user. This lets you store your authorized_keys files in LDAP, but avoids linking OpenSSH against OpenLDAP. (You could actually use any data store for your back end, but LDAP is both the most popular and what I have.)

Your AuthorizedKeysCommands script should take one argument, and return a series of authorized keys, one per line. CentOS has a script, which I previously mentioned, and one of my readers was kind enough to put together an OpenBSD port for it.

But there’s some problems with the CentOS approach, from a cross-platform perspective. While it’s fine on CentOS, porting and installing it on other platforms is more difficult than it needs to be. I’d really like something that has very few dependencies, is easy to install, and is easily portable across platforms.

When setting up a couple of Ubuntu boxes I came across an Ubuntu AuthorizedKeysCommand script. His approach is much simpler than the CentOS approach, but his script didn’t work for me out of the box, and it wouldn’t work on other operating systems without modification. But it inspired me to write my own script, one that works across all of my operating systems, using only the tools I already have on all of my servers. My results follow. But before I offer my script, I feel obliged to warn you.

The bad news is, I am not a programmer. I have been told by multiple independent parties that my code makes the Baby Jesus cry.

The really bad with this is that you need an ldapsearch command that returns your public keys, and this command is hard-coded with this script. The ideal script would read the system ldap config, but you’d probably have to hard-code a path to ldap.conf anyway.

The appalling news is, I wrote it in Perl. Why? Well, the evidence indicates that I am insane. But every server in my environment runs Perl, and it’s been ten years since I used enough sed/awk to make this work. A proper authentication credentials script would not use Perl.

I’m not suggesting that you take my code. I’m hoping to motivate one of my programmer readers, whose code only makes the Baby Jesus grimace a little, to do better. I mean, I’ve set a pretty low bar here.


#!/usr/bin/perl
#takes one argument, the username to get the keys for
die unless $ARGV[0];

s/^ //;
print;
}
print "\n";


One catch with this is that you’re processing the raw output of ldapsearch. An acceptable ldapsearch will return keys that look something like this:


...
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAw9zmtbk8bT+7OVpVvzuYYQqRhF8j
...blah, blah, blah...
ilXzBw== rsa-key-20110114


Initially, my LDAP searches returned some keys that looked like this:
...
sshPublicKey:: c3NoLWRzcyANCkFBQUFCM056YUMxa2MzTUFBQUNCQVBhZmNhemdmUHI1T29DdFp
...blah, blah, blah...
y5sb2NhbA==


This key doesn’t start with ssh-rsa or ssh-dss, and it doesn’t even look like a SSH key. But if you look at the key in a graphical tool like phpLDAPAdmin, it has the leading ssh-rsa. In my case, the key had an extra carriage return at the end of the key, which meant that ldapsearch had to base64 encode it. Get rid of extra whitespace. The LPK patch doesn’t notice that space, but a simple external script does.

Of course, if someone wanted to write an AuthorizedKeysCommand that was portable, handled that encoding, and didn’t suck as bad as mine, it wouldn’t hurt my feelings at all. Really.

The BSDCan 2013 call for proposals is open. As a BSDCon committee member, it’s my responsibility to get you lot to submit interesting papers. So: submit!

More than once, I’ve been asked something like “How can I get a paper accepted at BSDCan?” or “Why was my BSDCan paper rejected?” Here’s my answer to that general question. Lots of this applies to any conference, but as I’m not on the committees for those other conferences, I can’t claim any authority there. Other conferences have their own ideas, and other BSDCan committee members might have independent thoughts as well.

The purpose of a BSDCan paper is not to advertise the presenter’s work, but to put butts in seats. Sometimes these overlap. I want someone looking at the BSDCan schedule to say “Wow, I HAVE to go to this!” But “be interesting” isn’t exactly useful advice. Some of this might be.

1) Present an topic that hasn’t been covered before. The previous proceedings are all available online. Some topics come up every year. Don’t submit those unless you have a fresh new take on them.

2) Tell us why YOU should be the one to present your topic. We frequently get multiple similar proposals, and have to choose between them based on who we think might do the best job. Don’t assume that everyone on the committee knows who you are. One of us probably knows that you run weaselBSD on twelve thousand workstations, but they probably won’t share than information with everyone else. (Paper selection is done via web form, which isn’t as conducive to back-and-forth discussion as in-person or mailing list discussions.) More than once I’ve had someone come up to me at a conference and say “Why did you have so-and-so report on X? I have forty times as much X as the speaker you chose!” My answer is, “You didn’t TELL US that you had so much.” I am not telepathic.

3) We get many FreeBSD proposals. I want more Net/Open/Dfly proposals, as well as for projects and devices based on them. Non-F/N/O/D BSD papers have much smaller audiences, so a paper on them has to be very interesting. Again, butts in seats.

4) Include “lessons learned.” Anybody can read a man page. If you were involved in recovering from the recent FreeBSD security incident, you should submit a paper about it. If you deployed OpenBSD in a nuclear submarine and learned about the importance of the little radiation-detection badge, you should submit a paper. “Lessons learned” implies that you made mistakes, and can upgrade your talk from the merely technical to a bit of a story. Don’t be afraid to embarrass yourself, we’ve all been there. Sharing mistakes helps connect your presentation to the audience.

5) Tell us what the audience will get out of the talk — e.g., if it’s a sysadmin talk: “Attendees will be able to configure weaselBSD’s anti-ferret features and understand how they integrate with email and Web.”

6) Spelling and grammar are not pimple cream, to be dabbed on where needed. If you’re going to indulge in floccinaucinihilipilification, you’d better be able to spell it.

7) Speaking of floccinaucinihilipilification, you’re better off saying why your stuff is awesome as opposed to running down someone else’s work. I know many reasons why computers suck. Learning something to make my job suck less is good.

That’s what I look for, at least. Others have their own opinions. And if you think a little bit, you can make your proposal answer all of these. Unless you’re running weaselBSD, that is…

Now: submit!

As Henning reviews the Absolute OpenBSD manuscript, he’s pointed out items that I’ve missed. Some of these are only documented in man pages, while others don’t seem to really be documented anywhere except in the source code. Here’s an interesting tidbit he pointed out that I haven’t seen anywhere other than Henning’s email. (Having said this in public, I’ll now find all sorts of examples that I missed, such as Henning’s slides from EuroBSDcon 2010.)

You can log specific connections to separate log devices, for simpler debugging. You need the log rule near the beginning of your ruleset, but it doesn’t have an effect on whether a packet is passed or blocked, or how it’s translated. Here’s a pf.conf line to tell PF to watch for connections from 192.0.2.226 to 203.0.113.34.

match log (matches) from 192.0.2.226 to 203.0.113.34

Now watch the log interface, searching for the destination address:

# tcpdump -n -e -ttt -i pflog0 ip host 203.0.113.34
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Dec 17 17:40:25.071592 rule 2/(match) block out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384 (DF)
Dec 17 17:40:25.071600 rule 5/(match) pass out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384 (DF)
Dec 17 17:40:25.071604 rule 5/(match) pass out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384 (DF)
^C

You get the number of every rule that matches the packet. If you use NAT, it prints original and destination addresses. With my wussy PF rules, this isn’t terribly exciting. With more complicated rules, however, it makes debugging rulesets much easier.

This is the sort of useful information you’ll get if you preorder the new Absolute OpenBSD. (See how I subtly slipped that in? I’m getting good at this marketing stuff.)