Live data from Hacker News

SSH: Best practices

blog.0xbadc0de.be

31–40 of 123 posts

Re: SSH: Best practices

#31

The article didn't make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging. All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will drop a key on your machine, fire up…

> All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will...

...install a rootkit or botnet client regardless of how you've configured ssh.

What does it have anything to do with ssh at all? The attacker could just as easily set up an outgoing VPN-over-TLS in the same way.

Re: SSH: Best practices

#32

Earlier quoted context omitted.

You run untrusted code whenever your browser loads a web page that uses javascript. With more and more of the web requiring javascript to work, running untrusted code becomes less and less a real option if you want to get any work done. Arguably, plain HTML is also untrusted code, and I certainly don't trust every single one of the authors of my operating system and all of the os-level utilities and all the applicati…

> They said something like, "um... but we've got root". Which is incredibly misleading. Sure, they could put malicious code in their distribution. It could do whatever they want. And then it would be on your machine, where you can potentially discover it and publish what you've discovered and allow others to verify your discovery. Which could cause Canonical to not have root anymore, because people would immediately…

How many Ubuntu users actually verify everything Canonical sends them? I'd say very close to none, especially for the binaries.

Sure, in principle you could verify. You could read through all the source, you could even disassemble the binaries and read through the assembly (and don't forget to verify the hardware too). Again, who actually does that? Virtually no one.

So the two cases are a lot closer than you paint them to be.

Also, corporations do stupid, illegal, and unethical stuff all the time, even when it's clearly (especially in hindsight) not in their long-term interest to do so. Even when it will clearly destroy their reputation if the public found out they even considered it.

Even if you trust "the system" (which is more of a hope that if there's something malicious, someone out there will detect it sooner or later), there are many cases of vulnerabilities in even open source code going undetected for years... nevermind vulnerabilities in binaries that you don't have code for and who the authors of aren't generous enough to clue you in on.

Canonical (or whatever source you actually get your OS or apps from) could also send you some specially crafted something that no one else gets. Now who's going to verify it for you if you don't do it yourself? How are you ever going to find out, if you're not one of the ultra-paranoid and super-skilled 0.001% of Ubuntu users with infinite time and determination who actually verifies 100% of what Canonical sends them? You just won't. And if you did, there'd be a hundred new Ubuntu versions out by the time you finished verifying even one of them.

People trust, but they very rarely verify. The size of operating systems and applications and the skill to verify have all just grown too large to make it practical for the overwhelming majority of people.

I do see your point about Canonical doing whatever they want with the data they collect. That's certainly problematic. But that doesn't mean that there aren't major privacy or security issues with trusting Ubuntu (or any other OS) not to have malware on it.

Re: SSH: Best practices

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

Re: SSH: Best practices

#34

Earlier quoted context omitted.

Something you have plus 2 things you know does not turn 2FA into 3FA. It's still 2FA - it's just somethings you know instead of something you know. 3 FA is : * Something you have (normally one OR MORE user IDs) * Something you know (normally the associated password or passwords for the user ID(s)) * Something you are (normally biometric) [edit: technically, it's multi-factor when using multiple user/passwords - here'…

I look at biometrics as just another category of of the 2nd factor: things you have. You have your fingers. You have your eyes. In fiction and movies, these things that you have which could be taken from you (your fingers severed, your eyes plucked out) and used for getting past biometric scanners. In real life there are easier, stealthier, and less gruesome methods for getting those things: just copy them. (gummy be…

Unfortunately biometrics are near to useless for remote authentication. The only context in which biometrics work is when the whole authentication chain (reader, cable, computer, network) is tamper-proof. When one of these elements can be tampered with (e.g. unplugging the fingerprint reader and sniffing to the USB traffic), it becomes "something you know, that anyone can collect, that you can reproduce with an HD picture, and that you cannot revoke without losing your physical integrity".

I think biometrics may have a place in tamper-proof devices like iphones (infamous error 53) or biometric smartcards (need fingerprint to unlock secrets).

Re: SSH: Best practices

#35

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.

Re: SSH: Best practices

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

Re: SSH: Best practices

#37

How about https://github.com/ccontavalli/ssh-ident ? Is that still a "best practice", since the author doesn't mention it in this blog entry?

I didn't know that tool. Having different agents for different projects may be useful, especially if you're using Agent Forwarding.

I don't like that you have to alias ssh or replace /usr/xxx/bin/ssh with a symlink to make it work.

Re: SSH: Best practices

#38

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?

We have a shared account to manage servers as well. However, the individuals still have individual accounts, and individual SSH keys. They log in as themselves, and `sudo -iu` into the shared user. This can be done without giving the user root (i.e., sudo supports only giving access to the shared account).

It's still not a great setup, because it makes auditing a nightmare. (Unfortunately, a particular software package we use essentially requires it due to its bad architecture.)

Re: SSH: Best practices

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

Ironically, things done for PCI/ISO27K compliance very often decrease security. Maybe not always, maybe not everywhere, but at least that's my experience with the companies I worked at and is also in line with the stories I heard about other companies.

Quite recently: Security was concerned about enforcing ssh key rotation and was pushing for sysops to generate and store (obviously - unencrypted) private keys for all users on a central jump host and provide users access to that host using passwords (for which enforcing lifecycle policies is easier).

Re: SSH: Best practices

#40
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 compromising the machine; the latter I can just take pot-shots at the server with. (They do rate limit your SSH password attempts, right? right?)

Even if we assume that the password is good, and that the server won't allow infinite tries to guess it, the security is only equivalent: compromise of the user's local account will reveal the password (just sniff the password) or the key (just read the keyfile, and sniff the password if it is encrypted). I don't see any world in which a password is more secure than a key.

Post reply on HN