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: shw...@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 <pe...@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@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users