I have a Jetson Nano at home that I SSH into from my laptop. At home it’s on a local IP, but when I’m out I reach it via a public IP. I got tired of switching between ssh jetson-home and ssh jetson-www depending on where I am.

A VPN like Tailscale or WireGuard would also solve this, but I don’t always remember to switch it on. I wanted something that just works without thinking about it.

SSH doesn’t have a native fallback host option, but ProxyCommand with nc does the trick:

Host jetson-home
  User me
  HostName 192.168.1.100
Host jetson-www
  User me
  HostName 203.0.113.50
Host jetson
  User me
  ProxyCommand bash -c 'if nc -z -w 2 192.168.1.100 22 2>/dev/null; then nc 192.168.1.100 22; else nc 203.0.113.50 22; fi'

nc -z -w 2 probes the port with a 2 second timeout without sending any data. If the local IP responds (I’m home), it opens a fresh nc connection without a timeout. If the probe fails, it falls back to the public IP instead. SSH’s ProxyCommand expects a command that pipes stdin/stdout to the remote SSH port — nc does exactly that. SSH then does its normal handshake over whichever connection succeeded.

Important: don’t use -w on the actual connection — on most nc implementations it’s an idle timeout too, not just a connection timeout. Your SSH session will drop after 2 seconds of inactivity. Use -z to probe first, then connect clean.

Now ssh jetson just works from anywhere. I can still use ssh jetson-home or ssh jetson-www directly if I want to force one.

Host key gotcha Link to heading

One thing to watch out for — when using ProxyCommand, SSH identifies the host by the config name (jetson) rather than the IP. If your known_hosts only has entries for the IPs, you’ll get a host key verification failure. Fix it by adding the alias:

echo 'jetson ssh-ed25519 AAAAC3...' >> ~/.ssh/known_hosts

Or just connect once with ssh -o StrictHostKeyChecking=accept-new jetson.

Other Jetson Nano posts Link to heading

Further reading Link to heading