Thanks for the detailled report! Indeed cockpit-ssh only checks for MD5, but today's SSH offers and defaults to other hashes (in particular, SHA2). So we should detect the hash type, or at least try all of them (it seems current libssh only supports HASH_MD5 and HASH_SHA1 anyway, both of which are already broken).

To ensure that we can reproduce/verify this properly: How do you enable FIPS mode?

Good day Martin,

There's a series of steps to make sure a system is FIPS compliant.  Here's the steps that I used when I set it up on my end:

How can I make RHEL 6 or RHEL 7 FIPS 140-2 compliant?
https://access.redhat.com/solutions/137833

If that doesn't work for you or you need steps directly in the case, please let me know and I can update that.

Thanks and have a great day!
Best Regards,

Anthony Zone, RHCE
Senior Technical Support Engineer, Services Support Team
Customer Experience & Engagement - North America
Red Hat, Inc.
1.888.GO.REDHAT

This has already be implemented and will be in libssh-0.8.2 later this week:

https://git.libssh.org/users/asn/libssh.git/log/?h=master-pubkey-hash

I tried to reproduce this on Fedora 28 with enabling FIPS, and this crash does not happen there. Adding an unknown host and showing its fingerprint works fine.

But I can reproduce this on current RHEL 7.6. To fix this in RHEL 7, we can't make use of the new libssh 0.8 API, but we can just use a more modern hash and use glib's hash functions instead of libssh's.

We could also backport the patch to libssh-0.7 that you have the function available there ...

There's actually two separate aspects here:

 * For stable releases like RHEL 7, I don't actually think we should change the hash away from MD5. Even modern ssh still shows fingerprints with both MD5 (for historical reasons) and sha256 these days, and presenting the hash differently in a stable OS update seems somewhat unfriendly.

  So for fixing this *particular* crash but keeping MD5, using glib's MD5 method might be an option (I still need to verify that this actually works, and does not use the very same MD5 function from OpenSSL). Of course that means to implement the hashing of the ssh_key in cockpit-ssh, which is something I'd much rather avoid.

 * For future releases and upstream, using the libssh 0.8 API and moving to SHA256 seems prudent. Users need to get weaned off of MD5 fingerprints at some point :-), and a major change like RHEL 8 is an adequate time for such a change.

It's a bit annoying that this is an assertion in OpenSSL, as opposed to just a failing function. That makes it harder to do a runtime check, which would allow us to present an SHA256 hash *if* MD5 is not allowed, for RHEL 7.

cockpit-ssh could do something like

   if /proc/sys/crypto/fips_enabled == 1
        fingerprint = SHA256 sig
   else
        fingerprint = MD5 sig


But that would then mean supporting both cases, including a duplicate set of translated strings, for a while.

So in summary, backporting the new libssh API and moving to SHA256 fingerprints everywhere (including RHEL 7) would be a clean and safe implementation, but might upset some customers. But keeping MD5 and reimplementing the hashing with glib (or something else) is a security-sensitive and intrusive change for a stable release update. 

So, rock <-> hard place :(

Some more facts:

- On current RHEL 7.6, the "ssh" CLI shows fingerprints with SHA1 and SHA256 by default, not even MD5. 

- I went through all strings that concern fingerprints in Cockpit, and there is only one that explicitly mentions "MD5". This isn't even translatable (which is a bug, but one that plays into our favor for getting a freeze exception :) ). Thus changing the algorithm or supporting two different ones for some time is not that intrusive.

I checked libssh 0.8.1's API, and I don't see a function that returns the raw bytes/numbers of an ssh_key, so attempting to use a different hash function from glib or so isn't very practical.

So how about this:

 - Wait until libssh 0.8.2 hits Fedora and RHEL 8.
 - Add a configure check to Cockpit that checks for SSH_PUBLICKEY_HASH_SHA256, and if available, use SHA256 instead of MD5. Adjust tests to get along with either.
 - Backport the SSH_PUBLICKEY_HASH_SHA256 libssh support to RHEL 7 (as you proposed)
 - Backport the Cockpit change to RHEL 7. Justification is that MD5 has been broken for a long time, and the command line SSH does not show it by default.

Does that sound reasonable to you?

Created attachment 1478462 [details]
Patch to suppor sha256 hashes for pubkeys on libssh-0.7.x

It does for me.

I couldn't release 0.8.2 yet as I need abimap-0.3.1 which is not available on openSUSE Tumbleweed yet. However it should be on Monday.

Adjusting depends/blocks for RHEL 7. I just filed bug 1637182 about the necessary libssh backports, fixing this bug in RHEL 7 is blocked on that.

In bug 1637182 I pushed SHA256 support patches to dist-git, plus the fix for the "interactive keyboard" authentication (bug 1640812). I locally mockbuilt libssh and cockpit with the corresponding fix, and everything works -- I get SHA256 fingerprints, and it does not crash in FIPS mode.

Now I just need to figure out how to build cockpit against that pending libssh update.

I tried an initial scratch build here: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=18953765

As I feared, this doesn't see the new libssh update from https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=789421 , even though I tagged that with extras-rhel-7.6-go-toolset-candidate. Will ask Djordje tomorrow.

Repo for updated libssh, in case it helps: http://brew-task-repos.usersys.redhat.com/repos/official/libssh/0.7.1/7.el7/libssh-0.7.1-7.el7.repo

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3712