Hacker News Reader

Comment by _ytji | Hacker News Reader

I've thought about doing something like this several times, but the proposition of using any tools/libraries/pam modules/etc not installed by default, custom pam/sshd configs, and generally anything "outside of the box" sort of scares me.

I've used 2FA for SSH at $lastjobatmegacorp, however all that infrastructure was supported by a team of people dedicated to such things. How finicky would setting this up for myself be in practice? (Am I being paranoid for NOT wanting to go the extra mile to ensure that I actually have access to my systems when I need it the most?)

View on HN

If all you care about is your SSH key not being stolen, then you can very easily use a YubiKey (or other smartcard..) with SSH via either GPG or PKCS11. Both will mean your key never leaves your YubiKey (or other smartcard...). This doesn't prevent your colleagues from having their key stolen, but does protect yours.

I can use the YubiKey for SSH from Linux, Mac, Android phones without issue, and I keep several YubiKeys with my keys on them so it's extremely unlikely I'll loose them all at once.

Re the paranoia - if you're really the only person who can fix something, and you have lost your closest key, then - the thing in need of fixing can wait till you get home to your second key ;)

I'm less worried about losing a hardware key than I am about something breaking in a mysterious way and locking me out! My initially question was really about personal (unshared) systems. (I don't know - a random auto-update busting a non-standard PAM module and preventing it from loading, or even something just changing the PAM configs on its own, doesn't seem impossible to me). I'd definitely keep a spare if i went the Yubi route.

It's pretty hard to permanently get locked out. In a pinch, you can always mount the disk in another machine, fix whatever is wrong, and boot the original machine back up.

Or if you rent a server from a provider they usually offer a rescue mode boot option.

The Google auth PAM module is very straightforward: https://github.com/google/google-authenticator-libpam

You could run a separate instance of say, dropbear on another port as a failsafe, until you're comfortable. Or maybe firewall it off to a set of fixed source ips.

Neat, this might be the lowest-friction approach I've seen so far. (My distro even has a `libpam-google-authenticator` package to boot)

I wrote a blog post on this recently, using only open-source tools that don't come from big corps. To have TOTP second factor on Debian (like) systems you need only libpam-oath module on the server, and perhaps an open-source app like FreeOTP (RedHat) on a smartphone.

I'm afraid to link it here because the traffic might kill my puny box.

> I'm afraid to link it here because the traffic might kill my puny box.

So what if it does?

Presumably it isn't a "critical" host so the worst that could happen is, what, no one can read what your blog posts for a little while? Eventually, the traffic will go away and things will go back to normal, yeah?

I assume that (part of) the reason for writing your blog post was so that others could read it. Yet, by not posting the link, you are ensuring that we don't -- even though pretty much all of us in this comment thread are the target audience.

Alternatively, as someone else mentioned, there are things like the Internet Archive.

(FWIW, several years ago, a page on my blog was linked by The Atlantic one morning and shortly thereafter it also hit the front page of (IIRC) both Reddit and HN. The only way I figured out that "something was up" was due to the huge number of "new follower" notifications I was getting from Twitter as I was driving to work. At the time, I was running WordPress on a little VPS with 1 CPU core and 768 MB of RAM and it handled the ~115,000 page views just fine that day -- although I did have caching and such in place. YMMV.)

You make many valid points there.

Here's the link, let's see what happens:

Caveat lector: This is a "beginner" guide targeted at Raspberry Pi users, ignore the Pi related parts.

I intend to publish a second part about using keys instead of passwords.

https://2byt.es/post/totp/

The blog content is open source on GitHub so feel free to raise issues if necessary.

Nice walk-through. Re:bandwidth worries, for this crowd, you probably just link to: https://github.com/2bytes/website/blob/master/content/post/t...

I doubt hn will take down github...

I had considered that, but as someone else else pointed out, what have I got to lose if it's taken down?

At least with links to my blog I can use the access logs for an idea of which articles people find interesting (I don't do other metrics/analytics due to my philosophy).

At the moment I'm trying to build a new box to host this on but it seems Caddy has broken source builds (again) and I need plugins for my Git hooks and Hugo build.

Searching around for an alternative.

Edit: and thanks for the compliment.

Caddy's source builds are still working; just took a couple hours for me to figure out and update the instructions.

> I'm afraid to link it here because the traffic might kill my puny box.

Setup Cloudflare, which is free and easy to use. Or, just post an Internet Archive wayback machine copy of your post would be good enough.

Given that he:

> I wrote a blog post on this recently, using only open-source tools that don't come from big corps.

I doubt he wants to use CloudFlare ;)

Philosophically is using CloudFlare or whatever CDN any worse that using the normal internet infrastructure in terms of software freedom?

Definitely, all traffic is readable by CloudFlare. Whereas if you have your own SSL certs everything going through the "normal internet infrastructure" is encrypted (in theory your webhost is able to get to it, but definitely not as easily - and this is only an issue if you rent a server).

On top of that there are many arguments against CloudFlare when it comes to an open and decentralized internet.

EDIT: didn't read the Philosophically in your comment. CloudFlare does many things against an open internet, for a long time they blocked (or required excessive captchas) for all TOR users.

Unless you're hitting a database for every connection, even a puny box ought to be fine.

Static site, no DBs. Link's posted so let's see!

Looks great. If it's static, try using netlify and cloudflare; I've used cloudflare with great success for years, and I just tried netlify (works great & free).

I had to do a pam config recently. Having only tweaked a few settings previously, it was kind of intimidating as I was doing some security-type stuff and had to rewrite the config. I locked myself out more times than I care to remember; thank God I was working (mostly) in virtual machines. This is especially a problem since the necessary pam settings vary from distro to distro.

If you really want to, test it on a vm that replicates your machine first and make sure you document exactly what to do to get it working. To be clear, it should be fine if you're just adding a module, but sometimes getting the exact settings can be hard, so make sure to do it in a vm first and be careful. Just trying to keep others from going through what I went through.

Megacorps have their own reasons to select technology. Your best bet is probably to go with a Yubikey (or something like it). It's about $50 and it's what several of the big Linux projects themselves use so it's well tested and documented.

Or one of the Nitrokeys, which are generally more affordable and have open source firmware:

https://www.nitrokey.com

Do they offer a good solution to the dual problem of:

- if you can flash/read everything, so can an attacker

- if you have a blackbox nothing can peer into, how can you trust the device?

It looks like the very first FAQ answers that:

1) You generate your own root keys, to deploy onto the device,

2) You can't read the root keys back off the device once it's deployed.

That doesn't quite answer my question, I think.

My statement was that:

- if you have an opaque enclave on the device (e.g. a black box you can't peer into), you can't know what it's doing

- if you don't, you can read the private key bits out

Your statement was that it has a private enclave you cannot extract key material out of, which resolves the latter half of the question, but not the former, I think?

I'd never done anything much with pam before but found it relatively easy to get PrivacyIDEA working on CentOS, it's even easier if you're using Ubuntu. https://www.privacyidea.org/ and Cornelius is really helpful.

Reply on news.ycombinator.com