rbidden
You are using a remote connection - that is your agent is running on
another machine via ssh forwarding of the local socket. For security
reasons certain commands are not allowed. Go to the machine where the
agent is running and run gpg-preset-passphrase over there.
See also https://wiki.
Hi there,
I'm having a hard time finding resources to help me troubleshoot the
following error
> gpg-preset-passphrase: problem setting the gpg-agent options
> gpg-preset-passphrase: caching passphrase failed: Forbidden
when I try to preset password via:
$ /usr/lib/gnupg2/gpg-preset
On Mon, Mar 27, 2023 at 5:58 AM Werner Koch wrote:
> You are right. I forgot about this.
>
> You need to wait for the next version or apply the attached patch and
> run gpg-preset-passphrase with the option --restricted to address the
> other cache.
>
Great, thanks for confir
hrase): Use option.
--
We use a different cache for connections from the extra-socket.
However, with gpg-preset-passphrase is only able to preset a
passphrase into the regular cache. Further, a restricted connection
may not use PRESET_PASSPHRASE. To solve this we add an new option to
pres
see some error
> message "Forbidden" when the remote site issues certain commands.
>
Thanks for the debugging tips. I collected more info using those. Caching
behavior does indeed seem to depend on connection type based on what I am
seeing in the logs:
Call to gpg-preset-passphrase for :
On Wed, 22 Mar 2023 16:16, xeyrion--- said:
> Forwarding normal socket (instead of extra socket) makes the prompt go
> away. Is there a way to preset passphrase for extra socket as well?
The caching behavior does not depend on the connection type. Thus this
should not be an issue. I assume you
Hello,
I am trying to set up agent forwarding as per
https://wiki.gnupg.org/AgentForwarding. Everything is generally working,
but the remote gpg is prompting for passphrases
despite gpg-preset-passphrase having been used against local agent.
Forwarding normal socket (instead of extra socket
I am trying to set up agent forwarding as per
https://wiki.gnupg.org/AgentForwarding. Everything is generally working,
but the remote gpg is prompting for passphrases
despite gpg-preset-passphrase having been used against local gpg agent.
Forwarding normal socket (instead of extra socket) makes
On 23/03/03 03:09PM, Ingo Klöcker wrote:
> On Freitag, 3. März 2023 13:09:09 CET efeizbudak via Gnupg-users wrote:
> > So I'm trying to use gpg-preset-passphrase but for some reason I keep
> > having to enter the passphrase all the same. I run
> >
> > /usr/libexe
On Freitag, 3. März 2023 13:09:09 CET efeizbudak via Gnupg-users wrote:
> So I'm trying to use gpg-preset-passphrase but for some reason I keep
> having to enter the passphrase all the same. I run
>
> /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP
Works for me (with the cu
Hi all,
So I'm trying to use gpg-preset-passphrase but for some reason I keep
having to enter the passphrase all the same. I run
/usr/libexec/gpg-preset-passphrase --preset $KEYGRIP
and then paste the passphrase (I've also tried this with the keygrip for
the [E] subkey as opposed
Dmitry Alexandrov wrote:
> Peter Lebbing wrote:
> > You can actually unlock keys the way GnuPG intends to do that with:
> >
> > $ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset
> >
> > You can find the keygrip for your keys with:
> >
>
Peter Lebbing wrote:
> You can actually unlock keys the way GnuPG intends to do that with:
>
> $ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset
>
> You can find the keygrip for your keys with:
>
> $ gpg --with-keygrip --list-secret-keys
>
> You do need i
ifically, using
> https://github.com/docker/docker-credential-helpers, with setup
> https://github.com/docker/docker-credential-helpers/issues/102#issuecomment-388634452.
>
> Steps:
> use gpg-preset-passphrase
> Current Setup
>
> * ~/.gnupg/gpg-agent.conf
> *
On 13/04/2019 14:34, Peter Lebbing wrote:
> Either reload the agent (this will make it forget all passphrases)
Of course I should have made that explicit. You reload the agent by:
$ gpgconf --reload gpg-agent
I should mention this before you start figuring out a way to send it
SIGHUP (which btw
27;re using something ancient that upstream doesn't support
and which has known defects? Is this a distribution-supported version?
If there is no security support from any party, I think you should
switch to a supported version.
> * Setup gpg-preset-passphrase
> o gpg-pres
setup
https://github.com/docker/docker-credential-helpers/issues/102#issuecomment-388634452.
Steps:
use gpg-preset-passphrase
Current Setup
* ~/.gnupg/gpg-agent.conf
* pinentry-program /usr/bin/pinentry-curses
* max-cache-ttl 6048
* default-cache-ttl 6048
Hello,
Very new to gpg. I’m attempting to use gpg-preset-passphrase. But uncertain
how to go about enabling it for usage. Could someone direct me or provide me
some instructions in how to go about enabling gpg-preset-passphrase?
I have the following version installed:
gpg --version
gpg
Hello,
Very new to gpg. I’m attempting to use gpg-preset-passphrase. But uncertain
how to go about enabling it for usage. Could someone direct me or provide me
some instructions in how to go about enabling gpg-preset-passphrase?
I have the following version installed:
gpg --version
gpg
It really was that simple! Thank you! I must have spent too many hours
staring at it to be able to see such a simple issue.
gpg-preset-passphrase is happy with a keygrip and works exactly as I want
it to.
Cheers!
On Thu, Aug 16, 2018 at 11:34 AM, Peter Lebbing
wrote:
> On 16/08/18 18
On 16/08/18 18:31, Peter Lebbing wrote:
> By the way, the GnuPG 2.1 in Ubuntu 16.04 hasn't been updated in almost
> two years. I don't feel comfortable with it, and I would consider
> alternatives.
s/two years/two and a half years/
It hasn't been updated since release. For a moment I was thinki
gpg-preset-passphrase wants a keygrip, not a key fingerprint. To get the
keygrip for a specific key, use f.e.:
--8<---cut here---start->8---
$ gpg --with-keygrip -k 211601B877A3395Apub rsa1024 2012-03-17 [SC] [expires:
2018
cifically to gpg 2.1+; most of what I've found (on the stackexchange
sites, forums, and mailing lists, etc) reference older versions of gpg,
especially where gpg-agent is concerned.
I execute gpg-preset-passphrase to the best of my understanding, but all
GPG tools still prompt me for a passp
On 02/02/18 12:23, Peter Lebbing wrote:
> Do this every time after starting the server/starting gpg-agent, to unlock
> the key:
>
> gpg-preset-passphrase --preset 15CB764B81D542CF921978CA89910C69D53F4E2D
>
> (Type in the password. Currently no pinentry support.)
It is
Hello :)
David Matthews writes:
> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The
> command appears to work successfully but the passphase is not found by
> GET_PASSPHRASE. I've included details of my simple test below plus the
> output from running it o
On 14 July 2016 at 07:29, David Matthews wrote:
> On 13 July 2016 at 13:13, Daniel Kahn Gillmor wrote:
>> Hi David--
>>
>> On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote:
>>> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7.
>>
>&g
On 13 July 2016 at 13:13, Daniel Kahn Gillmor wrote:
> Hi David--
>
> On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote:
>> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7.
>
> there have been significant changes to GnuPG between 2.1.7 and 2.1.13.
&g
I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The
command appears to work successfully but the passphase is not found by
GET_PASSPHRASE. I've included details of my simple test below plus the
output from running it on Centos 7.2 (where it works using 2.0.22) and
Fedora 23
Hi David--
On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote:
> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7.
there have been significant changes to GnuPG between 2.1.7 and 2.1.13.
can you try upgrading to 2.1.13?
I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The
command appears to work successfully but the passphase is not found by
GET_PASSPHRASE. I've included details of my simple test below plus the
output from running it on Centos 7.2 (where it works using 2.0.22) and
Fedora 23
Hi,
ubuntu-14.04.3 LTS
gnupg-1.4.16-1ubuntu2.3
gnupg2-2.0.22-3ubuntu1.3
gnupg-agent-2.0.22-3ubuntu1.3
I've just started using gpg-agent and gpg-preset-passphrase to store a
passphrase briefly.
Yesterday, this was working fine on two hosts.
Today, it stopped working on one of them.
Th
On Mon, 27 May 2013 14:02, mailinglis...@hauke-laging.de said:
> How is a passphrase with a cache id like foo:12346 used? Is it tried for all
> keys which do not have a keygrip entry?
No. It is used with the commands
GET_PASSPHRASE [--data] [--check] [--no-ask] [--repeat[=N]]
Hello,
I quote from the man page:
###
gpg-preset-passphrase [options] [command] cacheid
cacheid is either a 40 character keygrip of hexadecimal characters identifying
the key for which the passphrase should be set or cleared
K
Daniel Eggleston-2 wrote:
>
> I'm looking for some help explaining the behavior of
> gpg-preset-passphrase.
>
> First, the manpage states:
>
>Passphrases set with this utility don't expire unless the
> --forget
>option is used to explicit
I'm looking for some help explaining the behavior of gpg-preset-passphrase.
First, the manpage states:
Passphrases set with this utility don't expire unless the
--forget
option is used to explicitly clear them from the cache --- or
gpg-agent
is either re
Greetings gnupg-users,
I'm trying to seed gnupg-agent using the not-so-majikal
gpg-preset-passphrase tool. Emphasis on *trying* - it's not working atm
(yet?) All the gory details follow bellow, but in a nutshell, this is
what I think is happening:
* use of gpg-preset-passphrase re
36 matches
Mail list logo
