Live data from Hacker News

Hardening SSH with 2FA

gist.github.com

81–90 of 103 posts

Re: Hardening SSH with 2FA

#81

Earlier quoted context omitted.

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. 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 ;)

Re: Hardening SSH with 2FA

#82
post #28

Earlier quoted context omitted.

It sounds like you're trying to do something like Yubikey OTP or U2F with SSH. Both are doable, but I don't think that's the normal way people use hardware tokens with SSH; what I've seen much more is that people use Y4 keys (which are basically pocket HSMs), generate RSA keypairs with them, and configure SSH to accept the public key on the token. This doesn't require any support on the serverside; as far as the serv…

> something like Yubikey OTP or U2F with SSH. Both are doable I would be interested in how you think U2F with SSH is doable. Maybe with a custom SSH server and client? Have you actually see this done in anger?

ssh server trusts internal CA, an application that requires U2F login can issue 5 minute certificates signed by the CA, the ssh session does not close when the login cert expires. See https://github.com/Netflix/bless and https://github.com/gravitational/teleport

Re: Hardening SSH with 2FA

#83

Earlier quoted context omitted.

Those aren't Yubikeys, though. They're Yubico security keys.

Huh, I guess you are technically correct. They are listed on the Yubikey product page, though, and Yubikey is so strongly associated with Yubico that the distinction is easily lost.

Yeah, that's unfortunate, because someone can easily mistake them for Yubikeys. They're basically WebAuthn keys.

Re: Hardening SSH with 2FA

#84
post #71

Development infrastructure like Jenkins has no business being on the internet, so my preferred "second factor" is a VPN, secured with machine specific certificates that offer only VPN connectivity, but not SSH or anything else. This means even if a developer's Git or SSH key is floating around your infrastructure no one without VPN access can get at it, and if a developer loses a laptop there's a good chance you'll h…

Exactly. This is what I employ as one of the safeguards as well. All important resources accessible only to via a jumpbox, and jumbox itself is only accessible in a VPN.

My fear is that if the VPN connection is severed, you're locked out of your environment.

I typically have a public bastion and just shut it down. In AWS you aren't paying for it if it's turned off and you have an "escape hatch" if you need it.

If someone manages to launch another instance or start the stopped one then they would have access, but that's another can of worms.

Re: Hardening SSH with 2FA

#85
post #84
post #71

Earlier quoted context omitted.

Exactly. This is what I employ as one of the safeguards as well. All important resources accessible only to via a jumpbox, and jumbox itself is only accessible in a VPN.

My fear is that if the VPN connection is severed, you're locked out of your environment. I typically have a public bastion and just shut it down. In AWS you aren't paying for it if it's turned off and you have an "escape hatch" if you need it. If someone manages to launch another instance or start the stopped one then they would have access, but that's another can of worms.

With AWS, in an emergency you can always use the console to provision access of some sort: SSH bastion with a public IP, second VPN, etc. This definitely implies that explicit 2FA is needed for console access, but I’m pretty comfortable with using smartphones for that.

Re: Hardening SSH with 2FA

#86

Earlier quoted context omitted.

> 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 posti…

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...

Re: Hardening SSH with 2FA

#87
post #86

Earlier quoted context omitted.

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.

Re: Hardening SSH with 2FA

#88

Development infrastructure like Jenkins has no business being on the internet, so my preferred "second factor" is a VPN, secured with machine specific certificates that offer only VPN connectivity, but not SSH or anything else. This means even if a developer's Git or SSH key is floating around your infrastructure no one without VPN access can get at it, and if a developer loses a laptop there's a good chance you'll h…

...and these days, most VPN logins require 2FA themselves...

Re: Hardening SSH with 2FA

#89
post #81

Earlier quoted context omitted.

> 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?

Re: Hardening SSH with 2FA

#90

There are scenarios where 2FA makes no sense for me. These are local password managers and SSH keys. Rethink this again: If your ssh key is compromised then you have a problem overall. For my point of view there is no real security gain in 2FA ssh key logins because your private key itself is already a secret! Only thing which is important is to set a good passphrase for your ssh key. However I can think of one excep…

As long as you have a passphrase and don't actually circumvent it (by e.g. an agent) you basically already have 2FA (you need access to the key (on your laptop/pc) and you need access to the passphrase (in your head)). But physical 2FA (like smartphone based ones or smartcard based ones) are nice because you can remove them from your computer or destroy them. You can't "destroy" a passphrase, so passphrase and sshkey are not really "independent".
Post reply on HN