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

An excruciatingly detailed guide to SSH (but only the things I find useful)

grahamhelton.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#111

Post by lynx23 »

fanf2 wrote: post #77
knome wrote: post #13

Earlier quoted context omitted.

>I am not sure what you are hinting at with your side comment about .local They are probably referring to its special status and special handling. https://en.wikipedia.org/wiki/.local >The Internet Engineering Task Force (IETF) reserves the use of the domain name label .local as a special-use domain name for hostnames in local area networks that can be resolved via the Multicast DNS name resolution protocol.[2] Any D…

Sadly it’s more complicated than that. Back in the 1990s, Microsoft distributed a Netware-killer version of NT called Windows Small Business Server. It was aimed at companies that might at best have a dial-up internet service. SBS, being based on Active Directory and Exchange (etc usw) required a domain name, but back then you needed considerable arcane knowledge to register an Internet domain name, which most SBS us…

I know at least one case of a Microsoft Consultant who suggested to use company.local for a new Exchange setup for roughly 5k employees. Unfortunately, his suggestion was actually implemented.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#112

Post by fmajid »

withinboredom wrote: post #33

There is an amazingly simple directive missing here: # in sshd_config: AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u # in /etc/ssh/auth.php $user = $argv[1] ?? ''; $user = rawurlencode($user); echo file_get_contents("https://gihub.com/{$user}.keys"); This is obviously not production quality code, but just demonstrates the gist of the configuration. Basically, you can do a number of things, like verify the u…

You really should use ssh certificates for this instead.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#113

Post by account42 »

pxc wrote: post #85
wahern wrote: post #67

Here's something I bet few people know: the OpenSSH configuration parser ignores duplicate directives; only the first such directive has any effect. This is more than a little counter intuitive as IME the more common semantic in configuration parsers and rules engines is for subsequent directives to take precedence over previous ones. This may seem inconsequential, but IME when changing defaults in, e.g., /etc/ssh/ss…

> Here's something I bet few people know: the OpenSSH configuration parser ignores duplicate directives; only the first such directive has any effect. This is more than a little counter intuitive This is how the sudoers file works as well. I think this is desirable in software that authenticates or authorizes users, and maybe more broadly wherever security concerns are essential. That's because this logic makes it ea…

> This is how the sudoers file works as well. I think this is desirable in software that authenticates or authorizes users, and maybe more broadly wherever security concerns are essential.

I strongly disagree - the most important trait for security-relevant configuration is that it works like you'd expect.

> That's because this logic makes it easy to create settings that can't be overridden in by adding a new file in a whatever.conf.d directory: you define those settings in the main config file before you source whatever.conf.d/* and you put some kind of special protections on that file.

What is gained by this? The administrator controls both of these locations.

> Even where you're not worried about somebody evading your controls per se, it can be nice from a configuration management perspective in giving you a soft 'guarantee' that if some new hire who doesn't have the whole picture adds a new file in there, or some package tries to install a stupid default for its own service, your baseline settings can retain priority.

Instead the new hire or a package adds important settings that now have no effect. In either case you need to review the whole configuration - reversing the order of precedence doesn't do anyting except confuse users.

If you want to have a configuration file that has the final say then make that explicit - and that absolutely doesn't require the order inside that file to be reversed. If the subdirectory is explicitly included in the main config then you can add your overrides after that include anyway.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#114

Post by withinboredom »

fmajid wrote: post #112
withinboredom wrote: post #33

There is an amazingly simple directive missing here: # in sshd_config: AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u # in /etc/ssh/auth.php $user = $argv[1] ?? ''; $user = rawurlencode($user); echo file_get_contents("https://gihub.com/{$user}.keys"); This is obviously not production quality code, but just demonstrates the gist of the configuration. Basically, you can do a number of things, like verify the u…

You really should use ssh certificates for this instead.

Yeah, if you have PKI infra, that’s the way to go.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#115

Post by pxc »

account42 wrote: post #113
pxc wrote: post #85

Earlier quoted context omitted.

> Here's something I bet few people know: the OpenSSH configuration parser ignores duplicate directives; only the first such directive has any effect. This is more than a little counter intuitive This is how the sudoers file works as well. I think this is desirable in software that authenticates or authorizes users, and maybe more broadly wherever security concerns are essential. That's because this logic makes it ea…

> This is how the sudoers file works as well. I think this is desirable in software that authenticates or authorizes users, and maybe more broadly wherever security concerns are essential. I strongly disagree - the most important trait for security-relevant configuration is that it works like you'd expect. > That's because this logic makes it easy to create settings that can't be overridden in by adding a new file in…

I gave my best effort at a rationalization for what we see in OpenSSH, but in light of some of my misremembered peripheral details and your arguments here, I've changed my mind.

Sometimes you do want to set a baseline, and other times you do want to set a default. But using an unconventional ordering for overrides in your config file format isn't the right way to do anything.

Thanks for laying this out.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#116

Post by wahern »

pxc wrote: post #115
account42 wrote: post #113

Earlier quoted context omitted.

> This is how the sudoers file works as well. I think this is desirable in software that authenticates or authorizes users, and maybe more broadly wherever security concerns are essential. I strongly disagree - the most important trait for security-relevant configuration is that it works like you'd expect. > That's because this logic makes it easy to create settings that can't be overridden in by adding a new file in…

I gave my best effort at a rationalization for what we see in OpenSSH, but in light of some of my misremembered peripheral details and your arguments here, I've changed my mind. Sometimes you do want to set a baseline, and other times you do want to set a default. But using an unconventional ordering for overrides in your config file format isn't the right way to do anything. Thanks for laying this out.

I suspect OpenSSH's precedence order might be a consequence of the semantics and syntax of the Host and Match directives. But I haven't looked into the history.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#117

Post by detuur »

e12e wrote: post #102
detuur wrote: post #58

Some years ago, I read a post on HN where someone made a text-mode game(? or something similar?) available through SSH. People could play the game by opening an SSH session and play from their terminals. This was non-trivial, and they explained all the ways they configured sshd to prevent players from running binaries other than the game. I didn't bookmark that post, and I haven't been able to find it again to my gre…

> they configured sshd to prevent players from running binaries other than the game You might be interested in how to limit users to nologin shell coupled with subsystem access: https://news.ycombinator.com/item?id=3527754

None of the links here seem to be the one post that I found years ago, but this one in particular is pretty interesting.

I found this[1] one while looking around, the thread has some additional interesting remarks, including an LD_PRELOAD attack vector.

[1]: https://news.ycombinator.com/item?id=3550944

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#118

Post by touisteur »

touisteur wrote: post #31
b112 wrote: post #26

Earlier quoted context omitted.

It's never enough for you walth, is it? I used to use an easily memorizable password, but you said that was wrong, and set me straight. Now my password is so complex, I have to rely upon a 3rd party service, that keeps getting hacked. Then you insisted I use keys. After, you became irate if I left the keys on my work dir. Now you want me to lug around a 2U HSM appliance?! For shame!

Can't / shouldn't lug 'em around, some of these boxens have shock, temperature, movement failsafes. Anti tampering you see.

See today's HN link for an example https://tches.iacr.org/index.php/TCHES/article/view/9290/885...

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#119

Post by sureglymop »

semi wrote: post #103
sureglymop wrote: post #53

One thing I would find interesting would be how to read someones private key or agent from ram. For example, when ssh agent forwarding to a machine, the root could extract that agent probably.

I don't believe a remote host that has access to your forwarded agent can extract the keys( ). But they can tell the agent to authenticate with any key loaded in your agent, not just the one you used to ssh into the machine you forwarded your agent to So e.g if you have a distinct ssh key for GitHub and a different one for all other uses and you ssh to a compromised server with agent forwarding, the attacker can then…

So if I have access to the agent and can authenticate with it at another remote location, then if I control that remote location I should be able to grab the key at _some point_ during this process. I may have to implement my own ssh server to do so but it should theoretically be possible, no?

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#120

Post by semi »

sureglymop wrote: post #119
semi wrote: post #103

Earlier quoted context omitted.

I don't believe a remote host that has access to your forwarded agent can extract the keys( ). But they can tell the agent to authenticate with any key loaded in your agent, not just the one you used to ssh into the machine you forwarded your agent to So e.g if you have a distinct ssh key for GitHub and a different one for all other uses and you ssh to a compromised server with agent forwarding, the attacker can then…

So if I have access to the agent and can authenticate with it at another remote location, then if I control that remote location I should be able to grab the key at _some point_ during this process. I may have to implement my own ssh server to do so but it should theoretically be possible, no?

Not as far as I'm aware, at least not without some really clever attack. The design is such that all you're doing is asking the remote agent to use it's private key to sign things, it never actually exposes the private key. Your agent doesn't even always have access to your private key- it could be on a TPM or Yubikey where the key never leaves the device. you are just passing around a connection to your agent that is able to authenticate with a private key.

I would not be surprised if there is some way to attack this into getting a private key, but it would either be a direct attack on the agent code like sending it malformed messages to somehow get remote code execution to then read the key. Or some more complicated attack on the cryptography where you repeatedly force it to auth and can somehow use the results to reduce the key space needed to brute force the key - along the lines of a known plaintext attack.

But I'm also just a hobbiest here who has looked a little into the security model but I am by no means a cryptography expert, so take all of this with a grain of salt.

Post reply on HN