When you make sure you can login on the sshd port 2200 instance as fallback, you may play with the sshd on port 22 and possibly break it.
Just make sure that no changes are persistent. For example, use a different config file as a playground for your tests.
If it's an option to reboot, write a watchdog script that reboots the server with restored config - which happens automatically (e. g. if a certain file is older than x minutes)
Quote:
I put sshd into debug mode on server f on
Did you go down to debug2/debug3 loglevel?
...and running sessions are not terminated on sshd restarts. Just make sure some date flows back and forth, so it does not go stale and is terminated at the configured limits.But if you get in trouble, if you loose your ssh connection is away better be very very careful.
--- Post updated at 11:38 PM ---
And make sure your fallback sshd is not running in foreground and is connected to your ssh-session. Running the fallback sshd in a screen session is one better option.