Identifying one of multiple authentication subkeys

[Shweta Tyagi]

Hi All,

I am using the following command

gpg --batch --passphrase-fd n and it stops popup which asks for the
passphrase. but when I run this command on window server 12 it's not
working its always show popup for the passphrase. can someone please help
me how can I stop popup on window server 12.



Shweta Tyagi  Netsuite Technical Consultant
Upaya - The Solution Inc
p: 408-868-4477
w: www.upayasolution.com e: shweta at upayasolution.com
s: shweta.tyagi97
a: 4320 Stevens Creek Blvd Suite # 124, San Jose, CA 95129
    <https://www.facebook.com/pages/Upaya-The-Solution-Inc/155447161187023>
   <https://twitter.com/upayasolution>
<https://www.linkedin.com/company/upaya---the-solution-inc.>
<https://plus.google.com/105509154382272912137>
<https://www.instagram.com/upayasolution/>





On Tue, Mar 26, 2019 at 4:22 PM Peter Lebbing <peter at digitalbrains.com>
wrote:

> On 26/03/2019 09:16, Werner Koch wrote:
> > This lists all keys allowed for ssh with its keygrip (1234. and the
> > corresponding ssh fingerprint (SHA256:PTJI).  Details as usual by using
> > 'help keyinfo'.
>
> Right, yes, the comment lines in sshcontrol are also really helpful for
> keys in sshcontrol.
>
> I should have been more explicit about my weird edge case.
>
> I use OpenPGP cards with a key in the authentication slot which is not
> part of any OpenPGP certificate, and is not in sshcontrol. gpg-agent is
> fine with this: if I have the card inserted, it will be offered as an
> authentication key to SSH servers. If I don't have the card inserted, it
> is not offered. This in contrast to the case where you were to add it to
> sshcontrol: then it would /ask/ for the card to be inserted if the
> server accepts the key. If it is not in sshcontrol, it will not be
> offered for SSH authentication.
>
> In this particular case, it is actually very easy to pick the correct
> SSH public key, because gpg-agent will add the comment "cardno:XXX",
> where XXX is the serial number of the card, to the public key when you
> do ssh-add -l or -L.
>
> It is more difficult to find the keygrip, though. While participating in
> this thread, I worked from the assumption that the key, for whatever
> reason, was not in sshcontrol, to catch edge cases such as this. I don't
> know whether there are other edge cases than this specific one where SSH
> keys are not in sshcontrol, though. This might be the only one.
>
> The use case I considered is this: I have a card I use on two PC's, but
> one of the PC's also has an on-disk SSH key. Some SSH accounts will only
> accept the card for authentication, but there are accounts which accept
> either key. If I'm on the machine with the on-disk key and my card is
> not inserted, it will pick the on-disk key. If I'm on the PC without
> the on-disk key, I cannot log in to that account without inserting the
> card.
>
> If the card were in sshcontrol, and it were offered before the on-disk
> key, I would be prompted to insert the card. But this would be
> unnecessary, since I have an on-disk key that will do the job just as
> well.
>
> But I have to say I no longer actually use this scenario :-). I did in
> the past, though.
>
> What would actually help in this use case, might be to have
> --card-status accept a --with-keygrip option. Then you have the
> "cardno:XXX" comment in ssh-add to pick the public key or its
> fingerprint, and --card-status to find the keygrip.
>
> > (I don't like the base64 encoding becuase it is hard to visual compare,
> > but that is how it is)
>
> Yes, I totally agree. And when matching stuff together like we do in
> this thread, we don't actually use any cryptographic properties of the
> fingerprint, there is no adversary. So MD5 might be easier on the eyes,
> but it has the disadvantage that the user needs to be /aware/ that they
> can get the same fingerprint format from ssh-keygen, ssh-add and
> gpg-agent.  If they just see one format here and another there, they
> might very well not realise they can be made to match.
>
> So I'm inclined to think the default should be to output it in the same
> format in both tools.
>
> Plus, when it's purely for identification purposes, you can skip reading
> more letters of the base64 encoding once you've identified the right
> key.
>
> > I fixed that for 2.2.15 so that the above option is considered.
> > Further, it is also possible to use
>
> Neat! Thanks!
>
> > p.s.  Eventually someone(tm) should write a GUI tool to list and manage
> > all kind of private keys in GnuPG.  For example to list all users of a
> > certain private key.
>
> :-)
>
> Sorry for the long mail. I didn't see a lot of opportunity to shorten it
> without losing clarity. If I were to introduce a misunderstanding, it
> will only take even more time to sort out.
>
> Cheers,
>
> Peter.
>
> --
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190326/9077ec98/attachment.html>