Re: 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: shw...@upayasolution.com
s: shweta.tyagi97
a: 4320 Stevens Creek Blvd Suite # 124, San Jose, CA 95129

   








On Tue, Mar 26, 2019 at 4:22 PM Peter Lebbing 
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 
>
> 

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Werner Koch]

On Mon, 25 Mar 2019 16:02, pe...@digitalbrains.com said:

> But something more user friendly to match SSH fingerprint and keygrip
> could be beneficial. I'm not sure what that would look like and neither

You can build a script based on this:

  $ gpg-connect-agent 'keyinfo --ssh-list --ssh-fpr' /bye
  S KEYINFO 1234[...] D - - - P SHA256:PtJi[...] - S
  [...]

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'.

> For one thing, OpenSSH seems to prefer SHA256 SSH fingerprints over the
> old MD5 ones now.

That is right and you can tell gpg-agent this by using

ssh-fingerprint-digest sha256

(I don't like the base64 encoding becuase it is hard to visual compare,
but that is how it is).  Note that while writing this I noticed that the
KEYINFO command always printed MD5 fingerprints.  I fixed that for
2.2.15 so that the above option is considered.  Further, it is also
possible to use

 keyinfo --ssh-list --ssh-fpr-md5
 keyinfo --ssh-list --ssh-fpr=sha1
 keyinfo --ssh-list --ssh-fpr=sha256

to select a certain fingerprint format independent of the option.


Salam-Shalom,

   Werner


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.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 25/03/2019 15:45, Werner Koch wrote:
> That is on purpose: gpg-agent stores the key permanently and thus it
> makes no sense to add and remove it regularly.

It might also be "slightly annoying" to remove key material which is
also in use for other purposes :-). You remove an SSH key, and suddenly
an OpenPGP subkey is also missing...

But something more user friendly to match SSH fingerprint and keygrip
could be beneficial. I'm not sure what that would look like and neither
do I think it is high on the priority list.

For one thing, OpenSSH seems to prefer SHA256 SSH fingerprints over the
old MD5 ones now.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Werner Koch]

On Sat, 23 Mar 2019 16:19, pe...@digitalbrains.com said:

> because ssh-add -d doesn't work with gpg-agent. Well, not with the
> version in Debian stretch anyway, I reserve the right to be ignorant

That is on purpose: gpg-agent stores the key permanently and thus it
makes no sense to add and remove it regularly.

Do quickly disable a key, prefix its keygrip in ~/.gnupg/sshcontrol with
an exclamation mark.  A comment above each automatically added keygrip
gives info about the key.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 23/03/2019 13:39, Brian Exelbierd wrote:
> How did you import this key?

If your OpenSSH private key is .ssh/id_ed25519, and you are running
gpg-agent as your SSH agent, it's a matter of:

$ ssh-add ~/.ssh/id_ed25519

Any comment on the private key that was already there (presumably
through ssh-keygen's -C option) will be saved in private-keys-v1.d.

I don't use monkeysphere, I just maintain all authorized_keys files by
hand. While I do have files with the public keys, often I'll just use
ssh-add -L to get the public key I need to put in there.

The point where stuff gets interesting is deleting SSH keys. For that I
would use the method I outlined in this thread to get at the keygrip,
because ssh-add -d doesn't work with gpg-agent. Well, not with the
version in Debian stretch anyway, I reserve the right to be ignorant
about features added since then.

> Should I open a feature request on this, or have you already done so?

I don't care enough to open a feature request. The development team's
time is limited after all.

HTH,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Brian Exelbierd]

Hi Peter,

Your help has been amazing and very useful.  I was re-reading this answer and I 
noticed the comments below:

On Sat, Mar 16, 2019, at 11:12 AM, Peter Lebbing wrote:

> (By the way, as you can see in the ssh-keygen output, my key actually
> has a comment field in the gpg-agent. It was imported from an on-disk
> OpenSSH file, that's where it came from.

How did you import this key?  Monkeysphere's pem2opengpg only reads older 
formats that don't support comments.  I didn't see anything about import from 
the newer formats in my searches.

> I don't know a way to have a
> comment field for a key generated with gpg, although I could probably
> hack it in in the private key store. Let's not do that.)

Should I open a feature request on this, or have you already done so?

regards,

bex

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 17/03/2019 13:17, Brian Exelbierd wrote:
> Having done no code examination, I feel like this is where the
> identity information for subkeys comes into play.  I presume the SSH
> request would pass the value of the identity file to the gpg-agent.
> This is probably 100% wrong though/

30% wrong? It actually is "the wire encoding of the public key", so key
material rather than a filename. Your comment made a click in my mind
though. I've solved it.

Put this in .ssh/config:
--8<---cut here---start->8---
Host your-server.com
IdentitiesOnly yes
IdentityFile ~/.ssh/testkey7.pub
--8<---cut here---end--->8---

Where testkey7.pub is a file containing the *public* key. Usually you
would use a private key here, but OpenSSH is just as happy with a public
key as long as the agent can do the private operation.

> Also, as an aside.  It appears that subkeys do not prompt for the key
> passphrase.  Instead I just get an allow/deny dialog or no dialog at
> all if I don't force confirm.

The passphrase is cached. The duration can be controlled through
default-cache-ttl-ssh and max-cache-ttl-ssh in ~/.gnupg/gpg-agent.conf
or on a per-key basis in sshcontrol. It is possible to turn off caching
for SSH keys completely. See "man gpg-agent".

> Distracting myself with GPG/SSH while doing taxes is a bad idea and
> leads to bad internet hygiene :D

Hehehe :-D

HTH,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Brian Exelbierd]

On Sun, Mar 17, 2019, at 1:12 PM, Peter Lebbing wrote:
> On 17/03/2019 12:45, Brian Exelbierd wrote:
> > There is no longer an identityfile to use in the .ssh/config file
> > which means all auth keys are tried with all hosts.  I have multiple
> > auth keys and the hosts give up after 2 or 3 failures.  How can I get
> > the right key served to the right host since SSH doesn't know how to
> > ask for it anymore ...
> 
> Ooohhh. I would have hoped the OpenSSH server's MaxAuthTries would only
> count failed signatures, not failed key matches. But I can reproduce
> this problem.
>
> I don't know a satisfactory solution to this.

Having done no code examination, I feel like this is where the identity 
information for subkeys comes into play.  I presume the SSH request would pass 
the value of the identity file to the gpg-agent.  This is probably 100% wrong 
though/

Also, as an aside.  It appears that subkeys do not prompt for the key 
passphrase.  Instead I just get an allow/deny dialog or no dialog at all if I 
don't force confirm.

> PS: Could you please trim your quotes when you reply on the mailing
> list?

Happily - and I should have last time.  Distracting myself with GPG/SSH while 
doing taxes is a bad idea and leads to bad internet hygiene :D

regards,

bex

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 17/03/2019 12:45, Brian Exelbierd wrote:
> There is no longer an identityfile to use in the .ssh/config file
> which means all auth keys are tried with all hosts.  I have multiple
> auth keys and the hosts give up after 2 or 3 failures.  How can I get
> the right key served to the right host since SSH doesn't know how to
> ask for it anymore ...

Ooohhh. I would have hoped the OpenSSH server's MaxAuthTries would only
count failed signatures, not failed key matches. But I can reproduce
this problem.

Picking an auth key is a two-step process. First the client offers
different public keys until the server says it accepts one. Only then is
authentication tried with the key that was just negotiated. But indeed,
MaxAuthTries counts every *offer* as an auth try and cuts out after 6 in
the default configuration.

--8<---cut here---start->8---
$ ssh -v [...]
[...]
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/peter/.ssh/id_ed25519
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /home/peter/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Just a comment
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Testkey 1
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Testkey 2
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Testkey 3
Received disconnect from ::1 port 22:2: Too many authentication failures
Authentication failed.
--8<---cut here---end--->8---

I don't know a satisfactory solution to this.

Peter.

PS: Could you please trim your quotes when you reply on the mailing
list?

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Brian Exelbierd]

On Sat, Mar 16, 2019, at 11:12 AM, Peter Lebbing wrote:
> Hi Brian,
> 
> On 15/03/2019 23:28, Brian Exelbierd wrote:> Hi,
> > Either way, I am unsure how to identify which subkey is which SSH key.
> 
> Provided the auth keys are in your .gnupg/sshcontrol file, the following
> will help:
> 
> --8<---cut here---start->8---
> $ ssh-add -L | head -1 >firstkey
> 
> $ ssh-keygen -l -E md5 -f firstkey 
> 2048 MD5:69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 
> /home/peter/.ssh/id_rsa (RSA)
> 
> $ gpg-connect-agent 
> > help keyinfo
> # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] 
> # 
> # Return information about the key specified by the KEYGRIP.  If the
> # key is not available GPG_ERR_NOT_FOUND is returned.  If the option
> # --list is given the keygrip is ignored and information about all
> # available keys are returned.  If --ssh-list is given information
> # about all keys listed in the sshcontrol are returned.  With --with-ssh
> # information from sshcontrol is always added to the info. Unless --data
> # is given, the information is returned as a status line using the format:
> # 
> #   KEYINFO   
> # 
> # KEYGRIP is the keygrip.
> # 
> # TYPE is describes the type of the key:
> # 'D' - Regular key stored on disk,
> # 'T' - Key is stored on a smartcard (token),
> # 'X' - Unknown type,
> # '-' - Key is missing.
> # 
> # SERIALNO is an ASCII string with the serial number of the
> #  smartcard.  If the serial number is not known a single
> #  dash '-' is used instead.
> # 
> # IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
> #   is not known a dash is used instead.
> # 
> # CACHED is 1 if the passphrase for the key was found in the key cache.
> #If not, a '-' is used instead.
> # 
> # PROTECTION describes the key protection type:
> # 'P' - The key is protected with a passphrase,
> # 'C' - The key is not protected,
> # '-' - Unknown protection.
> # 
> # FPR returns the formatted ssh-style fingerprint of the key.  It is only
> # printed if the option --ssh-fpr has been used.  It defaults to '-'.
> # 
> # TTL is the TTL in seconds for that key or '-' if n/a.
> # 
> # FLAGS is a word consisting of one-letter flags:
> #   'D' - The key has been disabled,
> #   'S' - The key is listed in sshcontrol (requires --with-ssh),
> #   'c' - Use of the key needs to be confirmed,
> #   '-' - No flags given.
> # 
> # More information may be added in the future.
> OK
> > keyinfo --ssh-list --ssh-fpr
> S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 
> 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - S
> S KEYINFO 64711FCE432F5387CCDD5E466513387B63096989 D - - - P 
> c1:34:c6:23:f7:d5:64:fb:49:7a:d3:53:db:d1:87:64 - S
> OK
> > 
> --8<---cut here---end--->8---
> 
> ssh-add was used to export the first key in the agent to a file.
> ssh-keygen can produce an MD5 fingerprint for that file for you.
> 
> You can match the MD5 fingerprint to the 7th field of KEYINFO. Then the
> 1st field will give you the keygrip of that SSH key.
> 
> If your auth keys are for some reason not in sshcontrol, you could use
> 
> --8<---cut here---start->8---
> $ gpg-connect-agent 'KEYINFO --list --ssh-fpr' /bye | fgrep 
> 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96
> S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 
> 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - -
> --8<---cut here---end--->8---
> 
> because it wouldn't be much fun wading through all your keys if you have
> a lot of key material, and that command without the grep will list it all.

This worked and will allow me to associate the keygrips with the old identify 
file names for my own bookkeeping/sanity.  This way as a project terminates, so 
can its key.

> (By the way, as you can see in the ssh-keygen output, my key actually
> has a comment field in the gpg-agent. It was imported from an on-disk
> OpenSSH file, that's where it came from. I don't know a way to have a
> comment field for a key generated with gpg, although I could probably
> hack it in in the private key store. Let's not do that.)

I think having the ability to name or associate metadata here is a nice-to-have 
for those of us managing multiple auth subkeys.

That said, I have a new problem of course :D

There is no longer an identityfile to use in the .ssh/config file which means 
all auth keys are tried with all hosts.  I have multiple auth keys and the 
hosts give up after 2 or 3 failures.  How can I get the right key served to the 
right host since SSH doesn't know how to ask for it anymore ...

regards,

bex

PS: This should possibly be a new thread, however, there are so few discussions 
of multiple auth-subkeys I feel like a searcher is likely to wind up here first.

> 
> HTH,
> 
> Peter.
> 
> PS: I see no reason why you 

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

Hi,

On 16/03/2019 14:22, Dirk Gottschalk wrote:
> In the output from --export-ssh-key is also a comment field. This
> fieldd, in my case shows: openpgp:0xF852DAEE

Yes, but it is only added by the --export-ssh-key command and has a
fixed form. Instead, for my keys, which by the way are not part of an
OpenPGP certificate and therefore can't be used with --export-ssh-key,
they are stored with the private key. The comment got there because they
were originally OpenSSH keys with that comment, and the comment got
retained on import into the agent. I could have put any comment
whatsoever in it and it would have been stored by the agent and shown on
any invocation of ssh-add -{l,L}.

--8<---cut here---start->8---
$ ssh-add -l
[...]
256 SHA256:xb01Ehdlix7o5oLN0YUEkhr70yZDXXCNXcMoNS48PB0 Just a comment (ED25519)
--8<---cut here---end--->8---

HTH,

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 




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Dirk Gottschalk via Gnupg-users]

Hi.

Am Samstag, den 16.03.2019, 11:11 +0100 schrieb Peter Lebbing:
> (By the way, as you can see in the ssh-keygen output, my key actually
> has a comment field in the gpg-agent. It was imported from an on-disk
> OpenSSH file, that's where it came from. I don't know a way to have a
> comment field for a key generated with gpg, although I could probably
> hack it in in the private key store. Let's not do that.)

In the output from --export-ssh-key is also a comment field. This
fieldd, in my case shows: openpgp:0xF852DAEE

This should be enough to identify the key. It is the short ID of the
referred authentication subkey.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: 4AAB BDA8 C34D 3037 DA6B  7DF9 BB6A A254 DF10 8952
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 16/03/2019 11:11, Wolfgang Traylor wrote:
> $ gpg2 --export-ssh-key 

Actually, if you want a specific subkey, you need to append a ! to the
key ID (probably need to quote it as well for the shell, \! ).
Otherwise, GnuPG will use key selection rules to take the latest
authentication subkey from the certificate selected.

It's a fine and simple method. The advantage of my method is it will
also work with keys that aren't part of an OpenPGP key :-). Plus it's
more fun.

HTH,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

Hi Brian,

On 15/03/2019 23:28, Brian Exelbierd wrote:> Hi,
> Either way, I am unsure how to identify which subkey is which SSH key.

Provided the auth keys are in your .gnupg/sshcontrol file, the following
will help:

--8<---cut here---start->8---
$ ssh-add -L | head -1 >firstkey

$ ssh-keygen -l -E md5 -f firstkey 
2048 MD5:69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 
/home/peter/.ssh/id_rsa (RSA)

$ gpg-connect-agent 
> help keyinfo
# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] 
# 
# Return information about the key specified by the KEYGRIP.  If the
# key is not available GPG_ERR_NOT_FOUND is returned.  If the option
# --list is given the keygrip is ignored and information about all
# available keys are returned.  If --ssh-list is given information
# about all keys listed in the sshcontrol are returned.  With --with-ssh
# information from sshcontrol is always added to the info. Unless --data
# is given, the information is returned as a status line using the format:
# 
#   KEYINFO   
# 
# KEYGRIP is the keygrip.
# 
# TYPE is describes the type of the key:
# 'D' - Regular key stored on disk,
# 'T' - Key is stored on a smartcard (token),
# 'X' - Unknown type,
# '-' - Key is missing.
# 
# SERIALNO is an ASCII string with the serial number of the
#  smartcard.  If the serial number is not known a single
#  dash '-' is used instead.
# 
# IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
#   is not known a dash is used instead.
# 
# CACHED is 1 if the passphrase for the key was found in the key cache.
#If not, a '-' is used instead.
# 
# PROTECTION describes the key protection type:
# 'P' - The key is protected with a passphrase,
# 'C' - The key is not protected,
# '-' - Unknown protection.
# 
# FPR returns the formatted ssh-style fingerprint of the key.  It is only
# printed if the option --ssh-fpr has been used.  It defaults to '-'.
# 
# TTL is the TTL in seconds for that key or '-' if n/a.
# 
# FLAGS is a word consisting of one-letter flags:
#   'D' - The key has been disabled,
#   'S' - The key is listed in sshcontrol (requires --with-ssh),
#   'c' - Use of the key needs to be confirmed,
#   '-' - No flags given.
# 
# More information may be added in the future.
OK
> keyinfo --ssh-list --ssh-fpr
S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 
69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - S
S KEYINFO 64711FCE432F5387CCDD5E466513387B63096989 D - - - P 
c1:34:c6:23:f7:d5:64:fb:49:7a:d3:53:db:d1:87:64 - S
OK
> 
--8<---cut here---end--->8---

ssh-add was used to export the first key in the agent to a file.
ssh-keygen can produce an MD5 fingerprint for that file for you.

You can match the MD5 fingerprint to the 7th field of KEYINFO. Then the
1st field will give you the keygrip of that SSH key.

If your auth keys are for some reason not in sshcontrol, you could use

--8<---cut here---start->8---
$ gpg-connect-agent 'KEYINFO --list --ssh-fpr' /bye | fgrep 
69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96
S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 
69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - -
--8<---cut here---end--->8---

because it wouldn't be much fun wading through all your keys if you have
a lot of key material, and that command without the grep will list it all.

(By the way, as you can see in the ssh-keygen output, my key actually
has a comment field in the gpg-agent. It was imported from an on-disk
OpenSSH file, that's where it came from. I don't know a way to have a
comment field for a key generated with gpg, although I could probably
hack it in in the private key store. Let's not do that.)

HTH,

Peter.

PS: I see no reason why you shouldn't have multiple auth subkeys, unlike
John Doe.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Wolfgang Traylor]

> I am unsure how to identify which subkey is which SSH key.
You can export your GPG subkey for SSH and compare with the `ssh-add -L` output:

$ gpg2 --export-ssh-key 

This gives you the SSH-formatted subkey which will match one of your lines from 
`ssh-add -L`.
Note that the comments (anything after the first whitespace in each line) might 
be different. So compare only up to the first whitespace.

Best regards,
W. Traylor

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[john doe]

On 3/15/2019 11:28 PM, Brian Exelbierd wrote:
> Hi,
>
> I would like to eliminate my SSH keys and consolidate my existing keys into 
> my gpg key.  I can do this by either importing my existing keys (easier) or 
> creating new authentication subkeys.
>
> Either way, I am unsure how to identify which subkey is which SSH key.  I 
> created a test key, below, with two authentication subkeys.  I can't tell 
> which subkey matches each key.  How do you know?  Without this knowledge it 
> is hard to know which key goes with which server and which key is safe to 
> delete later.
>
> Any advice?  Thank you.
>
> regards,
>
> bex
>
> ---
>
> # gpg2 -K --with-keygrip
> /root/.gnupg/pubring.kbx
> 
> sec   rsa2048 2019-03-15 [SC] [expires: 2021-03-14]
>   84B9177ECD98386DACDA102DF80B5DDF8D55076A
>   Keygrip = 13C8D80A6B3A5A7CC4095A254A07AFC9F287CF16
> uid   [ultimate] keyname
> ssb   rsa2048 2019-03-15 [E] [expires: 2021-03-14]
>   Keygrip = 26FD3D7D54BEE12111354B9E968C23EEDC445A4E
> ssb   rsa2048 2019-03-15 [A]
>   Keygrip = A04EA628443B5C1C60411C15E1EC35C21186D405
> ssb   rsa2048 2019-03-15 [A]
>   Keygrip = 45F02D545B6B6ADC32FCB7BC64B943F23B35D3FF
>
> # ssh-add -l
> 2048 SHA256:T/SZUtqVEzoo4c4rmh5e4jrnCd5ewGNj1Nrsg3VYbCE (none) (RSA)
> 2048 SHA256:+Qbn7T5rQms4+bBfzc7D68H2TynS/8gyT0pjrMOaiQA (none) (RSA)
>
> # ssh-add -L
> ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQC8vnk7hPdP9tWdw8DUV8rOYDTAlhbvSWPuEUwr0FdaveJoJtgYhceKVoyFnOYZnZ8QP0nAytHGeSAHkL/9Vw0Whyouu94awwoEERdkIzvl/KVRU3n0dBabbjbqlY6Dz+4zjIUo/KbyZ9PZHohCVQs/DzFUqnLsPoHzVVDBPvMHFkf0t2qSe0Pv2I7vLmI1UVBFMspjy80kmoijheFAmXebCGC3uzr23BKqzqfj2/HYv/DJAQufGiHsH+/I855U8Dckd4TQmHS4aRsIY0px1HA4of9nIiWWifvqxwshax2VSdJucJi1RB6YbSxbTIbjnl0YJbbIajV8xJjyloaOofph
>  (none)
> ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQCnrIe/fe6i6AMA+evGzz3Gc56rSH5D3cJ9R/cMta2jHjtNlZZD/uJNdbuALsI4elB5m0Yxsbiz0j3UG2L/2nHfjD73oPQkwFIacvtkZT/hpp/BWPFDWQnGaWeWdFfsxlzu6gOMsfYJQDxNIPRjLbYkcIOL3Xw5EIFlS2xEr+/ZGsD2uNnReXj5XZnXh6FrxcX7vhnKpHHsVzDZG+xRs+xhErhiini8J1REZaQzZnVftD/WZGbAU8f3LSDfSCFQVxRTibXW5JMd6JfFe1zZXST+JfAEqg5LhucpzsQAbYWtNiqZ5McerI1HYPjYNUqoYhGzXsWvEuvPp3qugVjH3ZI5
>  (none)
>

My understanding is that one subkey is to be used for authentication .

--
John Doe

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users