> From: Peter Lebbing [mailto:pe...@digitalbrains.com] > > On 25/08/17 16:08, Fiedler Roman wrote: > > I tried to use the agent support that way. One reason for low adoption > > might > > be, that using the provided documentation, it is just not possible to get > > a > > simple batch scenario working on Ubuntu 16.04 server setups without > > spending a > > whole day and debugging into the sources. > > Could you explain further what you are trying to accomplish?
The goal is to find a solution to decrypt numerous large, encrypted storage elements with a procedure, hopefully so simple, that it can be written in a SOP for execution by any Linux-admin with appropriate permissions without need to understand GPG, fight with different GPG versions on different machines, ... The problem is: 1) the encrypted elements are on a storage (trust zone A), where access to the private key is forbidden by policy 2) the elements are too large to copy them to the admin machine, where the private key is (trust zone B) 3) the elements are used on target machines with different GPG versions (some in a trust zone C, where the admin having access to the key does not have access to the machine, where decryption could occur) Idea: 1) Extract all GPG preambles of files to be decrypted to a single file (working) 2) Batch decrypt all preambles from the input file on the trusted equipment (not working in batch mode) 3) Decrypt all storage elements with the list of session keys (working) > "Batch scenario" suggests to me: the human user is not logged in. Not really for step 1, 3 - at least those steps do not require interactivity > "GnuPG agent forwarding" suggests to me: the human user is logged in > through SSH. For step 2 yes. But SSH connection, agent and session key extraction seem not to play together well on Ubuntu 16.04 Best regards, Roman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
