There is an amazingly simple directive missing here:<p><pre><code> # 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");
</code></pre>
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.<p>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.
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.<p>This may seem inconsequential, but IME when changing defaults in, e.g., /etc/ssh/sshd_config, people and software tend to <i>append</i> their changes to the end of a file or directive block, not the beginning, expecting those changes to be effective. Even security companies and organizations get this wrong, including various SSH bastion products I've seen. CIS Benchmarks recommendations (IIRC) <i>and</i> most (all?) third-party CIS audit suites don't consider precedence at all or get it wrong--e.g. by recommending appending a value, or by providing a compliance test that accepts a broken configuration. FWIW, the proper way to check whether an OpenSSH configuration directive is defined as expected is to use `sshd -T` or `ssh -G` to dump the derived, internal configuration, not by directly inspecting the configuration file(s).
> <i>The best way I found to remember this is local forwarding with-L means local is on the left-hand side of the address. Remote forwarding with-R means the local port is on the right-hand side of the address.</i><p>This is the most important, succinct statement made in this piece. -L and -R confused me from the get-go. Having which port instance L or R is "local" change is in some ways, annoying. I "get" that -L and -R change the direction of intentionality, where initiator and responder are, but I think it might have been sensible to make a port:address:port phrase ALWAYS refer to local:binding:remote and have -L and -R define which was listen and which was send.
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).<p>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.<p>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.<p>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.<p>More info: <a href="https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing" rel="nofollow noreferrer">https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing</a>
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...<p><pre><code> # 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</code></pre>
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.<p>-t is a cool trick, didn't know about that one.<p>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).<p>Cool list, it definitely lines up with what I've found useful and had a few more.
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.<p><a href="https://github.com/openssh/openssh-portable/pull/431">https://github.com/openssh/openssh-portable/pull/431</a>
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.
Why tilde? Because rlogin, rsh used it.<p>Why did rlogin, rsh use tilde? because cu used it.<p>Why cu? Because if you had a modem or serial line, cu was the way you talked to it, to send Hayes codes, and you can't use Hayes codes breakouts because they will break to the modem, so you need a signal to break to cu.<p>Why not ^[ ? Because thats telnet. so if you had telnet to a host, to connect to the modem over cu, you needed a distinct break-back for cu, to not break back to telnet.<p>Its breakout syntax all the way down.<p>Also, its not actually tilde, it <cr>tilde
> ssh-copy-id<p>This section starts out talking about how the command uploads your public key then seamlessly switches to saying it uploads your private key (which I am guessing are typos).<p>Also that command does not just upload the key, it appends it to ~/.ssh/authorized_keys which is considerably more useful.<p>Finally, in the ssh-keygen section, ed25519 is from everything I’ve read preferred these days to ecdsa.
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.<p>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.
I'd add to this list that in 2023 you should be securely storing your key in a HSM.<p>On Mac, that's easy to do via the Secure Enclave:
<a href="https://github.com/maxgoedjen/secretive">https://github.com/maxgoedjen/secretive</a>
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.
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?<p>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!
This is really cool stuff.<p>I just wanted to mention that not only does it have subsystems like sftp but you can make up your own subsystem (i use parameko!) to so just about whatever you want. Cool stuff like exposing the remote host's sound or random devices over ssh, cool BBS displays/apps or for the sneaky: command and control protocol between your malware/implant that proxies normal ssh for normal ssh clients as usual.
Tangentially related, I love that VSCode has an extension that lets you ssh into a remote host folder and treat it like a workspace. Most useful thing ever.
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."
`-g` was new to me. I believe I have done something similar by providing an explicit bind address to -L, like this:<p>ssh -L 0.0.0.0:2222:10.0.0.1:22 host<p>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).<p>The biggest gap in this collection of tricks (IMO) is SSH certificate support.
Maybe (hopefully :)) also interesting for those who enjoyed this article: <a href="https://johannes.truschnigg.info/writing/2022-07_advanced_ssh_usage/" rel="nofollow noreferrer">https://johannes.truschnigg.info/writing/2022-07_advanced_ss...</a>
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.
Great article that collected a lot of info that I usually wind up looking for separately.<p>But I have to ask: do people really find color schemes like this easier to read? I'm squinting at it throughout.