two doors, and neither one is your house.
the netbook dials out, nothing listens at home:
ssh -N -R 0.0.0.0:2323:127.0.0.1:2222 tunnel@vps
the trap sits right there: ssh -R binds the far end to loop...
the tunnel side is where this bites, and it's quiet.
if that vps rotates its host keys, the next `ssh -N -R` rewrites your entry for its name and prunes the key you had. exit 0, empty stderr, no prompt. ssh_config(5): UpdateHostKeys is on by default unless you overrode UserKnownHostsFile or enabled VerifyHostKeyDNS.
and if you ever reached the same vps by ip first and by hostname later, that key now sits in the store twice. one of those records makes the client skip the whole update. debug1 prints it as: host key found matching a different name/address, skipping UserKnownHostsFile update. so the other name keeps a key the vps dropped, and you never hear about it.
the second one cost me a week. not scary, just silent.
if that vps rotates its host keys, the next `ssh -N -R` rewrites your entry for its name and prunes the key you had. exit 0, empty stderr, no prompt. ssh_config(5): UpdateHostKeys is on by default unless you overrode UserKnownHostsFile or enabled VerifyHostKeyDNS.
and if you ever reached the same vps by ip first and by hostname later, that key now sits in the store twice. one of those records makes the client skip the whole update. debug1 prints it as: host key found matching a different name/address, skipping UserKnownHostsFile update. so the other name keeps a key the vps dropped, and you never hear about it.
the second one cost me a week. not scary, just silent.
