Live data from Hacker News

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

grahamhelton.com

31–40 of 120 posts

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

#31
post #26
post #19

I'd add to this list that in 2023 you should be securely storing your key in a HSM. On Mac, that's easy to do via the Secure Enclave: https://github.com/maxgoedjen/secretive

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.

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

#32
There's a current pull request for adding AF_UNIX support, which should make all kinds of exciting forwarding possible, since it will make it easy to proxy ssh connections through an arbitrary local process which can do anything to forward the data to the remote end.

https://github.com/openssh/openssh-portable/pull/431

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

#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 user is part of your org and in a certain group on Github. Then, if the user exists (and is rewritten via nss-ato or something), they can login to the server.

This saves a lot of trouble when off/on-boarding folks, since you can simply add/remove them from a github group to revoke or grant access to your machines.

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

#34

Great article that collected a lot of info that I usually wind up looking for separately. But I have to ask: do people really find color schemes like this easier to read? I'm squinting at it throughout.

> do people really find color schemes like this easier to read

I simply turned off style sheets in Firefox (Alt+V Y M [View menu->Page Style->No Style]) to get rid of the website color scheme and have it render using the colors I have set as default in Firefox.

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

#35
post #25
post #20

Earlier quoted context omitted.

It does work when you use subdomains. And there’s also example.org and example.net.

> It does work when you use subdomains. That's true but most people don't understand what subdomains are, so we're back to being (more) difficult for laypersons. > And there’s also example.org and example.net Well, that's a good point. There are options.

I think in the context of SSH, use of subdomains is very common and to be expected.

As far as laypersons are concerned, I would worry that they wouldn’t recognize foo.example to be a domain name, as opposed to www.example.com or blog.example.com.

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

#36
post #35
post #25

Earlier quoted context omitted.

> It does work when you use subdomains. That's true but most people don't understand what subdomains are, so we're back to being (more) difficult for laypersons. > And there’s also example.org and example.net Well, that's a good point. There are options.

I think in the context of SSH, use of subdomains is very common and to be expected. As far as laypersons are concerned, I would worry that they wouldn’t recognize foo.example to be a domain name, as opposed to www.example.com or blog.example.com.

I forgot we were talking about SSH :)

But in your example, you're comparing different structures. "www.foo.example" is somewhat more clear.

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

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

[deleted]

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

#39
post #36
post #35

Earlier quoted context omitted.

I think in the context of SSH, use of subdomains is very common and to be expected. As far as laypersons are concerned, I would worry that they wouldn’t recognize foo.example to be a domain name, as opposed to www.example.com or blog.example.com.

I forgot we were talking about SSH :) But in your example, you're comparing different structures. "www.foo.example" is somewhat more clear.

Well, it was you who didn’t want to use subdomains. And with subdomains, we can just stick with sub.example.com/net/org.

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

#40
The remote port forwarding example seems wrong. It's specifying the loopback address which would be pointing to vuln-server (where we are connecting via SSH) and not internal-web, right? How is vuln-server accessing the site hosted on the loopback of internal-web?

Edit: Okay now I see that command is supposed to be run from internal-web and not campfire. I guess you would also have to ProxyJump through vuln-server to internal-web to even run that command!

Post reply on HN