I love Match. I use it to automatically select my bastion/jump host when not on my home network and not on my local VPN:
$ cat ~/.ssh/config
# Define external nodes here
…SNIP…
# If connecting to a *.xn0.org host and router.xn0.org = 10.0.0.1, must be home/vpn.
Match host *.xn0.org exec "getent ahosts router.xn0.org | grep -q ^10.0.0.1"
ProxyJump none
# If connecting to a *.xn0.org host and the macaddr of 10.0.0.1 is NOT f0:9f:XX:XX:XX:XX, then use jump.xn0.org:
Match host *.xn0.org exec "! arp -ne 10.0.0.1 | grep -Fq f0:9f:XX:XX:XX:XX"
ProxyJump jump.xn0.org
# Define internal nodes here
…SNIP…
(As someone that's a long-term SSH user most of the good stuff was in the thread)
I also believe the day before yesterday someone showed an incredible rsync/dotfile/ssh trick in the comments but I have no idea what article it was on.
I'm not sure if Big SSH is astroturfing HN lately or not but I'm here for it.
Match is useful, but for anyone trying to solve the problem of accessing a given machine from different networks check out Tailscale. It's one of the closest things to magic that I've found in recent years and just works. I used to have a dynamic DNS thing set up, and all kinds of firewall rules to be able to ssh to my home machine when on the road from my laptop and now I just ssh [hostname] and it just works, wherever I am.
The only thing stopping tailscale solving all my problems the latency. It's 3-5x higher than straight wireguard without their cloud relay, 5-10x higher (or more) on their relay.
While I draft an easy prompting for complex YubiKey SSH MatchHost (not yet git-pushed), I’ve got this OpenSSH configuration tool based on user-prompting of many other OpenSSH-related configuration settings into sshd.conf/ssh.conf file using /etc/ssh[d].conf.d directory holding many setting files.
Each setting file has a full comment page on how to use its keyword, a commented-out default setting, and a CISecurity-recommended setting.
Each setting files are named (via numeric prefix) to be in execution order, which enables for easier thinking of “how deep” it goes into the SSH protocol.
As a default, the config files are written into a local build/etc/ssh subdirectories for perusal before being implemented manually into /etc
I also used to do mosh+tmux for remote development from my Mac.
A few months ago I switched to WezTerm, which has a built-in first class terminal multiplexer and remote protocol, including typeahead. The benefits are that I'm using the same terminal I (now) use on my Linux box, so I have the same keyboard shortcuts on Mac and Linux, and various things like cut/paste aren't weirded out by tmux.
The one downside I've had so far is that often when I've suspended too long my wezterm client disconnects and I have to reconnect to the session (just up-arrow+enter in my terminal), where mosh+tmux would just stay always there.
Well, setups using forced commands are relatively common with SSH (case in point: probably any Git server you've ever accessed over SSH); if one of those setups also allowed their user to specify ssh_config rules without realizing that Match can exec things there'd be a problem. I think that's a bit of a stretch though.
The ForcedCommand is server-side, the Match exec from ssh_config is done client-side. The server has no way to enforce which commands the client can run locally.
What is "SDN", how is it different from the thing that everyone else has called "VPN" for a few decades, and why not just have its resolver serve answers for the same TLD? Or better yet why not just route your home subnet over the VPN subnet (probably with a high metric, so that it doesn't override "real" routes) so you don't need a different IP?
Match is extremely useful though. It's in use on a few systems I control to allow password authentication from certain subnets.
Worth noting that I actually just use split-horizon DNS for my personal VPN though. Telling Unbound this is a lot easier (and still works with stuff that isn't SSH):
local-zone: "mydomain.com." transparent
local-data: "foo.mydomain.com. A 10.0.0.4"
I did not know we could do exec in ssh config so I learnt something new today!
However, I also have a similar setup but for my SDN I use Twingate which lets me re-route DNS when its connected so all I need to do is the equivalent of defining
*.lan
as a resource in the UI and then I can reach it no matter when I'm connected via SDN or not.
`Match exec` lets you do some convenient stuff. Like using env vars to determine which environment you're ssh'ing to when you re-use cidrs in multiple regions or w/e.
Could also set up DNS server to return different IP addresses for same hostnames depending on the which interface the DNS client is connecting from. There'd only be one hostname per server, two (or more) IP addresses each mapped to originating network.
I don't think it's reasonable for clients to cache responses across disconnect/reconnect, especially when the network has observably changed (new default gateway, for example), and even more so when the resolver has changed.
Based on my own personal experience I'd also say that no (modern) clients do so although that could be wrong.
Neat trick, but seems like something that should be solveable few layers lower. Does he mean VPN when he says "SDN"? Like why does the laptop have two different IPs and hostnames to begin with?
