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
signature.asc
Description: PGP signature
