It is base64 trimmed the last '='.

Introducing new specifier, say %f, would be good, while keeping %F as is.
%f includes the hash algorithm string as SSH does.

It seems to be base64:

% ssh -V
OpenSSH_7.1p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E md5 -q
playfair.gnupg.org RSA MD5:cc:dd:46:8e:ef:3d:d9:34:97:f8:b8:5a:59:51:80:4a
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E sha256 -q
playfair.gnupg.org RSA SHA256:KCh034SD0rMKqCkJbdH2wx354s1278tqt9F+xb5cidg

6.7 still shows MD5 fingerprints thus switching won't be easy. Does the SHA-256
fingerprint use Base32? If that is the case it might be a serious UX problem
because most people are used to look for colon separated hex digits.

I generalized the ssh key fingerprinting code so that we can select the digest algorithm.

Now I'm a little unsure how to proceed. We can easily include both the MD5 and the SHA256 digest
in the sshcontrol file. But what shall we use for expanding '%F' in key descriptions? If we
transition too soon or too late, users might not recognize their key. Displaying both surely is
too verbose. We could make it configurable, or at least a compile time option.

What do you think?

Removing and readding key helped. Thanks. Seems to be solved in 2.1.9

Please remove your private key(s) of ed25519 and register it again.

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798956#24

The same issue in 2.1.9

For no pinentry pop-up, I think that this is same cause described in the Issue 2112.
Please try the patch in T2112

I use several key of near all types: ed25519, rsa, dsa, ecdsa. All of them have
stopped working.

See T2106 for the SHA-256 feature.

I have not yet used that new ssh version. Will look into it soon to get the MD5
fingerprints replaced.

The MD5 bug has been fixed with commit 2167951:

• gcry_md_write (md, "384\0\0\0\x08nistp521", 15);

+ gcry_md_write (md, "384\0\0\0\x08nistp384", 15);

With recent versions of OpenSSH, the default fingerprint shown is uses SHA256.
The fingerprints emitted in sshcontrol are MD5. You can get ssh-keygen -l to
produce comparable MD5 fingerprints with "-E md5".

Perhaps the generated sshcontrol should also include the base64-encoded SHA256
fingerprints as well, though?

That still doesn't explain why ecdsa 384 keys are mis-fingerprinted, though.

This is still a problem with 2.1.8

I just backported the new ssh-agent code from master to the 2.0 branch. Thus
2.0.21 will have this support.

Would be great to have included if 2.1 is the ecc release.

I would love to just have 1 agent for everything.

There is no ECC support for the agent, yet. The ssh protocol is different from
the OpenPGP Protocol. It should be easy to add support, though.

Can't duplicate this problem.

Sorry, I can't replicate this using gnupg 1.9.92.
If you are still able to replicate it please create a test key and decribe
exacly what I have to do.

This was due to an out of secure memory condition.
To solve this I have increased the secure memmory poool to 32k, add better error
reporting as well as a simple check to detect keys greater that 4k.