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

81–90 of 123 posts

Re: SSH: Best practices

#81

Post by hackercomplex »

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

Thank you for this. I suppose I should have included the caveot that my rant applies mostly to early stage shops which are aren't ready to build out and ship a shiny new dev machine for every employee. Another problem for smaller startups is that if you're not careful almost everybody ends up being "blessed". And simply being a senior sysadmin type doesn't mean that you're automatically immune from all forms of social engineering attacks. I suppose your point is that even very early companies should opt for standardized hardware, I think you're right.

I <3 Duo Security.

Re: SSH: Best practices

#82

Post by throwaway2048 »

aris_ada wrote: post #35
rodionos wrote: post #33

Org question. We use a shared key and a shared account to manage our servers. When someone leaves the team we have to regenerate the key for the account. I'm sure it's not recommended, so what's a good way to manage ssh access in a team setting? I'd like avoid sharing the key so that access can be revoked from user without regenerating the key for everyone?

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

Re: SSH: Best practices

#83

Post by EvanPlaice »

shawn-furyan wrote: post #79
jvehent wrote: post #70

Earlier quoted context omitted.

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

I think that this issue is potentially moot if you've transitioned to immutable deploys. Under such a system, arbitrage steps would tend to change from the standard have an SA/Dev ssh in and muck around until the issue is found. Instead, first step may be just redeploying (in case of transient/intermittent issues that are disrupting service), and then checking out the production system locally to do root cause analys…

Exactly. It's also possible to capture stack traces remotely from a running system and/or after a crash. http://techblog.netflix.com/2015/12/debugging-nodejs-in-prod....

Hopefully, this practice -- and the tools required to make it happen -- get better with time.

Re: SSH: Best practices

#84

Post by aris_ada »

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

I wrote the article.

Re: SSH: Best practices

#85

Post by dchest »

hobarrera wrote: post #57
FiloSottile wrote: post #7

Earlier quoted context omitted.

Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model. Saying "they are public so it's ok" is technical oversimplification.

> Saying "they are public so it's ok" is technical oversimplification. It's not. The whole idea of the scheme is that you can publish them everywhere with no risk.

OMG, people! "Public" in "public key" doesn't mean that you should share it with the whole world, it's just because it's an antonym of "private key", meaning that the other party you want to communicate with doesn't need to have a pre-shared secret key with you. Other party may be the whole world, but may be not. How public key is used is up to a protocol and threat model: it may as well be secret, and yes, in some protocols and threat models security can depend on public key being secret, and it's not wrong, and not "security by obscurity".

Re: SSH: Best practices

#86

Post by deathanatos »

infinite8s wrote: post #65
deathanatos wrote: post #40

Earlier quoted context omitted.

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.

The parent is discussing both, and I am too; specifically, the parent says,

> we're not allowed to use key auth.

i.e., they're using password based auth.¹ The point of my post is that while certainly users leaving the private key unencrypted isn't good, trading that for password auth leaves you in a worse state overall (IMO).

¹Of course, they could be using an auth scheme that is neither password nor key based. But given that the parent didn't come out and say that, my gut says that's not the case here.

Re: SSH: Best practices

#87

Post by oleganza »

hobarrera wrote: post #57
FiloSottile wrote: post #7

Earlier quoted context omitted.

Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model. Saying "they are public so it's ok" is technical oversimplification.

> Saying "they are public so it's ok" is technical oversimplification. It's not. The whole idea of the scheme is that you can publish them everywhere with no risk.

In case of Bitcoin pubkeys you don't want to publish them anywhere for privacy reasons (that turn into real physical security reasons once you have enough BTC). Also, notice how pubkeys are normally hidden under hashes and revealed only at spending time. This drastically limits attacks on ECC if/when some weakness in curve math is discovered. And if quantum computer is invented tomorrow, people can safely transition funds to a new signature scheme by introducing 2-phase commitments to safely reveal (now crackable) ECDSA pubkey after another transaction was made with commitment to concrete signature (preventing double-spend attempts using a cracked key).

Re: SSH: Best practices

#88

Post by sapereaude »

Great post!

BTW, you can also now use hardware devices (like TREZOR and KeepKey) to perform "ssh-agent" functionality in hardware, with minimal setup work.

Blog post: https://medium.com/@satoshilabs/trezor-firmware-1-3-4-enable...

Source code: https://github.com/romanz/trezor-agent (the README has several demo screencasts).

Re: SSH: Best practices

#89

Post by cyphar »

thatcks wrote: post #64
cyphar wrote: post #62

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

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

Well that's an ... interesting (read: stupid) design choice. I get that it reduces load on the server, but how many public keys is one user likely to have? Surely you could do something with ring signatures to make it not even require knowing which key was used?

Re: SSH: Best practices

#90

Post by technion »

aris_ada wrote: post #36
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.

Compliance has very little to do with actual security unfortunately...

I've worked with an organisation with the following rules.

A user wants to write an SQL query. The user writes it in notepad or whatever, and saves it in a .sql file. The user then will right click on this file they just created, and hit "Scan with McAfee antivirus". If the .sql file they just created comes up clean, they can then open it in SQL Manager and execute it. If they want to then adjust the query, they have to close the file and start over, running the scan again. People can and have been fired over getting lazy about that process.

There's a security consultant with a clipboard who firmly believes this improves security.

Post reply on HN