Given the recent confirmation of weakened and broken encryption schemes and implementations, how does the community feel about the security of SSH?
It seems there has been very little discussion relating to SSH in the context of these leaks.
Additionally what configuration would be recommended to harden SSH?
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 is used in HTTPS, i.e. the Web, and Web browsers are marvelous engines that can, in particular, run the attacker's code (with Javascript). Thus, chosen-plaintext attacks are much easier to demonstrate with SSL than with SSH.
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.)
Additionally what configuration would be recommended to harden SSH?
Do not use version 1. OpenSSH, included in many Linux distributions, has an option to reject version 1 connection attempts. Keep this enabled.
Use public/private keys instead of or with passwords. These are stronger than passwords.
Do not run it on the default port. It is security by obscurity, but will reduce the number of attacks you get.
If your level of paranoia is high, be aware of the metadata you generate in transmissions, i.e. IP source and destination addresses, times and durations of connections. SSH does not obscure or secure this information.
Regarding the confidence of SSH, the good news is that SSH is designed to work with multiple algorithms. If you do not trust a specific algorithm, you can use another.
You can configure most SSH servers to use/accept specific or preferred algorithms. The client must also support this algorithm. If you don't trust RSA, use Blowfish or another cipher (A post here is helpful). Putty supports Blowfish and a few other ciphers as well.
I lack the expertise to compare them, but it can be a good starting point for your own research.
