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 u…
An excruciatingly detailed guide to SSH (but only the things I find useful)
81–90 of 120 posts
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#82There 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 u…
In theory it's kinda nice because it can let you do fancy things¹, but my actual experiences with it breaking basic functionality even for people who don't use those fancy things has ultimately made me trust Amazon Linux less.
It was especially frustrating because when I first encountered this, I was trying to SSH into a box owned by one of our cloud-first DevOps guys. I couldn't diagnose the box because I didn't have hands on it. He couldn't diagnose the issue because he knows AWS better than he knows Linux and didn't know where to look. He'd chosen Amazon Linux because it's by the owner of the cloud platform, so it must be 'more compatible', right? But here, 'more compatible' actually meant 'more full of stupid surprises'.
Bleh.
--
1: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-...
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#83There 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 u…
why php?
Other languages I know would require imports/boilerplate that would distract (Go/C#/C/Python/Scala/JS) from the example. Bash might be more familiar with devops but less familiar to regular programmers — part of the illustration I wanted to make was that it didn’t need to be a devops thing. Also PHP (along with JS) is a language most devs know a little bit about, whether they want to or not.
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#84Earlier quoted context omitted.
why php?
It’s the only language I could think of that could express a whole working example in only a couple of lines of code in a highly readable way. Other languages I know would require imports/boilerplate that would distract (Go/C#/C/Python/Scala/JS) from the example. Bash might be more familiar with devops but less familiar to regular programmers — part of the illustration I wanted to make was that it didn’t need to be a…
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#85Here'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…
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 easy to create settings that can't be overridden in by adding a new file in a whatever.conf.d directory: you define those settings in the main config file before you source whatever.conf.d/* and you put some kind of special protections on that file.
Even where you're not worried about somebody evading your controls per se, it can be nice from a configuration management perspective in giving you a soft 'guarantee' that if some new hire who doesn't have the whole picture adds a new file in there, or some package tries to install a stupid default for its own service, your baseline settings can retain priority.
In other contexts you probably see the opposite behavior because what you really want is not a 'baseline configuration' but a collection of defaults in the strict sense: fallback settings to be used in case nothing is explicitly configured by the user, developer, or administrator (as the case may be).
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#86Why tilde? Because rlogin, rsh used it. Why did rlogin, rsh use tilde? because cu used it. 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. Why not ^[ ? Because thats telnet. so if you had telnet to a host, to connect to the modem over cu, you neede…
I thought it was CR, tilde, . ? have i been doing it wrong?
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#87I'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!
If you don't need a certified HSM that generates keys on device (and you don't, right? You can generate keys on a ramdisk from live media with no persistence and no/encrypted swap), you can use basically any PGP smartcard, including nice little USB ones like Yubikey and NitroKey. And even if you do you can get a little USB HSM.
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#88There 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 u…
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…
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#89Some 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…
https://overthewire.org/wargames/ ?
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#90Great 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.
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…
On the whole, this actually allows you to achieve the same contrast level with lower total light emission. If you are in fact clinically light sensitive and you also have difficulty with low contrast, you just can't achieve the balance of contrast you need as effectively with light themes.
> then they are surprised to be blinded when they open a webpage, which is extremely likely to be light themed
For me it's well worth it to sacrifice the 'artistic integrity' of web designers' intentions and use something like Dark Reader or Midnight Lizard to force a dark theme across the whole web.