Pass sshuttle ssh options to get around remote hosts whose identification changes often (testt/dev/ops systems)

sshuttle-opts.sh

# It is possible to paas sshuttle common ssh options such as UserKnownHostsFile, StrictHostIPChecking, CheckHostIP etc 

# Normal sshuttle command:
sshuttle -r ubuntu@<some-ip>:2222 <remote_subnet(s)/CIDR>

# In the above scenario, for most systems, StrictHostKeyChecking, and all other good security features will be in effect.
# That's normally a good thing, except when it's not.  Like when you have to continually clean a known hosts file because
# your testing different build options and the remote host's ECDSA, DSA, RSA <or whatever> keeps changing.

# By making use of the -e option you can control how sshuttle uses ssh.  Any option your ssh-client supports can be passed.
# Ex:
sshuttle -e 'ssh -q -o CheckHostIP=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' -r ubuntu@<some-ip>:2222 <remote_subnet(s)/CIDR>

#Ex with real addresses:
sshuttle -e 'ssh -q -o CheckHostIP=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' -r ubuntu@192.168.8.134:2222 172.27.20.0/22

#Hint: Besure to strong quote the options so they make it intact though the shell, python and, eventually the remote host

# Like any sshuttle session, the above will relay sessions (not packets) through an ssh-tunnel via port 2222 on host 192.168.8.134 using publickey access for user ubuntu
# Hosts that reside on between 172.27.20.1 and 172.27.23.255 will be accessible directly from the host that the above
# command is ran from.

# However, since we are controlling how shuttle is using ssh. the provided options would not hold up the sshuttle
# session, due to conflicting stored key entries in ~/.ssh/known_hosts, and will actually write the "entry" for the host it is attaching
# to /dev/null, getting rid of the need to continually clean offending keys from your known_hosts file
# especailly when connecting to systems that frequently get rebuilt.

# IMPORTANT: Bypassing security features on public networks or production system is the epitome of a bad idea!
# However, when used with common-sense, on a private network under your control, these options can and do prevent a lot of headaches for
# test/dev/ops folks who frequently rebuild systems and like to automate the connection process.  With these options,
# you can say good bye to the "Nasty" messages kill your automated scripts ;)
# 
# @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
# @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
#   IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!