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

The OpenSSH Bug That Wasn't

bsdly.blogspot.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: The OpenSSH Bug That Wasn't

#81

Post by hackmiester »

moe wrote: post #78
hackmiester wrote: post #68

Earlier quoted context omitted.

Can you explain this to me? We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.

For accountability the openssh server already logs the key fingerprint. The main security implications of sudo are a false sense of security and the risks related to having a password on your account and typing it in all the time (how often have you spilled it into a bash history?). Sudo can't provide a dependable audit trail because it is trivially circumvented ('sudo bash'). It doesn't protect you from local-to-roo…

Fair enough (wrt accountability).

What is the false sense of security created by sudo? You don't have to have a password on your account to use it. You can use NOPASSWD or you can use pam_ssh_agent_auth to verify ssh keys if you are very paranoid. (Users still should not log into the servers with passwords.)

sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just fix the logs? To fix this, you must use snoopy to log commands to syslog, then syslog to a different computer. This makes both 'sudo' and root's ssh keys as accountable as one could ask for, I think. (As I could ask for, anyway.)

It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo." If you are running as your own user, it's much harder for a stray 'rm' to bring down the system. You might clobber your own files, but then you just restore from your backup.

Re: The OpenSSH Bug That Wasn't

#82

Post by cbsmith »

hackmiester wrote: post #77
cbsmith wrote: post #76

Earlier quoted context omitted.

From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability. I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.

I don't find 'sudo' to be complex at all. If in your situation I would have had the ability to log in as root, in my situation I will be in the 'wheel' group. It seems very straightforward to me.

I think you misunderstand my point. You have increased the complexity of securing the system. You now have each user's login shells, all of the joys of what those login shells touch, the sudo program and its configuration, all added to the attack surface.

Re: The OpenSSH Bug That Wasn't

#83

Post by cbsmith »

scintill76 wrote: post #65
cbsmith wrote: post #64

Earlier quoted context omitted.

Yeah, I'm not seeing the point of doing that. You might as well create the key, encrypt it with the passphrase as per usual, and then post it online for all to see. It's effectively the same thing as generating the key from the pass phrase, except you are mixing in a nice giant product of two primes in to the mix.

Well, I don't know a lot of the math and crypto, but I would probably seed an RNG from the stretched key and then pull large primes out just as ssh-keygen would. You're right, though -- given my "requirements", it's not much more to assume a convenient place to store a normal, encrypted key. It can be public since I already based my security on the password strength and some obscurity. I wouldn't use either of these…

Hmm... how about I reframe my point this way...

Let's say you have this deterministic SSH key generator. However, instead of your approach to using it, you took the resulting key and XOR'd it with a passphraseless private key, and then posted the XOR'd file up to the internet for all to see.

Now imagine what it would take for someone to crack it. They'd basically have to figure out what your deterministic key was. The publicly available file really wouldn't be of any help in that unless they already knew the underlying passphraseless key they were trying to hack.

Now explain to me how the "deterministic key + XOR" is in any way making it more difficult to crack it than just using "ssh -o -a [some reasonably high number]".

It's not. If anything, it is less. The deterministic key generator is essentially how most streaming ciphers designs work (well, aside from those derived from block ciphers), and generally offers weaker protections than block encryption.

So, rather than go through all that pain, just block encrypt your private key well and upload it to the cloud. ;-)

Re: The OpenSSH Bug That Wasn't

#84

Post by semi-extrinsic »

ori_b wrote: post #56
semi-extrinsic wrote: post #49

Earlier quoted context omitted.

Use a stepstone. This is really only feasible if you can get a user account some place where they take network security seriously. (A stepstone is a well-protected server where you can log in with user/pass and use your keys to login to other machines from there.)

Doesn't that have all the problems of password auth, but with one extra step, with it's own failure modes, in between?

I don't think so. A single server sitting behind an advanced firewall/IDS/IPS system and managed by competent IT staff is a much harder target than a multitude of servers I manage myself.

Also note that it's not really an extra step, you put in a ProxyCommand in your .ssh/config file.

Re: The OpenSSH Bug That Wasn't

#85

Post by chei0aiV »

heywire wrote: post #10
geerlingguy wrote: post #2

Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most p…

I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.

Don't connect to your servers from machines you don't/shouldn't trust.

Re: The OpenSSH Bug That Wasn't

#86

Post by steckerbrett »

cbsmith wrote: post #62
steckerbrett wrote: post #31

Earlier quoted context omitted.

If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.

If your threat model is someone stealing and cracking your private key, you really ought to be more worried that they are going to use their time machine to go back in time and kill your mother.

Both actions happen at the same time, someone phishes you, captures your input and they have the password for it as well. Now that they've got a shell on your box IP address restrictions are bypassed as well, as is port knocking. This is completely plausible, time machines are not. I read a (private) incident report very recently where half a company had their devices spear phished in order to gain access to a single internal server.

Re: The OpenSSH Bug That Wasn't

#87

Post by cbsmith »

steckerbrett wrote: post #86
cbsmith wrote: post #62

Earlier quoted context omitted.

If your threat model is someone stealing and cracking your private key, you really ought to be more worried that they are going to use their time machine to go back in time and kill your mother.

Both actions happen at the same time, someone phishes you, captures your input and they have the password for it as well. Now that they've got a shell on your box IP address restrictions are bypassed as well, as is port knocking. This is completely plausible, time machines are not. I read a (private) incident report very recently where half a company had their devices spear phished in order to gain access to a single…

Oh, someone capturing your private key's passphrase is something to be genuinely worried about.

Someone brute forcing said passphrase? Yeah no.

Re: The OpenSSH Bug That Wasn't

#89

Post by moe »

hackmiester wrote: post #81
moe wrote: post #78

Earlier quoted context omitted.

For accountability the openssh server already logs the key fingerprint. The main security implications of sudo are a false sense of security and the risks related to having a password on your account and typing it in all the time (how often have you spilled it into a bash history?). Sudo can't provide a dependable audit trail because it is trivially circumvented ('sudo bash'). It doesn't protect you from local-to-roo…

Fair enough (wrt accountability). What is the false sense of security created by sudo? You don't have to have a password on your account to use it. You can use NOPASSWD or you can use pam_ssh_agent_auth to verify ssh keys if you are very paranoid. (Users still should not log into the servers with passwords.) sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just f…

What is the false sense of security created by sudo? You don't have to have a password on your account to use it.

You seem to think sudo adds security even when you don't use a sudo password. That's precisely the false sense it creates.

snoopy

On vanilla Linux there is no dependable audit trail after someone becomes root, period.

that you are meant to think about what you type if it begins with "sudo."

Because you don't think when you type into a root shell?

The mythical "stray rm" is a strawman. I've never heard of one happening in the real world. If you're that careless then sudo won't save you either.

What I do see often is people spending minutes on trial & error because sudo turns even trivial commands into a minefield when a pipe/redirect, the shell environment, globbing or a loop gets involved.

Re: The OpenSSH Bug That Wasn't

#90

Post by cbsmith »

hackmiester wrote: post #81
moe wrote: post #78

Earlier quoted context omitted.

For accountability the openssh server already logs the key fingerprint. The main security implications of sudo are a false sense of security and the risks related to having a password on your account and typing it in all the time (how often have you spilled it into a bash history?). Sudo can't provide a dependable audit trail because it is trivially circumvented ('sudo bash'). It doesn't protect you from local-to-roo…

Fair enough (wrt accountability). What is the false sense of security created by sudo? You don't have to have a password on your account to use it. You can use NOPASSWD or you can use pam_ssh_agent_auth to verify ssh keys if you are very paranoid. (Users still should not log into the servers with passwords.) sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just f…

> sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just fix the logs? To fix this, you must use snoopy to log commands to syslog, then syslog to a different computer.

Wait, you just said "neither does anything else", and then gave an example of how to create an audit trail. ;-)

In truth, you should use auditd or similar systems to really have a proper audit trail.

You're absolutely right that sudo doesn't make an audit trail more worse. It just doesn't make it any better either. It does, however, create a bunch more ways that someone can hack your system.

> It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo."

How about you write a shell script on your own system, call it "sudo", and have it do "ssh root@admin.system $*"? You see what I mean? Maybe you are used to using sudo, but there is no reason the "oh noes, now I need to be careful mode" has to be a privilege escalation command on the host your are administrating. In fact, it shouldn't be. It really should be before you have logged in.

Post reply on HN