News for hackers. Stuff that matters.
Re:Best Practices for Securing SSH by oofbey on Wednesday January 05, 2022 @04:33PM (#29815264)
The article says to use two-factor-auth (obviously a good idea) but says nothing about HOW you add 2FA to SSH. Does anybody have pointers? I'd love to add 2FA to my bastion hosts, but don't want to put a ton of effort into doing so.
Re:Best Practices for Securing SSH by beermonster on Wednesday January 05, 2022 @04:55PM (#29815577)
Since OpenSSH >=8.2 you can use FIDO2 and security keys. See https://www.stavros.io/posts/u2f-fido2-with-ssh/
Re:Best Practices for Securing SSH by nyolfen on Wednesday January 05, 2022 @06:44PM (#29816937)
it's pretty easy to set up TOTP 2FA using google authenticator's PAM module: https://www.digitalocean.com/community/tutorials/how-to-set-...

a password-protected SSH key is also two factors

Re:Best Practices for Securing SSH by anjbe on Wednesday January 05, 2022 @06:57PM (#29817056)
> a password-protected SSH key is also two factors

Not really. By default SSH keys are kept in a private subdirectory of $HOME. An attacker who has access to it is very likely able to modify the user’s $PATH, trojan the passphrase prompt, and so on. Thus in many real‐world situations it collapses to one factor.

Contrast that to an SSH key tied to a WebAuthn token with "ssh-keygen -t ed25519_sk"—even a fully trojaned machine would not be able to freely initiate sessions with the compromised key.

Re:Best Practices for Securing SSH by u801e on Thursday January 06, 2022 @01:02AM (#29820027)
What about requiring both the key and the password to authenticate?
Re:Best Practices for Securing SSH by pigbearpig on Wednesday January 05, 2022 @11:58PM (#29819602)
This post is basically an ad. "Hey look at these generic things to secure SSH, maybe you should pay us instead."
Re:Best Practices for Securing SSH by VTimofeenko on Wednesday January 05, 2022 @04:36PM (#29815315)
I set up something like this [1] in the past. It relies on pam letting in the user if and only if that user provides the generated number. Do note that messing up pam is easy and may lock you out, so have a backup/snapshot, rescue shell or an open session when you are configuring it.

[1]: https://ubuntu.com/tutorials/configure-ssh-2fa#1-overview

Re:Best Practices for Securing SSH by old-gregg on Wednesday January 05, 2022 @06:08PM (#29816505)
The blog is hosted on https://goteleport.com/ - the open source SSH implementation which natively supports 2FA.

Full disclosure: I work there, but I am not the author.

Re:Best Practices for Securing SSH by oofbey on Wednesday January 05, 2022 @07:37PM (#29817467)
Ironically, I think the blog post would have been improved with some explicit self-promotion.
Re:Best Practices for Securing SSH by seldomcomment on Wednesday January 05, 2022 @04:42PM (#29815400)
you can do so also without google authenticator

in a previous HN post I've copied my quick 'n dirty notes

[1]: https://pastebin.com/yYzSrM61

Re:Best Practices for Securing SSH by u801e on Thursday January 06, 2022 @01:00AM (#29820013)
It's possible to configure sshd to require both password and key based authentication. That is, you have to have access to the private key and know the password.

You can set this up via the RequiredAthentications2 setting off you're just using protocol V2.

Re:Best Practices for Securing SSH by R0b0t1 on Wednesday January 05, 2022 @05:33PM (#29816064)
It depends what you mean by 2FA. Older definitions allow password protected keyfiles. If you mean active 2FA, you need a PAM plugin and usually a provider, but you can host your own. Look at e.g. Yubikey.
Re:Best Practices for Securing SSH by oofbey on Wednesday January 05, 2022 @07:38PM (#29817485)
I would take password-protected keyfiles - I would love it in fact. But AFAIK there's no way for the server to know if the keyfile was password protected or not. Is there? It seems like it wouldn't be reliable - you kinda have to trust the client to tell you the truth about whether or not it decrypted the keyfile before using it.
Re:Best Practices for Securing SSH by R0b0t1 on Wednesday January 05, 2022 @09:17PM (#29818304)
Why does that matter? There's no way to ensure your employees aren't writing down their passwords. If you don't trust someone to follow procedure then don't employ them.
Re:Best Practices for Securing SSH by oofbey on Wednesday January 05, 2022 @11:17PM (#29819321)
Security always exists in layers. Policy is a layer - e.g. asking people to do something. Another layer is to have a system to remind/enforce that policy. Writing down passwords is (generally) an obviously stupid thing to do, perhaps worthy of termination. But forgetting to put a passphrase on one SSH key when you regularly use a dozen of them for different purposes - this is absolutely not an offense worthy of termination.
Re:Best Practices for Securing SSH by R0b0t1 on Thursday January 06, 2022 @11:02AM (#29825237)
If that's what you need it's possible to generate and issue keys from a centralized host just like with TLS. You can even set up login with SSH/TLS certs, which can be password protected.
Re:Best Practices for Securing SSH by lnxg33k1 on Wednesday January 05, 2022 @04:36PM (#29815305)
Usually with authentication on linux, pam is a good starting point https://duo.com/docs/duounix