Mailing List Archive: Forward entire gnupg $HOME

Forward entire gnupg $HOME

Sep 4, 2019, 1:41 PM

Post #1 of 7 (993 views)

Hi all,

is there a way to properly shared the entire keyring and trust settings
between two machines?

My use case is the following:

Mutt, my email client, runs on a containerized mailserver on another machine
right under my desk.

My GPG key is stored on a Yubikey attached to my workstation (another
physical machine compared to the mailserver's host system)

I usually use my workstation to do everything, but since I can't access my
mailbox via NFS anymore (different story), I resorted to sshing into my
email server, and doing all the mailing needs right there, locally.

My Yubikey also is used as the SSH key for everything, and hence plugged
into my workstation.

After following https://wiki.gnupg.org/AgentForwarding and batteling with
the autostarting gpg-agent (fixed with no-autostart in the remote system's
gpg.conf), masking all but the dirmngr systemd socket and service units, and
struggeling with the removal of /run/user/1000/gnupg on logout, I finally
got it to work. (Nice how the last one doesn't matter, if dirmngr.socket is
enabled.)

Now I have another problem: my main machine knows all my internet friend's
keys, my mailserver not. I can of cause gpg --export, scp and gpg --import,
but that is nothing scalable and needs to be repeated over and over again
when anything changes.

Do I expect to much, or is this simply and typically invalid usecase?
Is there a simpler way to configure a remote GPG just for a session, so
that it uses another socket to connect to the gpg-agent (I also sign git
commits, sometimes with etckeeper even on remote machines).

Thanks a lot for reading, and best regards,
Andre

--
Andre Kl?rner

Re: Forward entire gnupg $HOME [ In reply to ]

johndoe65534 at mail

Sep 4, 2019, 11:59 PM

Post #2 of 7 (993 views)

Permalink

On 9/4/2019 10:41 PM, Andre Kl?rner wrote:
> Hi all,
>
> is there a way to properly shared the entire keyring and trust settings
> between two machines?
>
> My use case is the following:
>
> Mutt, my email client, runs on a containerized mailserver on another machine
> right under my desk.
>
> My GPG key is stored on a Yubikey attached to my workstation (another
> physical machine compared to the mailserver's host system)
>
> I usually use my workstation to do everything, but since I can't access my
> mailbox via NFS anymore (different story), I resorted to sshing into my
> email server, and doing all the mailing needs right there, locally.
>
> My Yubikey also is used as the SSH key for everything, and hence plugged
> into my workstation.
>
> After following https://wiki.gnupg.org/AgentForwarding and batteling with
> the autostarting gpg-agent (fixed with no-autostart in the remote system's
> gpg.conf), masking all but the dirmngr systemd socket and service units, and
> struggeling with the removal of /run/user/1000/gnupg on logout, I finally
> got it to work. (Nice how the last one doesn't matter, if dirmngr.socket is
> enabled.)
>
> Now I have another problem: my main machine knows all my internet friend's
> keys, my mailserver not. I can of cause gpg --export, scp and gpg --import,
> but that is nothing scalable and needs to be repeated over and over again
> when anything changes.
>
> Do I expect to much, or is this simply and typically invalid usecase?
> Is there a simpler way to configure a remote GPG just for a session, so
> that it uses another socket to connect to the gpg-agent (I also sign git
> commits, sometimes with etckeeper even on remote machines).
>

The obvious solution would be to use mutt on your work station! :)
I would also use one signing key per device on which you need to sign
commits/tags/...
That way if one device is compromised you simply revoke that subkey.

Sorry for not directly answering your question!

--
John Doe

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Forward entire gnupg $HOME [ In reply to ]

gnupg-users at gnupg

Sep 5, 2019, 12:16 AM

Post #3 of 7 (993 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, 5 Sep 2019, john doe wrote:

> On 9/4/2019 10:41 PM, Andre Kl?rner wrote:
>> Hi all,
>>
>> is there a way to properly shared the entire keyring and trust settings
>> between two machines?

[ snip ]

> The obvious solution would be to use mutt on your work station! :)
> I would also use one signing key per device on which you need to sign
> commits/tags/...
> That way if one device is compromised you simply revoke that subkey.

While this would work for signing, it will not work for decryption.

regards,
Erich
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl1wtmgACgkQCu7JB1Xa
e1o06A//QjHAhXVhjtQCqPrWIvOySXHZh7ISrzqN/Zs9XyhK6U4Zul698pr4FQKr
mj0R25EkwN8Xsqqneg+ZS7mwDPrp2RBqymlOifYGt4/xYHdoL18rwHDxwZ1ZiEk8
BNuZspl7h4Ka5mcGZT7ajFKT3+NiTZiq0TH9itanI6WBfg+H44oQb7HBVvsDuJeX
MGZGwUXsby6Q+lMB5KcHa+6FJVaRBAzLaOn0UjJ3ce/h9OOxPMCTPdgfE/14+Zez
0UGLyEGfe1qL2Fl8Gnq+LvB3f0hchE4fqd5F6fMOMqSByLi6lxsPveFdYMGT81Rt
sWzBPStMcQaHjdCI61egBCXj+Hd8h7PciyHvjGYJlFSz2/dAN+omlHgrujW7Ic81
Phkc7QPRq80983ee4dKJWdlKAkOaaURN30m/K/m1w1CQ4Mjza4lc+kBypJly7qVr
UtAptrDXl2awsx6mpK/ekp501db2suy7+4Y6X8TUArJbZVCL0EyZz8nIgCkJembx
Ye9EnofX5gbkFTkOol2u0i90K9ANnvhN8jjYuKJLqMk6RHE7SJM9LpOBDZzGtvc+
/t6hRrP60fOW3Z+SkhlzdWtGnfc5Dk40FTeeSY9UZzwNGT8J+2090yq/5MGOUq3q
DvX4TW5g6w0vkwCdRU5qrGBi/qU/SNJHwRWq8KiymkTQMXFbgaQ=
=dDKv
-----END PGP SIGNATURE-----

Re: Forward entire gnupg $HOME [ In reply to ]

kandre at ak-online

Sep 5, 2019, 5:36 AM

Post #4 of 7 (993 views)

Permalink

Hi all,

On Thu 05.09.2019 09:16:54, Erich Eckner via Gnupg-users wrote:
> On Thu, 5 Sep 2019, john doe wrote:
>
> > On 9/4/2019 10:41 PM, Andre Kl?rner wrote:
> >> Hi all,
> >>
> >> is there a way to properly shared the entire keyring and trust settings
> >> between two machines?
>
> [ snip ]
>
> > The obvious solution would be to use mutt on your work station! :)
> > I would also use one signing key per device on which you need to sign
> > commits/tags/...
> > That way if one device is compromised you simply revoke that subkey.
>
> While this would work for signing, it will not work for decryption.

It also would contradict my security model: there are exactly three copies
of my private key: one in my Yubikey 5 NFC, one in my Yubikey 5 nano, one
in my OpenPGP smartcard. There are no other keys at all.

And unless I actively use one of them, they are all offline and not usable.
The Yubikeys even go a step further: even plugged in and with my PIN used
once they are not usable, unless someone is physically present to confirm
the operation by touching them.

Especially the last part is the main reason I was drawn to Yubikeys: our
company uses SSH extensively, and due to Audit restrictions
SSHAgentForwarding must be enabled so that the audit box can log all SSH
plaintext traffic. But once I am logged on to one of our servers I have
root access as many of our colleagues - so a knowledgable person easily can
reuse my agent for anything else. With a physical confirmation required
this is no longer a problem.

So I hope you now know how my requirements came to be, and that simply
using multiple subkeys doesn't scale. The only thing saving my is proper
and secure forwarding.

Thanks and best regards,
Andre

--
Andre Kl?rner

Re: Forward entire gnupg $HOME [ In reply to ]

abbot at monksofcool

Sep 5, 2019, 11:06 AM

Post #5 of 7 (989 views)

Permalink

* Andre Klärner:

> is there a way to properly shared the entire keyring and trust
> settings between two machines?

What "properly" means is quite subjective.

My own .gnupg directories are under Git control. Imagine two computers,
let's call them alpha and bravo, in my local network, which both only
allow access via SSH key based authentication. Assuming that alpha is
the "master" (meaning I add keys and modify trust settings there), I can
initially transfer the data by running

cd /home/ralph
git clone ralph@alpha:/home/ralph/.gnupg

on machine bravo. All future updates can then be transferred by simply
invoking "git pull".

For obvious reasons one should not put GnuPG key material on GitHub or
similar, but if you do have your own, secure Git repository (which I
have), you can add that to the mix.

A nice side effect of this method is that my GPG key rings are fully
version controlled.

-Ralph

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Forward entire gnupg $HOME [ In reply to ]

angel at pgp

Sep 9, 2019, 2:39 PM

Post #6 of 7 (987 views)

Permalink

On 2019-09-05 at 08:59 +0200, john doe wrote:
> On 9/4/2019 10:41 PM, Andre Kl?rner wrote:
> > I usually use my workstation to do everything, but since I can't access my
> > mailbox via NFS anymore (different story), I resorted to sshing into my
> > email server, and doing all the mailing needs right there, locally.
(...)
>
> The obvious solution would be to use mutt on your work station! :)

Using mutt locally seems much simpler than forcing gnupg to work that
way.
You mention that you can no longer access your mailbox via nfs, but
since you can ssh to the email server, maybe you could mount it with
sshfs?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Forward entire gnupg $HOME [ In reply to ]

brian at minton

Jan 8, 2020, 5:54 AM

Post #7 of 7 (955 views)

Permalink

On Mon, Sep 09, 2019 at 11:39:01PM +0200, ?ngel wrote:
> On 2019-09-05 at 08:59 +0200, john doe wrote:
> > On 9/4/2019 10:41 PM, Andre Kl?rner wrote:
> > > I usually use my workstation to do everything, but since I can't
> > > access my mailbox via NFS anymore (different story), I resorted to
> > > sshing into my email server, and doing all the mailing needs right
> > > there, locally.
> (...)
> >
> > The obvious solution would be to use mutt on your work station! :)
>
> Using mutt locally seems much simpler than forcing gnupg to work that
> way. You mention that you can no longer access your mailbox via nfs,
> but since you can ssh to the email server, maybe you could mount it
> with sshfs?

There are some problems with sshfs, however, such as slowness and
locking. It would probably be better to run an imap daemon on your mail
server, and have mutt use imap to access the mailbox.

Mailing List Archive

Attached Files:

Attached Files:

Attached Files: