Yes, and they don't need any magic here, just trivial matching on the TCP packet contents. Even though SSH and TLS (SSL) encrypt their payloads, the protocol headers themselves are still distinguishable and very different from each other. For example, a SSHv2 connection always starts with the client sending
SSH-2.0-(client name and version). Similarly, even though your firewall cannot really know whether the TLS connection carries HTTP inside, it can recognize TLS itself.
Such inspecting of layers above TCP generally falls under "Deep Packet Inspection", a relatively common feature.
One obvious way to bypass this is to tunnel SSH inside TLS – for example, using stunnel, haproxy, or sniproxy. (In addition to plain tunneling, where port 443 is dedicated to SSH-over-TLS, they can also multiplex SSH / HTTP / other protocols over the same port based on SNI and ALPN.)
While this wouldn't always defeat really sophisticated traffic analysis, it would still bypass most filters which merely check "does this look like a TLS header".
And then there's the annoying kind of firewalls – the ones which intercept TLS to decrypt and re-encrypt all traffic. These can actually see inside TLS, and can pass HTTP requests while blocking everything else. (Note that some antivirus programs also do the same thing.) You can recognize this kind by looking at the server certificates; all proxy-generated certificates look the same, and often don't pass validation, while real certificates are issued by various different CAs.