Duplicity restore failing: No secret key
up vote
4
down vote
favorite
I'm setting up a backup from a local machine to a remote server.
I generated gpg keys on the local machine and ran a test backup with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
The backup seems to work fine, three files are created on the server.
My problem is I can't get the restore to work.
I deleted the test file on the local machine and try to restore it with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
I get the following error:
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====
I exported the gpg keys on the local machine with:gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
And imported them on the server with:gpg --import secret.key
gpg --import public.key
Is there anything else that needs to be done for the restore to work?
Edit:
If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path
the backup is created anyway without asking for the passphrase.
Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
backup encryption gnupg duplicity
add a comment |
up vote
4
down vote
favorite
I'm setting up a backup from a local machine to a remote server.
I generated gpg keys on the local machine and ran a test backup with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
The backup seems to work fine, three files are created on the server.
My problem is I can't get the restore to work.
I deleted the test file on the local machine and try to restore it with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
I get the following error:
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====
I exported the gpg keys on the local machine with:gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
And imported them on the server with:gpg --import secret.key
gpg --import public.key
Is there anything else that needs to be done for the restore to work?
Edit:
If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path
the backup is created anyway without asking for the passphrase.
Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
backup encryption gnupg duplicity
Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32
There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10
Could be related to this. In short: Somehowgpg
fails to ask for the passphrase.
– Daniel B
Oct 11 '15 at 12:17
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I'm setting up a backup from a local machine to a remote server.
I generated gpg keys on the local machine and ran a test backup with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
The backup seems to work fine, three files are created on the server.
My problem is I can't get the restore to work.
I deleted the test file on the local machine and try to restore it with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
I get the following error:
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====
I exported the gpg keys on the local machine with:gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
And imported them on the server with:gpg --import secret.key
gpg --import public.key
Is there anything else that needs to be done for the restore to work?
Edit:
If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path
the backup is created anyway without asking for the passphrase.
Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
backup encryption gnupg duplicity
I'm setting up a backup from a local machine to a remote server.
I generated gpg keys on the local machine and ran a test backup with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
The backup seems to work fine, three files are created on the server.
My problem is I can't get the restore to work.
I deleted the test file on the local machine and try to restore it with:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
I get the following error:
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====
I exported the gpg keys on the local machine with:gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
And imported them on the server with:gpg --import secret.key
gpg --import public.key
Is there anything else that needs to be done for the restore to work?
Edit:
If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path
the backup is created anyway without asking for the passphrase.
Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
backup encryption gnupg duplicity
backup encryption gnupg duplicity
edited Oct 11 '15 at 12:09
asked Oct 11 '15 at 2:00
Pabi
16119
16119
Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32
There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10
Could be related to this. In short: Somehowgpg
fails to ask for the passphrase.
– Daniel B
Oct 11 '15 at 12:17
add a comment |
Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32
There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10
Could be related to this. In short: Somehowgpg
fails to ask for the passphrase.
– Daniel B
Oct 11 '15 at 12:17
Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32
Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32
There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10
There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10
Could be related to this. In short: Somehow
gpg
fails to ask for the passphrase.– Daniel B
Oct 11 '15 at 12:17
Could be related to this. In short: Somehow
gpg
fails to ask for the passphrase.– Daniel B
Oct 11 '15 at 12:17
add a comment |
3 Answers
3
active
oldest
votes
up vote
3
down vote
accepted
The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.
The gpg agents needs to be enabled and configured for the restore to work.
Add the following to ~/.gnupg/gpg.conf
:
use-agent
pinentry-mode loopback
And to your ~/gnupg/gpg-agent.conf
:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Then restart the agent with echo RELOADAGENT | gpg-connect-agent
.
The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.
2
The second filepath is missing the dot. It should be~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40
add a comment |
up vote
1
down vote
Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.
I am using gpg 2.1.8. If I run it without the passphrase env:duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59
After doing that the output offile duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09
add a comment |
up vote
1
down vote
I have had this issue when using sudo
to execute duplicity
, which makes it search for the private key into root
's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.
The most simple solution to this problem was to avoid using sudo
, in my case, by setting the correct permissions on the destination directory.
If sudo
is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg"
to the duplicity command, as stated on this answer
Maybe this helps someone else :-)
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
1
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.
The gpg agents needs to be enabled and configured for the restore to work.
Add the following to ~/.gnupg/gpg.conf
:
use-agent
pinentry-mode loopback
And to your ~/gnupg/gpg-agent.conf
:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Then restart the agent with echo RELOADAGENT | gpg-connect-agent
.
The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.
2
The second filepath is missing the dot. It should be~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40
add a comment |
up vote
3
down vote
accepted
The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.
The gpg agents needs to be enabled and configured for the restore to work.
Add the following to ~/.gnupg/gpg.conf
:
use-agent
pinentry-mode loopback
And to your ~/gnupg/gpg-agent.conf
:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Then restart the agent with echo RELOADAGENT | gpg-connect-agent
.
The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.
2
The second filepath is missing the dot. It should be~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.
The gpg agents needs to be enabled and configured for the restore to work.
Add the following to ~/.gnupg/gpg.conf
:
use-agent
pinentry-mode loopback
And to your ~/gnupg/gpg-agent.conf
:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Then restart the agent with echo RELOADAGENT | gpg-connect-agent
.
The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.
The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.
The gpg agents needs to be enabled and configured for the restore to work.
Add the following to ~/.gnupg/gpg.conf
:
use-agent
pinentry-mode loopback
And to your ~/gnupg/gpg-agent.conf
:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Then restart the agent with echo RELOADAGENT | gpg-connect-agent
.
The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.
answered Oct 11 '15 at 14:11
Pabi
16119
16119
2
The second filepath is missing the dot. It should be~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40
add a comment |
2
The second filepath is missing the dot. It should be~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40
2
2
The second filepath is missing the dot. It should be
~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).– Sam
Oct 23 at 10:40
The second filepath is missing the dot. It should be
~/.gnupg/gpg-agent.conf
(same directory as the previously mentioned file).– Sam
Oct 23 at 10:40
add a comment |
up vote
1
down vote
Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.
I am using gpg 2.1.8. If I run it without the passphrase env:duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59
After doing that the output offile duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09
add a comment |
up vote
1
down vote
Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.
I am using gpg 2.1.8. If I run it without the passphrase env:duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59
After doing that the output offile duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09
add a comment |
up vote
1
down vote
up vote
1
down vote
Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.
Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.
edited Oct 11 '15 at 16:40
Thomas Weinbrenner
715717
715717
answered Oct 11 '15 at 11:13
ede
25112
25112
I am using gpg 2.1.8. If I run it without the passphrase env:duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59
After doing that the output offile duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09
add a comment |
I am using gpg 2.1.8. If I run it without the passphrase env:duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59
After doing that the output offile duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09
I am using gpg 2.1.8. If I run it without the passphrase env:
duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.– Pabi
Oct 11 '15 at 11:59
I am using gpg 2.1.8. If I run it without the passphrase env:
duplicity --encrypt-key KeyID test scp://user@host/path
it does not ask for the passphrase but the backup is created anyway.– Pabi
Oct 11 '15 at 11:59
After doing that the output of
file duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.– Pabi
Oct 11 '15 at 12:09
After doing that the output of
file duplicity-full.20151011T115714Z.vol1.difftar.gpg
lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.– Pabi
Oct 11 '15 at 12:09
add a comment |
up vote
1
down vote
I have had this issue when using sudo
to execute duplicity
, which makes it search for the private key into root
's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.
The most simple solution to this problem was to avoid using sudo
, in my case, by setting the correct permissions on the destination directory.
If sudo
is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg"
to the duplicity command, as stated on this answer
Maybe this helps someone else :-)
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
1
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
add a comment |
up vote
1
down vote
I have had this issue when using sudo
to execute duplicity
, which makes it search for the private key into root
's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.
The most simple solution to this problem was to avoid using sudo
, in my case, by setting the correct permissions on the destination directory.
If sudo
is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg"
to the duplicity command, as stated on this answer
Maybe this helps someone else :-)
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
1
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
add a comment |
up vote
1
down vote
up vote
1
down vote
I have had this issue when using sudo
to execute duplicity
, which makes it search for the private key into root
's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.
The most simple solution to this problem was to avoid using sudo
, in my case, by setting the correct permissions on the destination directory.
If sudo
is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg"
to the duplicity command, as stated on this answer
Maybe this helps someone else :-)
I have had this issue when using sudo
to execute duplicity
, which makes it search for the private key into root
's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.
The most simple solution to this problem was to avoid using sudo
, in my case, by setting the correct permissions on the destination directory.
If sudo
is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg"
to the duplicity command, as stated on this answer
Maybe this helps someone else :-)
edited Jul 18 '17 at 20:18
answered Jul 18 '17 at 18:52
Pablo
1115
1115
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
1
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
add a comment |
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
1
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21
1
1
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f984977%2fduplicity-restore-failing-no-secret-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32
There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10
Could be related to this. In short: Somehow
gpg
fails to ask for the passphrase.– Daniel B
Oct 11 '15 at 12:17