The SSH protocol is from the same era as SSL (the 1990s) and shares a lot of common principles. Both are relatively complex assemblies of several cryptographic algorithms, and SSL in particular served as a testbed for many novel attack techniques related to side-channel leaks (see this answer for a summary of attacks which have met some success with some versions or implementations of SSL). SSH seems to have less suffered from SSL, mostly because:
It is a lower-value target. A cryptanalytic paper which breaks some facet of SSL is more likely to get some non-academic attention than a similar paper which concentrates on SSH; and "attention" correlates (loosely, but still) with prospects of future funding.
SSL's public key management relies on X.509 certificates, and thus inherited all the relevant troubles. The public key distribution in SSH is much more primitive and lacks the flexibility of X.509, but it is also much harder to break (the SSL model strives to allow a client to securely connect to a server to which the client has never talked to yet; in the SSH model it is merely asserted that this problem is handled "out of band").
In any case, the developers of OpenSSH (the main SSH implementation nowadays) keep an eye on known attacks on SSL; and for the elementary cryptographic algorithms, OpenSSH uses the code from OpenSSL (the very classic and widely used opensource implementation of SSL). Thus, some attacks on SSL which could have been adapted to SSH have been preemptively countered that way.
The cryptographer's point of view is thus that the SSH protocol is roughly on par with SSL. SSL is the most attacked communication protocol, but also the most repaired, and every single novel attack has been tried against it, so we may say that SSL (and thus SSH too) is extremely secure -- as long as you dutifully apply security updates on implementations.
When looked at closely, you will see some cryptographic-level differences between SSL and SSH:
The SSHv2 protocol always uses a Diffie-Hellman key exchange; the server's private key is used only for a signature. This is similar to the "DHE" cipher suites in SSL, and provides Perfect Forward Secrecy. This is a good thing (it means that stealing the private key of a server does not allow decrypting previous connections that the attacker could have recorded).
The symmetric encryption layer combines encryption and a MAC in a mode known as "encrypt-and-MAC", distinct from the "MAC-then-encrypt" used by SSL (see this question for details). Both modes, though, are relatively poor, and require great implementation care to be secure (OpenSSH developers did take care).
In practice, the biggest vulnerability of SSH, by far, is the human user. Servers get broken into through SSH, not because of a cryptographic vulnerability of the protocol, but because either some remote hole was found and exploited in the server code, or the user's password or private key was stolen (typically because of some client-side malware). The really important step that must be taken is to make sure that security updates on both the server and the client are applied with all the possible alacrity.
Remember that SSH is, by nature, a way to remotely control a machine. It is a hole in the server's defence perimeter. A user who can SSH into a machine can then potentially run every possible "local exploit" against that machine. Believing that a given computer is safe against local privilege escalation would be overly optimistic; making the system secure against remote exploits is already hard work. Therefore, don't give SSH accounts away needlessly.
And use a strong password ! (See this for inspiration.)