Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH: Best practices

blog.0xbadc0de.be

Post reply on HN
Print view View original

111–120 of 123 posts

Re: SSH: Best practices

#111

Post by fanf2 »

superuser2 wrote: post #80
hackercomplex wrote: post #63

Developer laptop compromise is probably the biggest security risk that any startup company faces, because the developer laptop is an uncontrolled environment with a lot of "attack surface" which may have been previously compromised. In my view there are emerging best practices in this area. There are two ways to reduce this risk and both are controversial: 1. Force developers to only develop software using an SSH ter…

(Disclaimer, unicorn employee.) I'm confused. Are you implying people write company code on personally owned laptops? That's insane! 1. Company walks you through setting up FileVault (with key escrow) and VPN client, generating and uploading SSH public key immediately after unboxing laptop. 2. OneLogin + Duo (or pick your SSO/2FA scheme) for everything - internal webapps, GMail, etc. 3. SSH keys managed by Puppet. 4.…

If you are using an ssh agent, it is a good idea to delete the keys when you lock the screen or sleep your laptop. On Mac OS X you can do this with Hammerspoon: http://fanf.livejournal.com/139925.html

Re: SSH: Best practices

#112

Post by tbe »

> f=$(mktemp) && ssh-keyscan korell > $f && ssh-keygen -l -f $f && rm $f

> Unfortunately ssh-keygen does not support input from stdin, so this example is slightly more complicated than it should.

Any shell that supports process substitution can fix this for you with something like;

ssh-keygen -l -f <(ssh-keyscan korell)

Re: SSH: Best practices

#113

Post by Piskvorrr »

throwaway2048 wrote: post #82
aris_ada wrote: post #35

Earlier quoted context omitted.

Have each team member generate his own key. Copy everyone's key in a folder and have a script to generate an authorized_keys file. Use puppet or chef (or anything else) to dispatch the authorized_keys on every server. A single shared key is a security disaster waiting to happen.

did you read the article? ssh certificates with revokation are a much more workable solution

There's the up-front cost of setting them up, and perhaps tool support (pubkey/agent auth is widely supported; X.509...not so much).

Re: SSH: Best practices

#114

Post by LinuxBender »

Piskvorrr wrote: post #110
LinuxBender wrote: post #105

Earlier quoted context omitted.

I don't recall even remotely suggesting the sky is falling. If nobody fixes this, it doesn't affect me. I have Multiplexing disabled everywhere that I care about. The constant news of companies getting popped is actually quite entertaining. The only thing folks may be concerned about is that if too many companies get popped, there may be some heavy handed legislation that starts to affect people. Even that I am perfe…

ahem "It also means, anyone using the defaults in OpenSSH is not PCI compliant."

I wouldn't worry. Not every auditor will catch this.

Re: SSH: Best practices

#116

Post by LinuxBender »

Piskvorrr wrote: post #109
LinuxBender wrote: post #104

Earlier quoted context omitted.

This didn't exist in 2000. It was created and made default on the server in OpenSSH 5. OpenSSH 5 did not make it into enterprise distros for quite some time. There are literally tens of thousands of articles telling folks to enable ControlMaster (Multiplexing) on the client to "make ssh faster". You would be hard pressed to find a devops shop that isn't already using ControlMaster in their ssh client config. There ar…

This specific mechanism didn't exist in 2000; the behavior is no different from the ILOVEYOU virus: user runs code, code does something malicious, code contacts cracker. It all boils down to "if you require security, you can't have a default-open environment"; blaming a specific tool seems ... strange.

Strange as it may be, this virus will never be detected as a virus. That is why I am blaming the default settings in the tool.

Re: SSH: Best practices

#117

Post by Piskvorrr »

hobarrera wrote: post #59

What amazes me about these articles is that they keep recommending NOT to use password-based logins for SSH: Why are people still using that?

People are still using FTP, for what it's worth. In other words, the same old: ignorance ("we've always done it like this") and/or apathy ("meh, we're not a cracker target").

Re: SSH: Best practices

#118

Post by Piskvorrr »

LinuxBender wrote: post #114
Piskvorrr wrote: post #110

Earlier quoted context omitted.

ahem "It also means, anyone using the defaults in OpenSSH is not PCI compliant."

I wouldn't worry. Not every auditor will catch this.

Well, that's security through obscurity: planning to fail an audit if the auditors dig too deep, but betting on a surface-level inspection.

Re: SSH: Best practices

#119

Post by throwaway2048 »

Piskvorrr wrote: post #113
throwaway2048 wrote: post #82

Earlier quoted context omitted.

did you read the article? ssh certificates with revokation are a much more workable solution

There's the up-front cost of setting them up, and perhaps tool support (pubkey/agent auth is widely supported; X.509...not so much).

ssh certificates are not x.509, though they are designed around a PKI.

Re: SSH: Best practices

#120

Post by Piskvorrr »

throwaway2048 wrote: post #119
Piskvorrr wrote: post #113

Earlier quoted context omitted.

There's the up-front cost of setting them up, and perhaps tool support (pubkey/agent auth is widely supported; X.509...not so much).

ssh certificates are not x.509, though they are designed around a PKI.

Thanks for the correction.
Post reply on HN