I guess it is not very uncommon, since it has happened twice to me, in two sites I have worked. "Over-cautious" sysadmins decide that the University, Institute, Corporation, or whatever, would be safer if connections to the LAN from outside of it were banned, including the port 22. In an effort to avoid making security trample service (how considerate!) the usual solution to allow remote conection is to use VPN.
While VPN might have some advantages over SSH, I prefer the latter by far, and don't think a proper SSH setup has any lack of security, specially comparing to poorly implemented VPNs. For example, I would never trust something as vital as VPN software to a private company, yet most popular VPNs are proprietary (at least the University of the Basque Country uses the Cisco VPN). It is at least paradoxical that a free and open SSH implementation as e.g. OpenSSH, tested in such a throughout way, and for so long, is dumped, and a black-box solution developed by a profit-driven organization is used instead.
But I digress. I am not interesting in justifying why I want SSH. What I want to show here is a trick I learned reading tuxradar.com. Esentially, allows one to connect (with SSH) from machine A to machine B, even if machine B has all ports closed (so SSH-ing using another port would be useless either).
The idea (see below) is to connect from machine B to A, which is allowed (and is also the exact reverse of what we actually want to do), in a way that opens a canal for a "reverse" connection from A to B:
% ssh -R 1234:localhost:22 username_in_A@machine_A
Then we will be able to use port 1234 (or whatever port we specify in the ssh -R command above) in machine A to connect to machine B, as long as the original ssh -R holds:
% ssh username_in_B@localhost -p 1234
The picture shows it better:
SSHing from A to B (dashed red arrow) is disallowed, but the reverse (in black) is not. The ssh -R command line (see code above), opens up the link between ports 22 and 1234 (two-headed black arrow), so that a ssh -p to port 1234 in machine A will redirect us to machine B. If we are asked for a password (at the ssh -p stage), they are requesting the one for machine B, since we are being redirected to machine B.
Please, recall that the above recipe is no less secure than a regular SSH from A to B (if it were allowed), since anyone SSHing to port 1234 in machine A will be automatically redirected to machine B, but undergoing the same security checks as usual (password, public/private key...). Note also that I am talking about what is possible, not necessarily desirable or comfortable. It's just another tool if you want to use it.