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

101–110 of 120 posts

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

#101

Post by n8henrie »

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…

I think some directives can be duplicated -- like AllowUsers.

But I got bit by something related yesterday when NixOS suddenly changed the merge order and put my AllowUsers from own file below a Match from another file and locked me out :(

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

#102

Post by e12e »

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

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

#103

Post by semi »

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 ssh to GitHub as you.

() there was a vulnerability not too long ago involving getting the remote agent to load arbitrary shared objects for remote code execution, which obviously changes things

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

#104

Post by maratc »

raffraffraff wrote: post #92
lmz wrote: post #70

Earlier quoted context omitted.

Tilde dot is the disconnect sequence for SSH. Other characters after tilde have other uses as seen in the post.

And if you're N connections, use multiple tildes, depending on how many levels you want to disconnect. I think . It's amazing how switching jobs to one where you just write terraform and yaml all day gets your terminal skills all rusty.

There's a song about it, it's called "Ctrl up-arrow Q".

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

#105

Post by zamadatix »

ilyt wrote: post #22
zamadatix wrote: post #9

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…

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

If you avoid -f you can also chain commands knowing the second will only be run when ssh is finished running. Something I do often:

  ssh host.example -N -D 1080 && wall "Socks proxy to host.example closed."
The second command can be as complex as you want but a message in all terminals usually does the job for me.

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

#106

Post by callalex »

TheRealPomax wrote: post #55

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."

Doesn’t your browser of choice have some kind of reader mode?

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

#107

Post by pxc »

Shadowmist wrote: post #88
pxc wrote: post #82

Earlier quoted context omitted.

Amazon Linux does something sort of like this, which I guess is 'production quality', meaning much more complex. It annoys me on older versions of Amazon Linux (2 and earlier) because it involves (among other things) an invocation of the openssl CLI to verify the format of individual keys in the authorized keys file that is hardcoded to use RSA, so you can't authenticate to Amazon Linux 2 hosts using ed25519 even tho…

Use AWS SSM with something like Leapp.

Thanks for the tip! I will probably learn and play with SSM at some point.

As it is, I'm much the opposite of our cloud-first DevOps guys: I know how to operate Linux a lot better than I know how to operate AWS. That makes yours a more intimidating proposition to me.

At the same time, this particular box was a shortlived VM that was already behind a VPN, my organization already has tentative plans to implement a different network access system than SSM, it won't be my project to execute, and I don't get to be in the room for architecture decisions related to it.

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

#108

Post by labawi »

cholmon wrote: post #45

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…

There an additional trick - you can put include inside a Host/Match directive.

  # in ~/.ssh/config
  Host proj1.*.corp
    Include ~/.ssh/proj1.conf

  # in ~/.ssh/proj1.conf
  ...
This way, I can put project-specific matches at or near the top, while being sure I don't have to wade through numerous of individual files during review.

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

#109

Post by TheRealPomax »

callalex wrote: post #106
TheRealPomax wrote: post #55

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."

Doesn’t your browser of choice have some kind of reader mode?

Unfortunately, reader mode doesn't magically change the colours in all those code fragment images.

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

#110

Post by pxc »

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…

I'm an idiot about sudoers and got this completely backwards
Post reply on HN