OpenSSH 6.2 adds support for two-factor authentication

OpenSSH releases are always interesting, they never go without at least introducing one feature that makes ~~paranoid~~ security conscious people and no exception is OpenSSH 6.2 which was just released. In particular in this case I was very happy to read:

sshd(8): Added support for multiple required authentication in SSH
protocol 2 via an AuthenticationMethods option. This option lists
one or more comma-separated lists of authentication method names.
Successful completion of all the methods in any list is required for
authentication to complete. This allows, for example, requiring a
user having to authenticate via public key or GSSAPI before they
are offered password authentication.

What’s going on is not extremely obvious, but basically it means that you can now chain, instead of replace, the authentication method. Okay, step back. Have you ever noticed that when ah SSH connection fail, often enough you have a message saying public-key,keyboard-interactive? That means that it tried, in sequence, the two options, and when they failed, it refused the connection. Any of the two would have been enough for a successful connection. This is akin to the sufficient option in PAM, which means that a single positive result is enough to produce a valid login. The new option in this version of OpenSSH is equivalent to PAM’s requisite option, so if any of the configured login methods fails, the connection is dropped.

So why is this important? Well, this allows two-factor – or actually multi-factor – authentication, as now just having access to your laptop with an unprotected SSH key might not be enough to enter your critical servers. In my case, that would become at least a three-factor authentication as I could make it pass through my SmartCard (which requires the physical card and knowledge of its PIN), and then ask me the password itself.

Since the second factor can be PAM itself, there is no reason why you cannot add more than one factor there. In particular you might remember that just last year I looked into two-factor authentication options and in particular I looked into DuoSecurity — unfortunately, using DuoSecurity as is with PAM is a bit of a mess. I did send a patchset to upstream to make the PAM module more useful, and reliable – among other things making it feasible to use with sudo, so that get asked the second factor only when executing commands as root – but upstream does not care. It doesn’t fit their marketing and their main consulting target, so they basically left me dangling there with a patchset that is now probably to forwardport.

If you’re interested in getting a version of duo_unix with my patchset apply available in Portage (and available in source form for other distributions), i suggest you poke Jon and Doug at DuoSecurity, and ask them about it. If they were to ask me I would be glad to forwardport the patches, and change them as needed if they don’t like the precise way I wrote them. But I reached out enough myself, trying to help them with the packaging, – including proposing to just chat on the phone about what they want to do with it while I was in the US – at this point it’s their turn.

Alternatively, I’m pretty sure you can use YubiKey but I never ended up having one of them in my hands.

Securing logins, Duo Security experience

In January, I’ve ranted about not being able to get a Yubikey so that I could test some kind of OTP token for logging in to the FTP of one of my servers, so that my friend who is maintaining the WordPress install could work even from his office (where SSH does not work).

In the comments of that post Dug Song pointed me to his company, Duo Security which actually seemed like a good idea for what I had in mind. It provides support for both software and hardware token generators, has a clear API, and has a few integrations already available. Unfortunately now we’re in April, and you’ve seen nothing from me discussing it before. Why?

Well, mostly it feels like there’s a problem with timing. When I ranted about Yubikey, it was the week before leaving for FOSDEM, so I was finishing up job stuff and I couldn’t look at it until I came back from my combined trip (after FOSDEM I came here to Los Angeles). So when I started looking into it, I was at first only able to provide them with some build system changes.

When I then decided to spend some more time on it since the need to set up FTP increased, I started fighting with vsftpd to get it to accept using their PAM integration to use log in. The end result has been … a lot of time spent. Unfortunately the original design of their PAM implementation only works with a normal challenge-response authentication method (so it wouldn’t work with “safe” sshd PAM configurations), and more to the point, it would require asking two passwords, which an FTP client can’t.

While I first hacked it around, I was able to implement while here in LA last month a more complete patchset that implements a proper way to use it as a “single factor” authentication, or as a secondary push authentication. Unfortunately, I haven’t yet received a response about this patchset, which is why you won’t find duo_unix in Gentoo as it is.

The situation is getting more complex now: from one side I’m going to cut down most of my contract work in Italy as that’s not making me any money (seriously I think that even with all my ranting Flattr and Google AdSense are making me more money than website hosting), so I don’t foresee the need to provide users with some kind of strong authentication on the long term. From the other, while the firmware I’m working on doesn’t really care about this kind of strong authentication, the organization for which I’m working could use something like this. Of course, if the upstream for the package is not responding, that’s bad enough not to consider this.

I’m honestly not sure what to say since Dug and Jon seemed like friendly and helpful guys, maybe they are just too swamped with other requests and they can’t process mine as well, but whatever the reason, the issue I’m afraid is going to be a lapsed sale for them. Guys if you’re reading this, please let me know something, okay?

How not to sell me something — Why I won’t be maintaining Yubikey software directly in Gentoo

You probably remember my previous notes about WordPress, FTP and the problem with security. At the end after a (boring) set up session I was able to get vsftpd provide FTPS service, which should be usable both by WordPress and by Dreamweaver, so that my friend the webmaster can upload through it directly.

This is important because as it happens I have another prospective customer who’s going to run WordPress, and FTPS now start to look more interesting than SSH, as it doesn’t require me to give shell access to the server either.

Unfortunately I’m a bit worried (maybe more than I should be) for the use of standard passwords rather than certificates or keypairs for authentication. Which meant I went tried to think of other alternatives.. of which there are mostly two: Google Authenticator and YubiKey .

The latter I knew by name already because I proxy-maintain the required software for Brant, and I know it’s outdated already and would require a new maintainer who can deal with those packages – I already posted about hardware-related maintenance for what it’s worth – so it was my first choice: while it meant I had to spend some money, it would have solved my problem and improved Gentoo, even if just for a tiny bit. The price for YubiKey devices is also low enough that, if I felt like providing more FTPS access to customers, I could simply bill it to them without many complaints.

So I went on the manufacturer’s (Yubico’s) website and tried to buy two of them (one for me to test and set up, and one to give my friend to access the server); despite publishing the prices in dollars, they sell through Sweden and UK, which means they are part of EU’s VAT area, and me being a registered business within EU, I should receive a reverse-charge invoice by stating my own VAT ID… never had much of a problem with it, as many of my suppliers are sparse through Europe, I registered for the “foreign-enabled” registry right when I opened business — don’t ask me why Italian (and Spanish as far as I can tell) business owners are not enabled by default to have intra-union suppliers.

Now trouble starts: since, as I just noted, not all VAT IDs are valid to use for intra-union trade, there has to be a way to ensure you’re dealing with an acceptable party. This is implemented through VIES the VAT Information Exchange System which, for what concerns Italian businesses, only tells you a boolean result of valid/invalid (and not the full registration data that most other states seem to provide). I knew VIES from a previous business agreement, but I never cared much. Turns out though that most e-Shops I encountered validate the VAT ID after order completed — or in the case of Amazon it seems like they check their internal database as well as VIES.

Yubico instead validates the request through VIES at the time of registration:

VAT Number could not be validated with VIES at this time. This typically happens when the service is under maintenance. Please retry after some time. For urgent orders, please contact order@yubico.com

Considering that the VIES website has a long disclaimer (which I can’t quote here for reasons that will be clear in a moment) stating that they do not guarantee the availability of the service at any time, and only seem to guarantee the validity of the data to the extent that the law ask them to (which probably means “as long as the states’ own databases are correct”), relying on such a service for registration is .. bad.

The VIES website is indeed down since at least 11am today (over four hours ago as I write this); for a moment they also gave me an interesting page (which I forgot to save), telling me that there were too many requests’ failures from “my IP address” … listing an IP address in the ²¹²⁄₈ range — my actual IP address is in the ⁹⁴⁄₈ range.

What’s the end result here? I’ll probably waste some more time trying to get Google Authenticator; Yubico basically lost a customer and a (possible) contributor by trying and failing to be smarter and won’t have a dedicated maintainer in Gentoo in the near future. It’s sad, because it seems to be easily the most cost- and time-effective solution out there (Google Authenticator is free, but it requires a greater investment of time, and time is money as we all should know).