Depending on how restrictive your local network is, you may be able to change the listening port of the SSH server to 80 or 443 and thereby fool the local network into thinking that you are communicating over those ports. But a stateful firewall will almost immediately catch those connections and block them, because SSH doesn't look like HTTP(S), so it will detect that you are sending SSH traffic over an HTTP port and block it.
Also, if you're behind an HTTP-only proxy or transparent (forced) HTTP proxy, then you can't get out on anything but HTTP.
If you are locked down in this way, then the best thing you can do is enable web based SSH access on the server by installing a package, or use a web service that does so (e.g. GoToMySSH). But in practice, many networks also block the most common web SSH providers, or block the technology they use (ActiveX or Java applets), or the connection is sufficiently logged and monitored that they'll block access to the remote server if they find out that you accessed a remote shell on it.
In short, playing cat and mouse with the network admins on a network that you don't control is pretty much a game of grasping at straws. If they want to prevent you from doing X and are investing a lot of time in preventing it, then they will ultimately succeed. But if you just have a simple router that isn't being monitored, you can probably succeed just by changing the listening ports.
That said, you won't be able to get into the system in the first place to change the ports or set up a web SSH console if you can't SSH into it. So you'll probably have to go home to a less restrictive connection first.