We can hear the chorus now..."What? I'm using SSH to improve security; what do you mean it causes threats!?" Calm down, we're just being complete here. There are no new threats that SSH causes per se, but there are existing issues that it perhaps exacerbates.
To employ SSH, your users must be able to make outbound TCP connections: and really, that gives them the power to do just about anything. Think you can restrict which Internet hosts they can contact? Think again: all they need is a proxy on a host they can reach to redirect their traffic. Think they can only use TCP because that's all the firewall lets through? Not at all: there are freely available tools that can operate a full-blown VPN over a TCP (e.g., OpenVPN). Think you're safe from inbound attacks because you allow only outbound connections? Don't be naive: that "outbound" connection is a two-way street once established and can be connected to anything at all.
The only things that keep people from violating your security policy with this access, aside from respecting the policy itself, are ignorance and inconvenience. Your users might not know how to play any of the preceding tricks, or it might be too much trouble if they do. SSH, however, makes some of these things very easy: tunneling outbound connections to "forbidden" TCP ports, reverse forwarding to tunnel back through your firewall and circumvent it, etc...and everything nicely encrypted so that you can't see what's happening!
The important lesson here is not that SSH is dangerous, but that truly limiting network access is a very difficult proposition: usually impossible, in fact, with any kind of reasonable effort (and if you want to get any other work done). When there are convenient tools like SSH lying around tempting people to get around annoying limitations, you can no longer rely on ignorance and inconvenience to enforce your security policy. Ultimately, you must gain the trust and cooperation of your users to have an effective security policy.