[HN Gopher] An excruciatingly detailed guide to SSH (but only th...
       ___________________________________________________________________
        
       An excruciatingly detailed guide to SSH (but only the things I find
       useful)
        
       Author : weeha
       Score  : 282 points
       Date   : 2023-08-23 18:27 UTC (4 hours ago)
        
 (HTM) web link (grahamhelton.com)
 (TXT) w3m dump (grahamhelton.com)
        
       | pram wrote:
       | The SSH console blew my mind when I first saw it. A coworker
       | showed me ~# and it felt like discovering some kind of secret
       | cheat menu you'd see in a SEGA Genesis game.
        
       | aftbit wrote:
       | `-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.
        
       | josephcsible wrote:
       | One more useful trick I'm surprised wasn't mentioned since -D and
       | -R both were: if you do "ssh -R 8080 somehost", that does dynamic
       | port forwarding just like -D, but on the remote end instead of
       | the local end.
        
       | sophacles wrote:
       | 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
        
       | cholmon wrote:
       | 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
        
         | sureglymop wrote:
         | The host directive also supports wildcards.
         | 
         | For example, add `host *_work ` and then some stiff that is the
         | same for all work hosts like host1_work.
        
       | c0l0 wrote:
       | Maybe (hopefully :)) also interesting for those who enjoyed this
       | article:
       | https://johannes.truschnigg.info/writing/2022-07_advanced_ss...
        
       | [deleted]
        
       | TheRealPomax wrote:
       | I can't read this unless I hack up the CSS to not be dark text
       | using a thin typeface on a black background. I could edit the CSS
       | so that it's normal fonts with higher contrast colors, but
       | instead I think I'll go "someone made something on the internet
       | and I'm not the audience, good for them, but I'm closing this tab
       | again."
        
       | tedunangst wrote:
       | Another member of the intergovernmental agency domain squatters
       | club.
        
         | zamadatix wrote:
         | 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).
        
           | mananaysiempre wrote:
           | > ".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
        
           | tiffanyh wrote:
           | 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
        
             | zamadatix wrote:
             | 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.
        
             | digging wrote:
             | Doesn't work if you need to refer to more than one domain.
             | 
             | .example is also reserved for this exact purpose.
        
               | layer8 wrote:
               | It does work when you use subdomains. And there's also
               | example.org and example.net.
        
               | digging wrote:
               | > 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.
        
               | layer8 wrote:
               | 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.
        
               | digging wrote:
               | I forgot we were talking about SSH :)
               | 
               | But in your example, you're comparing different
               | structures. "www.foo.example" is somewhat more clear.
        
               | layer8 wrote:
               | Well, it was you who didn't want to use subdomains. And
               | with subdomains, we can just stick with
               | sub.example.com/net/org.
        
           | lynx23 wrote:
           | 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.
        
             | knome wrote:
             | >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 DNS query for a name ending with the label local must
             | be sent to the mDNS IPv4 link-local multicast address
             | 224.0.0.251, or its IPv6 equivalent ff02::fb. A domain name
             | ending in .local may be resolved concurrently via other
             | mechanisms, for example, unicast DNS
        
             | zamadatix wrote:
             | mDNS is the right way, the comment was directed towards the
             | common mistake of thinking it's like .lan. or .home.arpa.
        
             | em-bee wrote:
             | one thing i haven't been able to figure out with .local is
             | that with multiple connections (wire to the lan, wifi to
             | the internet, and vpn to the office network), the computer
             | seemingly picks one of them at random for its .local
             | address. i don't know how to fix that without setting each
             | of them manually.
        
             | timoteostewart wrote:
             | 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
        
       | ScottEvtuch wrote:
       | 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!
        
       | rwmj wrote:
       | 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
        
       | zamadatix wrote:
       | For forwarding I almost never do -f. It can be a footgun in
       | making it hard to tell which forwards are still open or
       | operational.
       | 
       | -t is a cool trick, didn't know about that one.
       | 
       | An important note that's easy to overlook in the ~ escape command
       | list is you can nest the escape when in nested sessions (i.e. if
       | you're not using -J for whatever reason).
       | 
       | Cool list, it definitely lines up with what I've found useful and
       | had a few more.
        
         | progbits wrote:
         | -t is great, I use
         | 
         | $ ssh -t my-dev-vps 'tmux new-session -A -s main'
         | 
         | So each time I run it I'm right back where I left off.
        
         | ilyt wrote:
         | > For forwarding I almost never do -f. It can be a footgun in
         | making it hard to tell which forwards are still open or
         | operational.
         | 
         | That kinda still is a problem when you have multiple shells
         | open to the target server. I wish SSH exported it in any
         | reasonable way aside from trying to get it myself from the
         | process list...
        
       | withinboredom wrote:
       | 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.
        
         | uses wrote:
         | little typo there: "gihub"
        
           | withinboredom wrote:
           | Nice catch! Too late to edit it though.
        
       | walth wrote:
       | 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
        
         | bbarnett wrote:
         | 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!
        
           | h2odragon wrote:
           | 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.
        
           | [deleted]
        
           | touisteur wrote:
           | Can't / shouldn't lug 'em around, some of these boxens have
           | shock, temperature, movement failsafes. Anti tampering you
           | see.
        
             | [deleted]
        
         | aidos wrote:
         | For people using 1Password you can get it to act as an agent to
         | lookup keys directly in your vaults. Again, great integration
         | on a Mac where you can use your fingerprint each time the key
         | is required.
        
         | Foxboron wrote:
         | 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`.
        
       | sevenseventen wrote:
       | 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.
        
         | emptyfile wrote:
         | [dead]
        
         | [deleted]
        
         | h2odragon wrote:
         | > do people really find color schemes like this easier to read
         | 
         | That scheme works great for me. Not just "dark mode," if it
         | were my site i'd have made the colors more neon-ish.
        
           | torh wrote:
           | I find the color and the font hard to read... Guess we are
           | all different.
        
         | king_geedorah wrote:
         | Do you mean the color scheme of the web page itself or the
         | color scheme of the terminal in the screen captures? They're
         | pretty close so maybe the distinction doesn't matter. The
         | former seems more legible than most pages I see posted here
         | since most of them have poor contrast. The latter is
         | approximately what I use in my own terminal, except my text
         | color is closer to that of the text editor screen capture than
         | any of the shell ones for the same reason of contrast. I've
         | pretty poor eyesight in general though so perhaps there's
         | something to that.
        
         | onetom wrote:
         | I grew up on green CGA, goldenrod Hercules monitors and
         | grayscale mono VGA ones.
         | 
         | Indeed, for the past decade I also prefer the light themes,
         | though I find these dark themes pretty usable too:
         | https://protesilaos.com/emacs/modus-themes-pictures
         | 
         | As I've noticed, the main problem with dark themes is the low
         | contrast usually. These modus themes were designed
         | scientifically, to meet the contrast ratios recommended by the
         | Web Content Accessibility Guidelines.
         | 
         | Also, back in those days mono-monitor days, people just kept
         | the brightness at the same level they used during the day and
         | complained how tiring is it for their eyes to "use the computer
         | for so many hours".
         | 
         | My eyes never got tired, because I was constantly adjusting the
         | brightness to match the ambient lighting and I've drastically
         | lowered it, when I was coding in dark.
         | 
         | I've noticed that dark-theme users (eg during live streaming)
         | crank up their brightness/contrast to compensate for the low-
         | contrast dark themes, then they are surprised to be blinded
         | when they open a webpage, which is extremely likely to be light
         | themed and they keep complaining about light themes...
        
         | pwg wrote:
         | > 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.
        
         | deepspace wrote:
         | > I'm squinting at it throughout
         | 
         | Same here. I have anecdotally noted that many people, like
         | myself, who were around in the days of actual green screen
         | terminals and later green monochrome monitors are far less
         | likely to prefer dark mode than younger people.
         | 
         | For me, the advent of color screens that made black-on-white
         | text possible was a huge improvement in terms of readability
         | and eye strain reduction, and I cannot imagine going back to
         | the old ways.
        
           | SL61 wrote:
           | As a younger person who strongly prefers black text on white
           | backgrounds, I talked to some of my friends who use dark mode
           | and discovered that they almost exclusively use their screens
           | in dark rooms. Scrolling through their phone in bed with the
           | lights off, for example. And younger PC gamers typically
           | leave their room light off when they're on their computer.
           | 
           | The constant "light mode hurts my eyes!" never made sense to
           | me until I tried using my computer in a completely dark room.
           | So I think the trend over the past decade isn't really dark
           | mode itself, it's more people using screens in dark rooms.
        
             | tetha wrote:
             | I am a data point towards this. I use dark color themes in
             | my living room, and light-ish color themes on the balcony.
        
           | salawat wrote:
           | Was around in the tail end of the glory days of monochrome
           | green/amber terminal. Still love me some dark mode. I'll
           | admit though I've never understood light gray on black when
           | other options stand out better.
        
           | h2odragon wrote:
           | Amber was better than green.
           | 
           | And as someone else mentioned, dark rooms may be part of it
           | too. I find light backgrounds less obnoxious in brighter
           | light, but i avoid brighter lights by preference.
        
         | layer8 wrote:
         | > But I have to ask: do people really find color schemes like
         | this easier to read?
         | 
         | No, and also not the monospace font for prose.
        
       | detuur wrote:
       | 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 great dismay. If anyone remembers this post and still
       | has it, I'd love to read it again.
        
         | gruffypuffy wrote:
         | https://overthewire.org/wargames/ ?
        
       | sureglymop wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2023-08-23 23:01 UTC)