Command for verifying SSH key doesn't work under Windows #9717

Closed
opened 2025-11-02 08:47:25 -06:00 by GiteaMirror · 11 comments
Owner

Originally created by @jessedufrene on GitHub (Oct 21, 2022).

Description

When verifying an SSH key, the Gitea settings page gives a command that (after adjusting for the correct key path) does not work in Windows, because the output produced by the command is different than on other OSes such as Linux

The same command given the same exact private key and token will produce 2 different outputs, depending on whether the command is run under PowerShell on Windows, or the terminal on Linux (in my case, via WSL). Included are screenshots showing the same command producing two different outputs, then the public key file being echoed to show that it is the same. When pasting the given signature into Gitea (including the 'BEGIN' and 'END' parts of the output), the output from Linux will be accepted, but the output from Windows will be rejected.

I'm not sure what command would work natively in Windows, but the UI should be adjusted to show either 1 command that does work for all operating systems, or multiple commands for each operating system.

Also a QOL fix i'd like to see, instead of /path_to_your_pubkey in the command, it should use the path where the public key is stored at by default, such as ~\.ssh\id_rsa.pub on powershell and linux. Where you currently always have to modify the command, this would allow not having to modify the command in the majority of cases.

Gitea Version

1.17.3 on docker installs, 1.18.0+dev-602-g6a0330979 on demo site

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

The problematic command in question:
image

Running the given command (with token replaced with "sample" for demonstration purposes) with adjusted path under PowerShell, then cat-ing the public key:
image

Running the given command (with token replaced with "sample" for demonstration purposes) with adjusted path under WSL, then cat-ing the public key:
image

Error given when pasting from Windows:
image

Success message when pasting from Linux:
image

Git Version

No response

Operating System

Windows 10 21H2 & 21H1

How are you running Gitea?

This was tested via a Docker and Docker-Compose based install, as well as the try.gitea.io demo site

Database

No response

Originally created by @jessedufrene on GitHub (Oct 21, 2022). ### Description When verifying an SSH key, the Gitea settings page gives a command that (after adjusting for the correct key path) does not work in Windows, because the output produced by the command is different than on other OSes such as Linux The same command given the same exact private key and token will produce 2 different outputs, depending on whether the command is run under PowerShell on Windows, or the terminal on Linux (in my case, via WSL). Included are screenshots showing the same command producing two different outputs, then the public key file being echoed to show that it is the same. When pasting the given signature into Gitea (including the 'BEGIN' and 'END' parts of the output), the output from Linux will be accepted, but the output from Windows will be rejected. I'm not sure what command would work natively in Windows, but the UI should be adjusted to show either 1 command that does work for all operating systems, or multiple commands for each operating system. Also a QOL fix i'd like to see, instead of `/path_to_your_pubkey` in the command, it should use the path where the public key is stored at by default, such as `~\.ssh\id_rsa.pub` on powershell and linux. Where you currently always have to modify the command, this would allow not having to modify the command in the majority of cases. ### Gitea Version 1.17.3 on docker installs, 1.18.0+dev-602-g6a0330979 on demo site ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots The problematic command in question: ![image](https://user-images.githubusercontent.com/2367033/197123285-018265ff-d9d0-4e03-8035-c5486180a6d4.png) Running the given command (with token replaced with "sample" for demonstration purposes) with adjusted path under PowerShell, then cat-ing the public key: ![image](https://user-images.githubusercontent.com/2367033/197116349-e6d5be3c-5ca7-446e-bb3a-b8a47c14f971.png) Running the given command (with token replaced with "sample" for demonstration purposes) with adjusted path under WSL, then cat-ing the public key: ![image](https://user-images.githubusercontent.com/2367033/197116325-858e816c-8907-401c-9aa0-513b291f4a27.png) Error given when pasting from Windows: ![image](https://user-images.githubusercontent.com/2367033/197122217-749631f1-5552-4e94-85ee-a3b968cf5dc6.png) Success message when pasting from Linux: ![image](https://user-images.githubusercontent.com/2367033/197122553-b76d5ddc-355b-43f9-b998-e25c4c29f96d.png) ### Git Version _No response_ ### Operating System Windows 10 21H2 & 21H1 ### How are you running Gitea? This was tested via a Docker and Docker-Compose based install, as well as the try.gitea.io demo site ### Database _No response_
GiteaMirror added the type/bugissue/workaround labels 2025-11-02 08:47:25 -06:00
Author
Owner

@jessedufrene commented on GitHub (Oct 21, 2022):

In the meantime, I wrote a workaround bash script to make authenticating the windows key via WSL easier:

echo Grabbing host key . . .
rm -r ~/hostssh
mkdir ~/hostssh
cp $(wslpath "$(wslvar USERPROFILE)")/.ssh/* ~/hostssh
chmod go-rwx ~/hostssh/id_rsa
echo Paste this as a new key in Gitea:
echo
cat ~/hostssh/id_rsa.pub
echo
read -p "Enter the token: " token
echo Copy starting from the "BEGIN" line to the "END" line:
echo
echo -n $token | ssh-keygen -Y sign -n gitea -f ~/hostssh/id_rsa
echo
@jessedufrene commented on GitHub (Oct 21, 2022): In the meantime, I wrote a workaround bash script to make authenticating the windows key via WSL easier: ```sh echo Grabbing host key . . . rm -r ~/hostssh mkdir ~/hostssh cp $(wslpath "$(wslvar USERPROFILE)")/.ssh/* ~/hostssh chmod go-rwx ~/hostssh/id_rsa echo Paste this as a new key in Gitea: echo cat ~/hostssh/id_rsa.pub echo read -p "Enter the token: " token echo Copy starting from the "BEGIN" line to the "END" line: echo echo -n $token | ssh-keygen -Y sign -n gitea -f ~/hostssh/id_rsa echo ```
Author
Owner

@42wim commented on GitHub (Oct 21, 2022):

Try Write-Host "token" -NoNewLine | ssh-keygen -Y sign -n gitea -f .\.ssh\id_rsa

@42wim commented on GitHub (Oct 21, 2022): Try `Write-Host "token" -NoNewLine | ssh-keygen -Y sign -n gitea -f .\.ssh\id_rsa`
Author
Owner

@jessedufrene commented on GitHub (Oct 25, 2022):

that command does produce a different SSH string than the other PS command I run, but it still isn't the right string

@jessedufrene commented on GitHub (Oct 25, 2022): that command does produce a different SSH string than the other PS command I run, but it still isn't the right string
Author
Owner

@theAkito commented on GitHub (Dec 30, 2022):

Also a QOL fix i'd like to see, instead of /path_to_your_pubkey in the command, it should use the path where the public key is stored at by default, such as ~\.ssh\id_rsa.pub on powershell and linux. Where you currently always have to modify the command, this would allow not having to modify the command in the majority of cases.

Actually, it should point to the private key or say something like /path_to_your_privkey. Struggled with this for 15 minutes due to this error.

@theAkito commented on GitHub (Dec 30, 2022): > Also a QOL fix i'd like to see, instead of `/path_to_your_pubkey` in the command, it should use the path where the public key is stored at by default, such as `~\.ssh\id_rsa.pub` on powershell and linux. Where you currently always have to modify the command, this would allow not having to modify the command in the majority of cases. Actually, it should point to the private key or say something like `/path_to_your_privkey`. Struggled with this for 15 minutes due to this error.
Author
Owner

@theLockesmith commented on GitHub (Jan 9, 2023):

In the meantime, I wrote a workaround bash script to make authenticating the windows key via WSL easier:

echo Grabbing host key . . .
rm -r ~/hostssh
mkdir ~/hostssh
cp $(wslpath "$(wslvar USERPROFILE)")/.ssh/* ~/hostssh
chmod go-rwx ~/hostssh/id_rsa
echo Paste this as a new key in Gitea:
echo
cat ~/hostssh/id_rsa.pub
echo
read -p "Enter the token: " token
echo Copy starting from the "BEGIN" line to the "END" line:
echo
echo -n $token | ssh-keygen -Y sign -n gitea -f ~/hostssh/id_rsa
echo

This worked perfectly for me! Thanks a ton!

@theLockesmith commented on GitHub (Jan 9, 2023): > In the meantime, I wrote a workaround bash script to make authenticating the windows key via WSL easier: > > ```shell > echo Grabbing host key . . . > rm -r ~/hostssh > mkdir ~/hostssh > cp $(wslpath "$(wslvar USERPROFILE)")/.ssh/* ~/hostssh > chmod go-rwx ~/hostssh/id_rsa > echo Paste this as a new key in Gitea: > echo > cat ~/hostssh/id_rsa.pub > echo > read -p "Enter the token: " token > echo Copy starting from the "BEGIN" line to the "END" line: > echo > echo -n $token | ssh-keygen -Y sign -n gitea -f ~/hostssh/id_rsa > echo > ``` This worked perfectly for me! Thanks a ton!
Author
Owner

@NFIfCondition commented on GitHub (Jan 23, 2023):

Anyone have a idea to make this on mac i dont get the key i need

@NFIfCondition commented on GitHub (Jan 23, 2023): Anyone have a idea to make this on mac i dont get the key i need
Author
Owner

@zeripath commented on GitHub (Jan 24, 2023):

Would it be possible to give us some output that you think is correctly signed with a copy of a pubkey?

Then we could try to get the verifier to work correctly.

By censoring your pubkey and the output we cannot check the results ourselves and work out how to get the verifier to accept the response from windows.

@zeripath commented on GitHub (Jan 24, 2023): Would it be possible to give us some output that you think is correctly signed with a copy of a pubkey? Then we could try to get the verifier to work correctly. By censoring your pubkey and the output we cannot check the results ourselves and work out how to get the verifier to accept the response from windows.
Author
Owner

@pierre-eliep-met commented on GitHub (Feb 27, 2023):

I need to use gitea on a PC that cannot have WSL installed (security policy). So I am trying to use git bash instead (wich works for the key verification process, but I hope it can connect through ssh from windows too...

@pierre-eliep-met commented on GitHub (Feb 27, 2023): I need to use gitea on a PC that cannot have WSL installed (security policy). So I am trying to use git bash instead (wich works for the key verification process, but I hope it can connect through ssh from windows too...
Author
Owner

@nocheinlarry commented on GitHub (Nov 3, 2023):

I run into the same problem Windows sshkey -Y sign ... vs. Linux sshkey -Y singn ... issue.
I tried on Windows 11 Powershell in Windows Terminal and Windows 11 Command (cmd.exe) and Ubuntu 22.04.3 LTS.

Verifying only works in Ubuntu, Windows sshkey output is everytime deviating from the Linux and is different between PowerShell and cmd.exe.

I tried to remove 'token' and replace with "token" or not using them at all. Nothing worked so far. Has anyone any clue how to get the verification running in Windows PowerShell and cmd.exe?

@nocheinlarry commented on GitHub (Nov 3, 2023): I run into the same problem Windows sshkey -Y sign ... vs. Linux sshkey -Y singn ... issue. I tried on Windows 11 Powershell in Windows Terminal and Windows 11 Command (cmd.exe) and Ubuntu 22.04.3 LTS. Verifying only works in Ubuntu, Windows sshkey output is everytime deviating from the Linux and is different between PowerShell and cmd.exe. I tried to remove 'token' and replace with "token" or not using them at all. Nothing worked so far. Has anyone any clue how to get the verification running in Windows PowerShell and cmd.exe?
Author
Owner

@ianfailing commented on GitHub (Nov 19, 2023):

Bump. Please support the windows key signing.

@ianfailing commented on GitHub (Nov 19, 2023): Bump. Please support the windows key signing.
Author
Owner

@Unrepentant-Atheist commented on GitHub (Dec 5, 2023):

Only way to solve this for me, is to have VirtualBox running an ubuntu (if you don't use WSL), copy the priv key, and run the command inside the Ubuntu VirtualBox to generate the right signature.

@Unrepentant-Atheist commented on GitHub (Dec 5, 2023): Only way to solve this for me, is to have VirtualBox running an ubuntu (if you don't use WSL), copy the priv key, and run the command inside the Ubuntu VirtualBox to generate the right signature.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#9717