Populate comment field when exporting authentication key for SSH
Open, NormalPublic

Description

The gpg-agent should provide populate the comment field when providing a SSH
formatted key, ideally identifying the user (primary uid) or the gpg
authentication subkey's id or fingerprint.

The following detail was originally posted to the mailing list
(https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056911.html)

The SSH public key format contains a comment field (RFC4716, s3.3.2):

    The comment header contains a user-specified comment.
    user@example.com

From "man sshd":

    Public keys consist of the following space-separated fields:
    options, keytype, base64-encoded key, comment.

    The comment field is not used for anything (but may be convenient
    for the user to identify the key).

If I load an SSH key from a file using 'ssh-add' the comment field is
populated with the file name (i.e. "alice.pem") if the gpg-agent does
not already contain that key.

If I do "ssh-add -L" I will see "alice.pem" at the end of the output:

        ssh-rsa AAAAB3NzaC1yc2EAAAADAQAHT...IfFoxh2j13b3 alice.pem

If the key is in the agent because of the gpg keyring then it is known
as "(none)". If I do "ssh-add -L" I will see "(none)" at the end of the
output:

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQAHT...IfFoxh2j13b3 (none)

The reason that I stumbled upon this was because I was debugging a ssh
connection that used the gpg-agent and the ssh debugging output
displayed the following misleading output:

    debug1: Offering RSA public key: (none)

which means the public key called "(none)" rather than, as I initially
interpreted it, no public key.

It's also useful client-side to see who a public key belongs to.

It would be good if the comment field reflected the key source, perhaps
the short (or long) key id. For example:

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQAHT...IfFoxh2j13b3 (3A808C39)

Or even the primary uid of the key

ssh-rsa AAAAB3NzaC1yc2EAAAADAQAHT...IfFoxh2j13b3 alice@example.org

Details

Version
2.1.15
johnlane set Version to 2.1.15.
johnlane added a subscriber: johnlane.

I wish to work more with the bug tracker.

justus claimed this task.Oct 19 2016, 3:11 PM
justus added a subscriber: justus.

The bug tracker has a spam problem, so new users need to be approved. I did that.

Note that the gpg-agent *does* relay comments if the private key has one. If
the key resides on a smart card, the cards serial number is used. It uses
'(none)' to indicate that no comment has been set.

I agree that '(none)' while technically correct is not very helpful, I'll have a
look if I can come up with a more helpful fallback comment.

werner added a subscriber: werner.Oct 21 2016, 10:56 AM

Using the original file name does not make much sense because it is common to
delete that file. Maybe the creation/ctore date and key algorithm can be used
as a default.

With the extended private key format we could add a comment field for ssh.

justus removed justus as the assignee of this task.May 3 2017, 10:34 AM
jeffpc added a subscriber: jeffpc.Oct 15 2018, 4:13 AM

While I agree that it would be good for some useful comment to be generated, I'd currently settle for a way to manually set a comment on a key.

paride added a subscriber: paride.Mar 1 2019, 4:53 PM
cepxuo added a subscriber: cepxuo.Apr 21 2019, 4:00 AM

This bug makes it impossible to use gpg-agent as ssh-agent for keys generated from gnupg.
(How should I understand what passphrase should I enter?)
The only way is to load them with ssh-add.

Please, take comment for ssh from the public key.

As I see READKEY shows ssh comment imported from ssh key file by ssh-add. Is there a way to add it manually?

Same here, having YubiKeys and on-disk ssh keys from several computers, it is a bit a pain not to know which key is actually used. Any chances to get at least an update via manual editing of the comment?

werner edited projects, added gnupg (gpg23), ssh; removed gnupg.Mon, Oct 14, 9:28 AM

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.

@werner Yes, that sounds great, and would help already a lot, but extending it for card keys would be optimal. Thanks for your work.