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

61–70 of 123 posts

Re: SSH: Best practices

#61

Post by thatcks »

clinta wrote: post #6
r0muald wrote: post #5

I thought using per-service SSH keys was an useful mitigation against e.g. GitHub public keys being exposed: - https://blog.benjojo.co.uk/post/auditing-github-users-keys - http://arstechnica.com/security/2015/06/assume-your-github-a... - https://news.ycombinator.com/item?id=9645703

Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.

Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames). This may be a trivial information leak or it may be one that you consider important; it depends on the situation.

Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mitigates this risk significantly.

Re: SSH: Best practices

#62

Post by cyphar »

thatcks wrote: post #61
clinta wrote: post #6

Earlier quoted context omitted.

Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.

Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames). This may be a trivial information leak or it may be one that you consider important; it depends on the situation. Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mit…

> Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames).

How? That's now how public key auth works...

> Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mitigates this risk significantly.

This is true for other reasons, and you can automate it with some shell scripts.

Re: SSH: Best practices

#63

Post by hackercomplex »

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 terminal (by first connecting to a developer VPN via 2FA and then sshing into their secure development environment where may use tools like tmux, vi, and their programming language of choice to get the job done). In this scheme copying source codes or security credentials to a developer laptop is considered a violation and becomes a fireable offense no questions asked.

2. Require all developers to run a private USB-bootable linux desktop shell which is known to be clean. In this case they remain free to utilize modern desktop editors and code emulators (such as android simulator). It's even possible to setup secure persistence in these environments so that the developer's browser configuration, network/vpn config, dotfiles, apt installs, etc are stored on an encrypted filesystem on USB device. The reason why a USB image is preferred is because it's annoying to ask a new employee to repartiation her personal harddrive.

My suspicion is that as more of the tools developers need to rely on are cloud-based: (example: github, cloud9, jenkins, etc) we will eventually see these modern best practices against client-side attacks being adopted more broadly. The quality and reliability of hot-bootable ultra secure cloud operating systems has gone thru the roof over the past couple of years and I assume this trend will only accellerate due to the fact that Google Chrome OS continues to penerate more of the market and consumers are getting used to it.

TLDR: ssh keys existing on developer harddrives is an info-sec anti-pattern, they should only ever exist in system memory or in an encrypted partition on a USB stick.

Re: SSH: Best practices

#64

Post by thatcks »

cyphar wrote: post #62
thatcks wrote: post #61

Earlier quoted context omitted.

Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames). This may be a trivial information leak or it may be one that you consider important; it depends on the situation. Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mit…

> Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames). How? That's now how public key auth works... > Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mitigates this risk significantly. This is true for other reasons, a…

It's how the SSH protocol itself works. When the client connects to a server, it sends the (remote) username and then a series of public keys. If the server will accept the current public key, it asks the client to authenticate with that key to show that you hold the private key; if it doesn't, it says 'try again'.

This means that a malicious client with just the public key can probe to see if a server will accept a given username/public key combo. If the server does, it will challenge you to authenticate that you hold the private key (which you'll have to fail, since you don't have it).

Re: SSH: Best practices

#65

Post by infinite8s »

deathanatos wrote: post #40
bisby wrote: post #30

Weird, where I work we're not allowed to use key auth. They claim it's for PCI since they can't enforce that the keys are passworded/encrypted.

That's an odd tradeoff. I'm going to have to disagree with the sibling noting that "compliance != security". Here's the thing: they say they can't enforce users to encrypt passwords (hogwash; you can have a local agent that checks that), but do they check that users are providing good passwords? I have much more faith in a randomly generated key than I do in a human-generated password. The former pretty much requires…

The parent comment is discussing encryption of the private key with a password, not passwords for connecting to the server.

Re: SSH: Best practices

#66

Post by [deleted] »

deathanatos wrote: post #40
bisby wrote: post #30

Weird, where I work we're not allowed to use key auth. They claim it's for PCI since they can't enforce that the keys are passworded/encrypted.

That's an odd tradeoff. I'm going to have to disagree with the sibling noting that "compliance != security". Here's the thing: they say they can't enforce users to encrypt passwords (hogwash; you can have a local agent that checks that), but do they check that users are providing good passwords? I have much more faith in a randomly generated key than I do in a human-generated password. The former pretty much requires…

[deleted]

Re: SSH: Best practices

#67

Post by LinuxBender »

AnthonyMouse wrote: post #60
LinuxBender wrote: post #54

Earlier quoted context omitted.

OpenSSH allowing this behavior by default is in itself the vulnerability.

Then how do you exploit it without assuming the ability to execute arbitrary code as the user?

Some time soon I will put something up on github so you can test this methodology. It probably won't be tonight though.

Re: SSH: Best practices

#68

Post by EvanPlaice »

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…

3. Never grand direct SSH to access the the staging/production environment.

Automate the build and deployment environment on a system that developers don't have direct access. Instead of pushing changes, the bot pulls a specified release branch, builds, tests, and deploys the code. All without human interaction.

If malicious code were somehow introduced from a developer's environment, it would be recorded and reflected in the commit history.

AFAIK, that's how GitHub manages deployments via HubBot. See https://www.youtube.com/watch?v=NST3u-GjjFw.

-----

To take things a step further, public-facing environments should be made immutable wherever possible. With the entire system being built and released as a whole. Docker alleviates some of the complexity and overhead but I think this space is where Unikernels have a lot of potential to shine.

There's a very good talk about how the Wunderlist team used chaos and frequent destruction of their envronments to overcome fear and uncertainty here. https://www.youtube.com/watch?v=RrX_28s70ww&app=desktop.

Emphasis being placed on the the frequent disposal and recreation of environments rather than building long-running persistent environments.

This setup probably won't work for long-lived systems (ex databases). In those cases, access via a transient environment like a USB bootable OS would be ideal to prevent persistent viruses/trojans. Ironically, the best current options are security-focused distros like KaliLinux that put a special emphasis on avoiding persistent state. Maybe one day soon we'll see an admin-focused OS that better fits this role.

Re: SSH: Best practices

#69

Post by jvehent »

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…

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

It's also the least likely to happen. Attackers will have broken deep into your database due to poor webapp security before getting a hold of your ssh private key.

Not that SSH security doesn't matter. It's easy enough and carries enough risks that putting some effort into it is worthwhile.

Re: SSH: Best practices

#70

Post by jvehent »

EvanPlaice wrote: post #68
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…

3. Never grand direct SSH to access the the staging/production environment. Automate the build and deployment environment on a system that developers don't have direct access. Instead of pushing changes, the bot pulls a specified release branch, builds, tests, and deploys the code. All without human interaction. If malicious code were somehow introduced from a developer's environment, it would be recorded and reflect…

> 3. Never grand direct SSH to access the the staging/production environment.

Most complex systems fail in unexpected ways, and the best way to debug is to grant the devs access to production machines. It can be temporary, monitored and through a secure channel, but it's still something most organizations can hardly live without.

Post reply on HN