… forward

The previous options string was

restrict,permitopen="127.0.0.1:",permitopen="localhost:"

which authenticates fine but blocks every channel-open request:

channel 0: open failed: administratively prohibited
stdio forwarding failed
Connection closed by UNKNOWN port 65535

Reason: OpenSSH's restrict sets permit_port_forwarding_flag = 0, and permitopen only adds entries to a filter list — it does not flip the flag back on. The channel-open hook checks the flag BEFORE consulting permitopen, so the restriction wins and the permitopen entries are dead config. The man page hints at this: "may be followed by other options (e.g., port-forwarding) that re-enable specific functionality."

port-forwarding is the explicit re-enable; permitopen is the narrower filter that applies once forwarding is enabled. Adding it between restrict and the permitopens fixes the operator's ssh -J gopher-jump@vps -p <rathole_port> ... flow without loosening any of the other restrict-imposed protections (no shell, no X11, no agent, no env, no ~/.ssh/rc, no PTY).

The next ReconcileAuthorizedKeys cycle after this ships rewrites every existing options line in place — addToAuthorizedKeysFor matches by type+keydata token, ignoring options, so updating the prefix doesn't duplicate or scrub the keys. Operators who already migrated to the new authorized_keys layout get the fix on the next service start.

Regression test guards against a future refactor that drops port-forwarding from the options string.

Description

Resolves #__

Changes Made

Testing

• Tested locally
• Added/updated unit tests
• All tests passing

Screenshots (if applicable)