Security

A friend wanted to learn Linux, so I offered to spin up a VM under Proxmox. Done. Just kidding. I mean, that would work (assuming you handled port forwarding) if you were hitting an IP, but FQDNs are much easier for people to remember. Except ssh isn’t based on HTTP, so how do you forward them? One way is with nginx’s stream module. Something like this suffices. stream { upstream ssh { server $DEST_IP:$SSH_PORT; } server { listen $FORWARDED_PORT; proxy_pass ssh; } } And that’ll handle one person just fine. But what if another friend wants the same thing? Linux is perfectly capable of handling concurrent users, but the point of the VM was that they could break it during learning, and I could restore a snapshot (after giving them time to fix it themselves, of course). I could have multiple ports being forwarded, and direct each person to specify their assigned port, but that wouldn’t let me learn anything new. Plus, opening more ports is arguably less than ideal. If IPv6 was everywhere, every VM could just have their own IP, but we aren’t there yet. A VPN is of course a great option, and it’s something I’m working on. In the meantime, enter authorized_keys commands, and jump boxes. ...

Because alliteration. Moving on. If you’re interacting with APIs of any kind regularly, you probably have the credentials saved somewhere. Maybe you’re already using a solution to securely store these, in which case congratulations, you’re better than most. I, for one, was not. I assuaged my guilt with the knowledge that my Mac’s disk encryption meant that they were protected, but the whole thing still felt icky. This was briefly discussed in Slack, and this method of dealing with the problem came up. In short, it uses 1Pass to store secrets, and their CLI to access them and load them into the shell environment. That was all well and good, but I wanted a way to programmatically create the entry in the first place. 1Pass’ templates are JSON, so this wasn’t overly difficult with the help of jq. Download the CLI here. ...