HMAC ripemd160 is not supported

[stephenrauch]

Paramiko does not appear to support HMAC ripemd160. I know this because a system I have to communicate with recently decided that is was ONLY going to use this HMAC. (Yeah I know, WHAT?!?)

Although the crypto lib used supports this HMAC, it appears from a code inspection that paramiko does not due to hashlib not guaranteeing to support that HMAC on all backends.

Below is a monkey patch which I am using to make this HMAC work with paramiko on supported backends. I am putting it here in case someone else runs into this problem, or if there is some interest I could submit a PR with this logic applied directly to the paramiko.Transport() class.

### ::HACK:: ###

# this code monkey patches the paramiko library to support 'hmac-ripemd160'
# this HMAC is not guaranteed to be supported by hashlib, so is not natively
# supported by paramiko
import paramiko
assert paramiko.__version__.split('.')[0] == '2':
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.hashes import RIPEMD160
if default_backend().hmac_supported(RIPEMD160()):

    def ripemd160():
        import hashlib
        return hashlib.new('ripemd160')

    pref_macs = list(paramiko.Transport._preferred_macs)
    pref_macs.insert(2, 'hmac-ripemd160')
    paramiko.Transport._preferred_macs = tuple(pref_macs)

    paramiko.Transport._mac_info.update(
        {'hmac-ripemd160': {'class': ripemd160, 'size': 20}}
    )

### ::HACK:: ###

[bitprophet]

Thanks for the report/post!

Ever so slightly related to #387 insofar as that touches "make it easier for users to configure/update what kex/hmac/etc they use/want to use/prefer/blacklist/etc/etc, without ugly hacks".

I think best to hold off on a PR until that gets sorted out, though I am tentatively +1 on the idea of (additionally to making it easier for users do do what you do above) making it so we intelligently enable everything that the local system supports, by default.

[bitliner]

+1, can't use ansible because of this.