Front page

Re: Encrypting with a local and a shared key

f1cb495f48d64859bd3b79e443797f31
UNWIND REVIVAL DECKHAND

From: Frederik Vanrenterghem <frederik@vanrenterghem.biz>
Date: Wed, 8 Jun 2016 21:28:57 +0800

   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA1
   
   Thanks Lars.
   
   I'm trying it again and can do
   
     obnam --keyid MY_LONG_KEY add-key
   
   but get the following error trying the next command:
   
     obnam --keyid MY_LONG_KEY add-key CLIENT
     Enter passphrase for key '/root/.ssh/id_rsa': 
     ERROR: R0C79EX: gpg failed with exit code 2:
     gpg: decryption failed: secret key not available
   
   (the first question is to enter the ssh key passphrase to log in to the
   backup repository).
   
   It would appear the secret key for the client would need to be stored
   centrally too?
   
   Best regards,
   Frederik
   - -- 
   Sent from my PC using Mutt
   -----BEGIN PGP SIGNATURE-----
   Version: GnuPG v1
   
   iQIcBAEBAgAGBQJXWB2ZAAoJECioQVZU6G8fqFEQAJgHnug+wx5cNjWa3aBuufI6
   rbXLdhyUT4COr9kALxM3mabGroLkvZ3xrTotaLl4wAz/fZLzKHNd2rk0EyhSmjd4
   u3f8KZMW8SWNK/1UcNtqkMlhoxspJ7zgf82x32ScIDifdDIrXCk5oquVywvWQizC
   UteaMsZmmFAPkd0zPs41Tq+3vX9EDuzZIUzDKsnFhEbh/felKcJpLCRl3ttjifFW
   q8CsMUHe63dCXJwuTyVR43kSotnMSnqGqzJmpHwbn8ZJKJSWBr+mMcdE9ytYHs80
   igq+yH/gMOAninuXKq9wL+JtPeEPAq6qRvNlD19q9ZessvbpMT6tgPgFfm9AlgFv
   9VrpNPMzE/7eS6BqL3jVcruX/Dkr2NgdHuv+g+RtFO7qVf/VXZOkU52yfEMOnBpt
   /jaDElH8NBTW+25fglUSiOilCiHpABQaapa1ManH1t+8xZUKXBiEqr3mKi+UUpt/
   bD3H62dEiKIDfPERHbZyGf4iegSpXxfuEFU47/v2z+fXqOPeKBDZWZKi9BjAvlnx
   hPisqfmSXj9JlM2MDS17DxfpWkWreh/Kze/DPik0gqvIMWliG6aPudLthwPpF5S/
   Op1sC/UJyGquXb/UTGgU46OMcMwrEFSTsJRKnD+Mn5zQo0ssQdUByPpLOV33k29Y
   z298dqamSrrIgtjwAlRM
   =JHSf
   -----END PGP SIGNATURE-----
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Lars Kruse <lists@sumpfralle.de>
Date: Thu, 9 Jun 2016 00:50:09 +0200

   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA256
   
   Hi Frederik,
   
   
   Am Wed, 8 Jun 2016 21:28:57 +0800
   schrieb Frederik Vanrenterghem <frederik@vanrenterghem.biz>:
   
   > but get the following error trying the next command:
   > 
   >   obnam --keyid MY_LONG_KEY add-key CLIENT
   >
   > [..]
   > 
   > It would appear the secret key for the client would need to be stored
   > centrally too?
   
   maybe I am questioning the obvious: can you access the client's repository
   in the environment above?
   
    obnam --client-name CLIENT ls
   
   Cheers,
   Lars
   -----BEGIN PGP SIGNATURE-----
   Version: GnuPG v2
   
   iQIcBAEBCAAGBQJXWKEhAAoJEFML9eRz0dWUg+4QAIy+0XXrVm3bZvgPXR1S8s2C
   faSbOfIyMYYHTTeknecTlzplClis36pGERb2fBNWOLzik/wSWfjOds3BuosvYd9e
   f81YSYyz5jScaydu4JQdmzOvH+0ZmxyLF25Pchi4oN2n8AA2Jgy/IxvxbXcrpNh8
   ShnkDJrgLLw8cFnKa1bQCSeZtC0BI5gejCgpVhVcgpZMKSIHmG1SBXlNEFs6GAX+
   utXQwYTVqWAIvQTcUUNA9x11EEeyNNOB3eRLa/06BYmJv5avK23twoYIpCaDUwzr
   R9WpHaDe+HmpI7IEOTfkz1//SDng8phVIB2Vlpt7cVVMlhpe4iyTdXNr0B+iyQ+l
   aFYY9CDRExM5yDOYYebL93LPCFpT83AnPfcu78dtZtKqyOIeJVIhdS1SDglgjP7B
   HJnspYCyc28fvswZF8DUSfcgoPwXVnTz08rOeptK0vY84bY56PsHyTHbPRIdU7vr
   3DrQ3jnJk1/Ltfc7pgeC87Fzx6HpHSsJ/Og8h/hYNXItwhzySIQD3ilCKIfpQR9x
   DaYCNvdUQHZVxzJoJmZVjfnpWM+2IHrK9ilbt+HDTbfd3QnBP+hCq+Tloci1VBxE
   W+DcpWr0smWV+ObXUArKA2QOeIh3J/XlvTHfMYz4H+3DZ+fCOSUfSIO3Pi3gHeEb
   pNMr1eNwP3VnJ4hvkMva
   =Bv4d
   -----END PGP SIGNATURE-----
From: Lars Kruse <lists@sumpfralle.de>
Date: Thu, 9 Jun 2016 05:08:45 +0200

   Hi Frederik,
   
   
   Am Thu, 9 Jun 2016 08:46:56 +0800
   schrieb Frederik Vanrenterghem <frederik@vanrenterghem.biz>:
   
   > [..] Why enable having 2 keys if you'll always need the first one
   > to be shared at least temporarily though.
   
   IIRC, in my setup I used the following approach for each backup client in
   combination with a global key (stored on the "recovery" node):
   1) client: create a key pair
   2) recovery node: add the public part of the client's key to the toplevel of
      the backup repository
   3) client: create the client's repository (e.g. backup the first generation)
   4) client: import the public part of the global key into the client's repository
   
   This process involved a bit of copying files around, but it made it possible
   that all keys gained appropriate permissions without any private part of a
   keypair leaving its host.
   
   Cheers,
   Lars
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Frederik Vanrenterghem <frederik@vanrenterghem.biz>
Date: Thu, 9 Jun 2016 08:46:56 +0800

   Hi Lars
   
   2016-06-09 6:50 GMT+08:00 Lars Kruse <lists@sumpfralle.de>:
   
   >
   > maybe I am questioning the obvious: can you access the client's repository
   > in the environment above?
   >
   >  obnam --client-name CLIENT ls
   >
   > I can't verify that command anymore as I've now been able to make things
   work, but the approach seems unconventional.
   
   I created a first client with encrypted backups using key 1. Next, I
   created a second client with key 2. Before that client could be created on
   the repository, I had to import secret key 1 in the keyring of client 2.
   Afterwards, I could remove it again.
   
   It seems at the same time intuitive and counter-intuitive. The repo is
   encrypted with key 1, so it could be expected needing key 1 to alter it
   from client 2. Why enable having 2 keys if you'll always need the first one
   to be shared at least temporarily though.
   
   Best regards,
   Frederik
From: Gary <gary@mups.co.uk>
Date: Thu, 9 Jun 2016 12:55:48 +0100

   On 09/06/16 01:46, Frederik Vanrenterghem wrote:
   > It seems at the same time intuitive and counter-intuitive. The repo is
   > encrypted with key 1, so it could be expected needing key 1 to alter it
   > from client 2. Why enable having 2 keys if you'll always need the first
   > one to be shared at least temporarily though.
   > 
   
   The way I do my backups is:
   
   Client "Laptop" where root user has the gpg/ssh keys needed to backup
   via obnam.
   
   Client "Desktop" where root user has a different gpg/ssh key needed to
   backup to obnam.
   
   As the backups occur via root and without user intervention, the gpg key
   needs to have no password (I don't want to have any users needing to
   unlock the root key when they log in/out/reboot machines) and since
   there's a risk of compromise of the root key, I use a unique one per
   machine.
   
   Likewise the ssh keys are passwordless, but can only be used to connect
   to a backup user running in a chroot on the server and due to each
   client root user having a different GPG key one machine is unable to
   access the decrypted backup data of another machine.
   
   I actually have each machine backing up to its own repo dir, but the
   same applies when all backup to one.
   
   Now, the problem with this setup is, when my laptop dies or is stolen,
   the only key that can decrypt the laptop client data is on the laptop.
   Likewise for the desktop and any other clients. So the solution is to
   give a second GPG key read access to both the obnam repo and each client
   within that repo.
   
   The only "people" who can access the repo at this time are the root
   users with their GPG keys, so you either have to copy the secret+public
   gpg key of the root user to the keyring of the user you wish to add
   (which imo is the wrong way to do it) OR
   
   As the root user, import the public key of the user you wish to add. In
   my case it's my regular GPG key I use to sign/encrypt emails. So the
   root user imports that public key (never has access to nor needs to have
   access to my secret key) into their keyring.
   
   Now you can run the obnam addkey command to add my user key to the repo,
   then run it again to grant that key access to the "laptop" client within
   the repo.
   
   The process is then repeated on each other client, root user imports my
   users public key and adds it to the "Desktop" client. It needs doing on
   each client because any given "root" user has a key that only grants
   access to their client data in the repo and not any other clients data.
   
   So, to summarize, the reason for two keys is at least in my case because
   I do not want to have my regular gpg key unprotected (without a
   password) on any machine I backup using obnam. At the same time I want
   to be able to restore any machines backup using my user key in the case
   of a machine crash/theft.
   
   Another use case for this would be that I could allow one specific
   machine, say "FamilyPC" to backup with a key that owner can use to
   backup/restore their data, yet I could also add my key as a fail safe
   admin key so I can access their data should they lose their GPG key.
   
   What you've done was imo mostly correct, the only change I'd make to
   your process is not to import key 1 into another users key ring in order
   to add key 2 to the repo as that requires key 1 private key exposure.
   Instead, add just the public key for key2 to the keyring/user that holds
   key1.
   
   Obnam only needs the public key to add access to the repo and the secret
   key then remains with the user who you've now given access. They never
   get your secret key, you never need to get theirs. (Even though in this
   case the owner of both keys may be yourself)
   
   A little long winded an explanation but hopefully it helps :)
   
   Regards,
   
   Gary
   
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Frederik Vanrenterghem <frederik@vanrenterghem.biz>
Date: Thu, 9 Jun 2016 21:46:19 +0800

   2016-06-09 19:55 GMT+08:00 Gary <gary@mups.co.uk>:
   
   > What you've done was imo mostly correct, the only change I'd make to
   > your process is not to import key 1 into another users key ring in order
   > to add key 2 to the repo as that requires key 1 private key exposure.
   > Instead, add just the public key for key2 to the keyring/user that holds
   > key1.
   >
   >
   Nice, that makes sense.
   
   Thx,
   Frederik