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>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users