Certain places firewall TCP ports other than the most common ports. There are many techniques for bypassing such restrictions. One simple approach is to run a SSH daemon on port 443, however a downside of this is you need to dedicate an IP address to this SSH service.
There is quite a neat technique for making SSH and SSL share a port; in the SSL protocol clients should write first, whereas in SSH the server should write first; therefore by waiting to see if the client writes data it is possible to make a guess as to if the client is an SSL client or a SSH client.
I'm not the first person to think this up, Net::Proxy has a script called sslh and confusingly there is also a C implementation also called sslh.
I recently switched my web server to use HAProxy to allow me some more flexiblity in how I configure things (especially now the development version has keepalive support). While reading the (incredibly detailed) documentation I noticed it should be able to do the sslh technique.
Doing this needs the (currently) in development HAProxy 1.4 (support was added for content switching TCP as well as HTTP in this commit -- thanks to Cyril Bonté on the mailing list for confirming that).
The configuration looks something like the following (global section omitted, you'll want to run it as a user other than root and chroot it if you actually use this).
defaults
timeout connect 5s
timeout client 50s
timeout server 20s
listen ssl :443
tcp-request inspect-delay 2s
acl is_ssl req_ssl_ver 2:3.1
tcp-request content accept if is_ssl
use_backend ssh if !is_ssl
server www-ssl :444
timeout client 2h
backend ssh
mode tcp
server ssh :22
timeout server 2h
This listens on port 443, forwards it to port 444 (where the actual SSL web server is listening) unless it is not SSLv2, SSLv3 or TLSv1 traffic, in which case it forwards it to the ssh backend listening on port 22.
Obviously as I said earlier this is only a guess that is subject to network conditions such as packet loss. I'm not recommending you use this technique on a production site, but for a low traffic machine where you want to run both protocols it is very useful. (By increasing the timeout for SSH you increase the chances of a correct result, but also add a potentially annoying delay).
Sometimes layer 7 filtering techniques are in use and just listening on port 443 is not enough. In this case you can use SSH inside SSL.