Passing the pubkey to ssh-keygen is sufficient to verify an SSH signing key #12220

New Issue

GiteaMirror · 2025-11-02T10:02:29-06:00

GiteaMirror commented

2025-11-02 10:02:29 -06:00

Originally created by @Ma27 on GitHub (Dec 18, 2023).

Description

When verifying an SSH key to use it for signatures, gitea instructs to pipe a token to ssh-keygen -Y sign -n gitea -f /path_to_your_privkey:

https://github.com/go-gitea/gitea/blob/v1.21.2/templates/user/settings/keys_ssh.tmpl#L81

This is however not doable when the private key is on e.g. a smartcard (like a YubiKey) and SSH is done via an agent (which is what most people are probably doing anyways regardless of whether they use a hardware token).

In (at least) cases like this you can/need to pass the file containing the public key to ssh-keygen and the agent takes care of the rest.

Since this was changed from pubkey to private key in #20112 (cc @rluetzner @6543 @wxiaoguang ) I decided to not just revert it, but file a bug to discuss this first.

Ideally, it should be explained in the UI here that both variants are possible or link to appropriate docs.

Gitea Version

1.21.2

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

NixOS 23.05

How are you running Gitea?

I deploy gitea on NixOS with the NixOS module.
This is not relevant to the issue itself because the instructions for verifying an SSH key are always the same.

Database

PostgreSQL

Originally created by @Ma27 on GitHub (Dec 18, 2023). ### Description When verifying an SSH key to use it for signatures, `gitea` instructs to pipe a token to `ssh-keygen -Y sign -n gitea -f /path_to_your_privkey`: https://github.com/go-gitea/gitea/blob/v1.21.2/templates/user/settings/keys_ssh.tmpl#L81 This is however not doable when the private key is on e.g. a smartcard (like a YubiKey) and SSH is done via an agent (which is what most people are probably doing anyways regardless of whether they use a hardware token). In (at least) cases like this you can/need to pass the file containing the public key to `ssh-keygen` and the agent takes care of the rest. Since this was changed from pubkey to private key in #20112 (cc @rluetzner @6543 @wxiaoguang ) I decided to not just revert it, but file a bug to discuss this first. Ideally, it should be explained in the UI here that both variants are possible or link to appropriate docs. ### Gitea Version 1.21.2 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System NixOS 23.05 ### How are you running Gitea? I deploy gitea on NixOS with the NixOS module. This is not relevant to the issue itself because the instructions for verifying an SSH key are always the same. ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 10:02:29 -06:00

GiteaMirror closed this issue

2025-11-02 10:02:29 -06:00

GiteaMirror commented

2025-11-02 10:02:30 -06:00

@wxiaoguang commented on GitHub (Dec 18, 2023):

No idea why Gitea should explain everything on its UI, since users should figure out how to use SSH-related (all including any third-party) tools independently, by reading their manual carefully (man ssh-keygen) or learn from some official tutorials.

To sign, the private key should always be used, while ssh-keygen could find/use the private key by public key through the agent.

Maybe the simplest approach is to change the prompt to path_to_your_PrivateKey_or_AgentPublicKey

@wxiaoguang commented on GitHub (Dec 18, 2023): No idea why Gitea should explain everything on its UI, since users should figure out how to use SSH-related (all including any third-party) tools independently, by reading their manual carefully (`man ssh-keygen`) or learn from some official tutorials. To sign, the private key should always be used, while `ssh-keygen` could find/use the private key by public key through the agent. Maybe the simplest approach is to change the prompt to `path_to_your_PrivateKey_or_AgentPublicKey`

GiteaMirror commented

2025-11-02 10:02:30 -06:00

@Ma27 commented on GitHub (Dec 18, 2023):

I wouldn't expect a lot of people to know precisely how singing via ssh-keygen works. And this is a security feature at the end of the day, so I think a bit of help is a good thing here (gitea already demonstrates how to sign the token in the first place). I mean, one of the reasons why many people dislike GPG is because it's extremely inconvenient to use, so assistance is a good thing here.

To sign, the private key should always be used, while ssh-keygen could find/use the private key by public key through the agent.

correct.

Maybe the simplest approach is to change the prompt to path_to_your_PrivateKey_or_AgentPublicKey

Yeah, agreed.

@Ma27 commented on GitHub (Dec 18, 2023): I wouldn't expect a lot of people to know precisely how singing via `ssh-keygen` works. And this is a security feature at the end of the day, so I think a bit of help is a good thing here (gitea already demonstrates how to sign the token in the first place). I mean, one of the reasons why many people dislike GPG is because it's extremely inconvenient to use, so assistance is a good thing here. > To sign, the private key should always be used, while ssh-keygen could find/use the private key by public key through the agent. correct. > Maybe the simplest approach is to change the prompt to path_to_your_PrivateKey_or_AgentPublicKey Yeah, agreed.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12220

Passing the pubkey to ssh-keygen is sufficient to verify an SSH signing key #12220

Description

Gitea Version

Can you reproduce the bug on the Gitea demo site?

Log Gist

Screenshots

Git Version

Operating System

How are you running Gitea?

Database

Passing the pubkey to `ssh-keygen` is sufficient to verify an SSH signing key #12220