OpenSSH and OpenVPN have nearly identical attack vectors with regard to MITM. In a default configuration, both require an upfront exchange of public keys (SSH at time of first-connection; OpenVPN at time of first-configuration).
In fact, because OpenVPN requires the client to obtain the server's certificate ahead of time out of band, and SSH instead relies on the end user typing "yes" after manually comparing a fingerprint, it could be argued OpenVPN is less susceptible to a MITM attack.
edit:
Additionally, from past experiences linking up cn-north-1 with us-east-1, individual SSH tunnels fail constantly. individual VPN sessions fail constantly. The only way we were able to make life livable between the two was by way of BGP across a combination of ipsec and openvpn tunnels. (different tunnels, mind you; not layered)
They are not identical in attack vectors, and OpenVPN has many more capabilities to resist MITM and other attacks, and it resists network failure much more.
OpenSSH uses the SSH protocol and username/password and public keys for auth.
OpenVPN auth uses TLS key exchange, pre-shared keys, and username/password, and uses IPSec's ESP protocol for transport, with custom work to handle multiplexing connections. It can verify HMAC on all packets. It tunnels layer 2 or 3. It won't swap sensitive memory and can utilize SELinux. Since OpenVPN can use static keys and a UDP transport, it can resist network partition much better than OpenSSH.
Of course IPSec is much better than either of them. If you have to do all your tunneling in userland, OpenVPN is a more secure method, but if you don't have tun/tap device access, OpenSSH will get you by with port forwarding (which is what its SOCKS tunnel is, if you don't use its tun/tap device or pppd).
OpenSSH and OpenVPN have nearly identical attack vectors with regard to MITM.
Perhaps in theory, but in practice I would argue otherwise. Why?
Most SSH configurations require key verification and are rarely modified otherwise.
By contrast many OpenVPN configurations, statistically, have MITMable keys, and as they tend to be written from scratch the likelihood of these configurations in the wild is much higher.
With regards to SSH tunnel longevity, try specifying the ServerAliveInterval and ServerAliveCountMax options.
In fact, because OpenVPN requires the client to obtain the server's certificate ahead of time out of band, and SSH instead relies on the end user typing "yes" after manually comparing a fingerprint, it could be argued OpenVPN is less susceptible to a MITM attack.
edit: Additionally, from past experiences linking up cn-north-1 with us-east-1, individual SSH tunnels fail constantly. individual VPN sessions fail constantly. The only way we were able to make life livable between the two was by way of BGP across a combination of ipsec and openvpn tunnels. (different tunnels, mind you; not layered)