[Pkg-privacy-maintainers] Bug#928684: Bug#928684: monkeysphere-host import-key broken due to ssh-keygen change

[Daniel Kahn Gillmor]

Control: unarchive 909700
Control: forcemerge 909700 928684
Control: severity 909700 grave

Hi Andrei--

On Wed 2019-05-08 20:45:24 +0000, Andrei Morgan wrote:
> # monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://server.example.net
> RSA.xs:194: OpenSSL error: no start line at /usr/bin/pem2openpgp line 1106, <STDIN> line 1.
> gpg: no valid OpenPGP data found.
> #
>
> it appears that ssh-keygen is now producing -----BEGIN OPENSSH PRIVATE KEY-----
> headers which has lead to this no longer working. I believe it used to say
> -----BEGIN RSA PRIVATE KEY----- instead.

Thanks for this report.  I'm not sure that a11y is an appropriate tag
for this, since there is no specific accessibility concern here (see
https://wiki.debian.org/accessibility), so i've removed that tag.

I can confirm this behavior on a debian buster system and on a debian
unstable system.  It makes the "monkeysphere-host import-key" subcommand
fail.

This looks like it's the same issue as #909700, which was "fixed" only
by changing the test suite to force creation of PEM files, which is why
it was not caught earlier, sigh.

So i'm merging this bug with the earlier 909700 and merging it and
elevating the severity, since it has an effect on a newly-installed
buster system.

As a workaround, if you don't care about the existing RSA hostkey on
your server, you can just re-generate it with:

     rm -f /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub
     ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key

First step to a fix to the package is probably to "unfix" the test
suite, to have it use the default key generation (you can follow it in
/var/lib/dpkg/info/openssh-server.postinst).

The correct fix is probably to rewrite "monkeysphere-host import-key" to
avoid using keytrans.  I think (though i haven't done the work yet) this
can be done most flexibly for future reliability by rigging together
OpenSSH's key management tools with GnuPG's key management tools.

so something like this, which i haven't gotten to work fully yet:

 a) make an ephemeral GNUPGHOME directory, with "batch" in gpg-agent.conf
 
 b) launch gpg-agent in it, using gpconf --launch
 
 c) use ssh-add to import the secret key into gpg-agent's ssh-agent
    emulation using SSH_AUTH_SOCK=$(gpgconf --list-dir agent-ssh-socket)
    (gpg-agent.conf's "batch" suppresses gpg-agent's attempt to set a
    passphrase on the key during import).

 d) learn the associated keygrip from $GNUPGHOME/sshcontrol or
    $GNUPGHOME/private-keys-v1.d/

 e) ask gpg --batch --full-generate-key to craft an openpgp certificate
    based on that existing key. this appears to be something like:

Key-Type: RSA
Key-Grip: $KEYGRIP
Key-Usage: auth
Name-Real: ssh://$HOSTNAME
Expires: $EXPIRY
%no-protection
%commit

 f) export the secret key material in OpenPGP format (i'm running into
    trouble here as i try to test this)

Alternately, perhaps we could do a-e above directly in
/var/lib/monkeysphere/host, then we don't have to worry about the export
and might be able to still use the key.

The main differences from the current implementation here are:

 * this might allow us to handle non-RSA host keys, which is kind of
   nice

 * the generated certificate has certification capability (since gpg
   doesn't allow you to generate an OpenPGP certificate without that key
   usage flag set on the primary key)

Thanks for the report!

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20190508/a95850f5/attachment.sig>