Felix Koop <[email protected]> writes: > > The photo actually does contain *some* more information about the error, > > but it is not very helpful: > > > > Trying to decrypt OpenPGP data > > bad gpgme_op_decrypt: GPGME: Decryption failed > > Unsupported algorithm: (null) > > Wrong key usage: 0 > > Public key algorithm: RSA > > Key ID: F8118489CABEB18B > > Secret key available: Yes
I've done some searching, and it seems that this error can, due to a bug <https://bugs.gnupg.org/gnupg/issue1020> also be reported when the private key is not available. However, I'm not sure how this could be the case here, since the client should abort if it failed to import the private key from the seckey.txt file. > > So I'm guessing that the key ID for the client is F8118489CABEB18B? > > This should be what the fingerprint should end with in the > > client.conf file on the server, at least. > > That was not the case. But when trying to fix the problem I upgraded > the mandos-client package to the testing version. To have again a > clean system, I purged everything related to mandos and reinstalled. I > get the same error (photo attached, other key ID, of course). The Key > ID on the photo B76C46544768EBD7 is different from what I have as > fingerprint in the client.conf file (content also deleted and newly > generated configuration inserted): > > fingerprint = 7BB742A419FA7D4436BC68E5AB68E8FF70C4627B Is the key in the error message possibly the subkey ID? I don't know. Even if it was, I don't know how it would help. > If that matters: The server is an ubuntu wily system with mandos > 1.7.0-1. We always recommend using the latest released version of Mandos, but I can see no change which would fix this bug in any later version. > New listing attached. Nothing new there, except you seem to have switched from Mandos 1.7.2 or later to 1.7.1 or earlier, and from Debian unstable to stable. > > > > 3. Boot your system with the additional kernel command line > > > > argument "break". This will start an emergency shell. > > > > First, run the command > > > > > > > > chmod a=rwxt /tmp > > > > > > > > Then you should be able to run the /lib/mandos/plugin-runner > > > > program, and by running the command multiple times you should > > > > be able to debug the problem. Also, the output of the > > > > "gpgconf" command in this mode should be informative, > > > > especially compared to its output when run in the normal > > > > system. > > > > > > I don't get the emergency shell, but a kernel panic instead. Then > > > the system reboots. This continues. > > > > Right. I suggest you take that up with the initramfs-tools > > maintainer. I think this is the only way forward - find out why it doesn't work in the initramfs by actually debugging it interactively in the initramfs. You could try one of these kernel command line parameters (listed in order of preference) instead of simple "break": break=mount break=premount break=modules break=top > > Can you reproduce the problem by unpacking the initramfs (as above), > > chrooting into it, and running the mandos-client from inside it? > > Done: > > Mandos plugin mandos-client: Trying to decrypt OpenPGP data > Mandos plugin mandos-client: Decryption of OpenPGP data succeeded > Mandos plugin mandos-client: Decrypted password is: <password in hex> […] > <password> > > So there it is, the correct password. Everything seems to run fine in > the chroot. > > Any idea what else to check? The only way to even reproduce the problem seems to run in the actual initramfs environment. When you try to enter an interactive shell in that environment, you get a kernel panic. This could be an indication of a larger problem with your initramfs environment, and since we can't even reproduce the problem outside this environment, I don't know what else to do at this point. I would try to fiddle with it to get an emergency initramfs shell to work - it seems to be the only alternative at this point. /Teddy Hogeborn -- The Mandos Project https://www.recompile.se/mandos
signature.asc
Description: PGP signature
