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

51–60 of 123 posts

Re: SSH: Best practices

#51

Post by [deleted] »

AnthonyMouse wrote: post #50
LinuxBender wrote: post #49

Earlier quoted context omitted.

Keylogger, perhaps. The multiplexing just makes it trivial to connect to everything with no logging and no authentication. I don't even have to modify the PATH or install a keylogger. I am already several steps beyond that in one move. In other words, no audit trail for the FBI to look into, no need to upload some new application, no need to exploit a vulnerable application (beyond the vulnerability of OpenSSH itself…

If this were a game of chess, checkmate is getting arbitrary code to run in the context of the user. If you have an existing ssh process running as the same user then you can attach it with a debugger and inject code into it.

[deleted]

Re: SSH: Best practices

#52

Post by AnthonyMouse »

[deleted] wrote: post #51
AnthonyMouse wrote: post #50

Earlier quoted context omitted.

If this were a game of chess, checkmate is getting arbitrary code to run in the context of the user. If you have an existing ssh process running as the same user then you can attach it with a debugger and inject code into it.

[deleted]

A debugger injecting code into a process under the same context isn't a vulnerability. It's supposed to be able to do that. And OpenSSH is supposed to allow you to multiplex sessions. It's a feature.

The vulnerability is the attacker being able to run arbitrary code as the user.

Re: SSH: Best practices

#53

Post by [deleted] »

AnthonyMouse wrote: post #52
[deleted] wrote: post #51

Earlier quoted context omitted.

[deleted]

A debugger injecting code into a process under the same context isn't a vulnerability. It's supposed to be able to do that. And OpenSSH is supposed to allow you to multiplex sessions. It's a feature. The vulnerability is the attacker being able to run arbitrary code as the user.

[deleted]

Re: SSH: Best practices

#54

Post by LinuxBender »

AnthonyMouse wrote: post #52
[deleted] wrote: post #51

Earlier quoted context omitted.

[deleted]

A debugger injecting code into a process under the same context isn't a vulnerability. It's supposed to be able to do that. And OpenSSH is supposed to allow you to multiplex sessions. It's a feature. The vulnerability is the attacker being able to run arbitrary code as the user.

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

Re: SSH: Best practices

#55

Post by LinuxBender »

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.

They are correct. You can't enforce passphrases (at all) on ssh keys, nor can you enforce key rotation unless you have a system that issues both the public and private keys. Even then, the user can simply re-sign the key and remove the passphrase. SSH Keys used correctly can be more secure than 2FA, but I have yet to see anyone actually use them correctly. If you are honest with yourself, you know that most of the folks in your org don't have passphrases on their SSH keys. It is easy enough to test if you have something managing their laptops.

Re: SSH: Best practices

#56

Post by LinuxBender »

skarap wrote: post #39
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.

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…

I agree with that. Folks are forced to create little isolated environments that are less likely to be patched or monitored, for fear of bringing more systems into PCI scope.

That is slowly starting to change however. PCI DSS 3.0 gets a bit more specific and starts to go down some technical rabbit holes. PCI DSS 4.0 will be even more specific and have more technical requirements (vs. checkboxes)

Re: SSH: Best practices

#57

Post by hobarrera »

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

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.

Re: SSH: Best practices

#58

Post by hobarrera »

noondip wrote: post #12

Here's a brief guide for setting up SSH with YubiKey as a smartcard which complements this article nicely - https://github.com/drduh/YubiKey-Guide

Looks like I'd need to configure gpg to use it locally first.

One of the main uses of smartcards is to use it on other machines (eg: not mine). What's the added benefit of adding one if I'm logging in from my local machine?

Re: SSH: Best practices

#60

Post by AnthonyMouse »

LinuxBender wrote: post #54
AnthonyMouse wrote: post #52

Earlier quoted context omitted.

A debugger injecting code into a process under the same context isn't a vulnerability. It's supposed to be able to do that. And OpenSSH is supposed to allow you to multiplex sessions. It's a feature. The vulnerability is the attacker being able to run arbitrary code as the user.

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?
Post reply on HN