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

41–50 of 120 posts

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

#41

Post by timoteostewart »

lynx23 wrote: post #12
zamadatix wrote: post #4

Earlier quoted context omitted.

For those wondering what this is referring to it's the use of ".int" for the TLD of the examples. ".test" and ".example" are the only really good reserved TLDs for this (".local" isn't quite what people think it is).

I am not sure what you are hinting at with your side comment about .local, but I came here to say that I pretty much love .local. Switched all my home machines to the systemd-resolved stub with enabled mDNS. Feels so much nicer then maintaining your own DNS or hosts files... Yes, there is some initial lookup delay, but thats totally fine for private use methinks.

I switched to using .home.arpa[0] on my local network last year. Looked funny to my eyes at first, but it seems normal to me now.

[0] https://datatracker.ietf.org/doc/html/rfc8375

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

#42

Post by Foxboron »

walth wrote: 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

I've been hacking on `ssh-tpm-agent` which allows you to create or import TPM sealed keys. This is practical as it prevents key extraction and it has dictionary attack protection which allows you to have 4 digit pins instead of passphrases to protect your private keys.

https://github.com/Foxboron/ssh-tpm-agent

Currently hacking up better support for `HostKeyAgent` and `HostKey` for `sshd`.

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

#43

Post by aftbit »

`-g` was new to me. I believe I have done something similar by providing an explicit bind address to -L, like this:

ssh -L 0.0.0.0:2222:10.0.0.1:22 host

I think this will bind to 0.0.0.0:2222 (allowing remote hosts to connect) and forward all traffic to that port to 10.0.0.1:22 (from the server's perspective).

The biggest gap in this collection of tricks (IMO) is SSH certificate support.

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

#44

Post by sophacles »

A lesser known but quite useful bit of ssh is connection multiplexing. Rather than establish a new tcp connection, doing the auth dance, etc, you can tell ssh to reuse an existing connection. (The protocol itself has a notion of channels, a bit of metadata with every data frame to distinguish different streams, and this functionality uses that).

The big thing with it is that you don't have to do a full auth for subsequent sessions - nice if you don't have tmux (etc) on the remote, and do multiple panes via multiple terminal windows. Particularly when auth involves a passphrase and hsm touch or similar that can take several seconds.

It also has a "connection persistence" setting so when you're bouncing around between a handful of servers you don't have to auth each and every time you switch between servers.

Overall I think of it as one of those features that's nice to have, but not really life changing or anything - Some servers I connect to have it turned off and I notice it's absence more than I notice when it's working.

More info: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

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

#45

Post by cholmon »

If you have a lot of hosts listed in your ~/.ssh/config file, you can keep the file from getting too cluttered by using the Include directive, which supports wildcards...

    # in ~/.ssh/config
    Include config.d/*.conf

    # in ~/.ssh/config.d/work.conf
    host work
        hostname myoffice.example.com
        user myuser

    # in ~/.ssh/config.d/client1.conf
    host client1.dev
        hostname dev.client.example.net
        user someuser
    
    host client1.prod
        hostname prod.client.example.net
        user someuser

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

#46

Post by mananaysiempre »

zamadatix wrote: post #4
tedunangst wrote: post #2

Another member of the intergovernmental agency domain squatters club.

For those wondering what this is referring to it's the use of ".int" for the TLD of the examples. ".test" and ".example" are the only really good reserved TLDs for this (".local" isn't quite what people think it is).

> ".local" isn't quite what people think it is

Whereas ".intranet", ".lan", and some others are what (some) people think ".local" is[1].

[1] https://www.rfc-editor.org/rfc/rfc6762#appendix-G

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

#48

Post by zamadatix »

tiffanyh wrote: post #10
zamadatix wrote: post #4

Earlier quoted context omitted.

For those wondering what this is referring to it's the use of ".int" for the TLD of the examples. ".test" and ".example" are the only really good reserved TLDs for this (".local" isn't quite what people think it is).

Example.com People should just use example.com, it’s reserved and the most obvious to the end user that it’s for example purposes. https://en.wikipedia.org/wiki/Example.com

Example.com is certainly acceptable as well but it does have a somewhat negative side effect of being an actual running, pinging, sometimes-service-responding host which means if people paste the documentation verbatim it may either actual execute or take longer than normal to timeout (ssh would fall into the latter). ".example" is reserved for the same purpose but does not have any registered domains, on top of being a few characters shorter for when you need more than 1 name in your documentation.

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

#49

Post by h2odragon »

b112 wrote: post #26
walth wrote: 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!

Physical access only. The server is air-gapped.

And there's a big dog chained to the desk beside it. Biometric security, you see: if you don't smell right to Brutus, you don't get to log on.

Look at our security rituals from an outside view: we sure do seem to spend a lot of time propitiating our idols of one kind or another.

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

#50

Post by zamadatix »

lynx23 wrote: post #12
zamadatix wrote: post #4

Earlier quoted context omitted.

For those wondering what this is referring to it's the use of ".int" for the TLD of the examples. ".test" and ".example" are the only really good reserved TLDs for this (".local" isn't quite what people think it is).

I am not sure what you are hinting at with your side comment about .local, but I came here to say that I pretty much love .local. Switched all my home machines to the systemd-resolved stub with enabled mDNS. Feels so much nicer then maintaining your own DNS or hosts files... Yes, there is some initial lookup delay, but thats totally fine for private use methinks.

mDNS is the right way, the comment was directed towards the common mistake of thinking it's like .lan. or .home.arpa.
Post reply on HN