The problem is middleboxes like fortigate also do MITM on ssh connections. Assuming you are not bringing home devices into work and don't have your ssh server's fingerprint memorized you might be tempted to just type 'yes' when prompted.
In any case you are left with no SSH, or somebody watching your ssh and have control over your ability to tunnel.
The best you can do with these boxes is make a sub tunnel over one of the protocols that they do allow through, you just can't rely on the primary encryption provided by the protocol that the middle box is executing MITM on. If somebody actually looks at the traffic they will see that you are not transferring plain text at the middle box, so that might raise some eyebrows.
From what I've read (http://www.gremwell.com/ssh-mitm-public-key-authentication), if you use public key authentication with SSH, the MITM will break the authentication (forcing ssh to ask for a password). It's the same as with TLS client certificate authentication: in the same way the server certificate authenticates the server to your browser, the client certificate authenticates your browser to the server, and the server will reject MITM connections as unauthenticated.
While unfortunately for TLS client certificates are not a solution against MITM due to their awful user experience and privacy concerns, for SSH public key authentication has a good user experience, and is very common.
In any case you are left with no SSH, or somebody watching your ssh and have control over your ability to tunnel.
The best you can do with these boxes is make a sub tunnel over one of the protocols that they do allow through, you just can't rely on the primary encryption provided by the protocol that the middle box is executing MITM on. If somebody actually looks at the traffic they will see that you are not transferring plain text at the middle box, so that might raise some eyebrows.