Thanks, now this works as expected for me :-)

Right, getkey_next had a somewhat surprising semantic. I fixed that with commit
b280aa6.

It also works with ECDSA keys.

Current master b2da3951 segfaults on me.
Btw. I think this is likely because i have a local ID without an Authentication
subkey for aheinecke@gnupg.org

(gdb) run --export-ssh-key aheinecke@gnupg.org
Starting program: /opt/gnupg/bin/gpg2 --export-ssh-key aheinecke@gnupg.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat

Program received signal SIGSEGV, Segmentation fault.
lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116

3116 *ret_keyblock = keyblock; /* Return the keyblock. */
(gdb) bt full
#0 lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116
    rc = 0
    no_suitable_key = 0
    keyblock = 0x0
    found_key = 0x701980

#1 0x0000000000415bb6 in getkey_next (ctx=0x6dd940, pk=0x0, ret_keyblock=0x0)
at ../../g10/getkey.c:1636

rc = <optimized out>
found_key = 0x0

#2 0x000000000045713a in export_ssh_key (ctrl=0x6dd810, userid=0x7fffffffe420
"aheinecke@gnupg.org") at ../../g10/export.c:1437

getkeyctx = 0x6dd940
keyblock = 0x6fd160
desc = {mode = KEYDB_SEARCH_MODE_SUBSTR, skipfnc = 0x0, skipfncvalue =

0x0, sn = 0x0, snlen = 0, u = {

name = 0x7fffffffe420 "aheinecke@gnupg.org", fpr = "

\344\377\377\377\177", '\000' <repeats 17 times>, kid = {

4294960160, 32767}, grip = " \344\377\377\377\177", '\000'

<repeats 13 times>}, exact = 0}

curtime = 1452288169
pk = 0x0
identifier = 0x6ddb80 ""
mb = {len = 0, size = 4096, buf = 0x6e5d70 "", out_of_core = 0}
fp = 0x6dd810
b64_state = {flags = 7199040, idx = 0, quad_count = -153676256, fp =

0x10, stream = 0x6dd800, title = 0x6ddb80 "",

radbuf = "\000\000\000", crc = 0, stop_seen = -1, invalid_encoding =

0, lasterr = 0}

fname = 0x7fffffffe420 "aheinecke@gnupg.org"

#3 0x000000000040dc00 in main (argc=1, argv=0x7fffffffdfe8) at ../../g10/gpg.c:4193

pargs = {argc = 0x7fffffffdb9c, argv = 0x7fffffffdb90, flags = 32769,

err = 0, r_opt = 0, r_type = 0, r = {ret_int = 0,

ret_long = 0, ret_ulong = 0, ret_str = 0x0}, internal = {idx = 2,

inarg = 0, stopped = 1,

last = 0x7fffffffe420 "aheinecke@gnupg.org", aliases = 0x0,

cur_alias = 0x0, iio_list = 0x0}}

a = 0x6dd800
orig_argc = 0
orig_argv = 0x6ddb80
fname = 0x7fffffffe420 "aheinecke@gnupg.org"
sl = 0x0
remusr = 0x6ddb40
locusr = 0x0
nrings = 0x0
afx = 0x7fffffffe420
configfp = 0x7fffffffe420
configlineno = 27
parse_debug = 7198720
cmd = aExportSshKey
malloc_hooks = {malloc = 0x405ee0 <gcry_malloc@plt>, realloc = 0x406d40

<gcry_realloc@plt>, free = 0x406290 <gcry_free@plt>}

ctrl = 0x6dd810

Done with commit 4970868 to be released with 2.1.11.
This uses a new command and not an export option so that export options can be
kept in the conf file.

ECDSA keys (NIST keys) do not yet work.

Right, this is what I actually had in mind. Using the "<keyid>!" notaion it
would also be possible to export any primary of subkey in ssh format.

That fingerprint looks more like gibberish than something which should be
compared by the user. In that regard a SHA-1 fingerprint looks much more
serious and IMHO will be more secure than a base-64 fingerprint where you have
to explain that the users also need to match the case - if they are at all able
to compare that fingerprint.

We should take this to the mailing list.

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.