-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Command for verifying SSH key doesn't work under Windows #21527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 |
Try |
that command does produce a different SSH string than the other PS command I run, but it still isn't the right string |
Actually, it should point to the private key or say something like |
This worked perfectly for me! Thanks a ton! |
Anyone have a idea to make this on mac i dont get the key i need |
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. |
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... |
I run into the same problem Windows sshkey -Y sign ... vs. Linux sshkey -Y singn ... issue. 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? |
Bump. Please support the windows key signing. |
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. |
Window-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves go-gitea#21527.
Windows-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves #21527. --------- Co-authored-by: Heiko Besemann <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
…a#28392) Windows-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves go-gitea#21527. --------- Co-authored-by: Heiko Besemann <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
…#28464) Backport #28392 by @nekrondev Windows-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves #21527. Co-authored-by: nekrondev <[email protected]> Co-authored-by: Heiko Besemann <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
…a#28392) Windows-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves go-gitea#21527. --------- Co-authored-by: Heiko Besemann <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
…a#28392) Windows-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves go-gitea#21527. --------- Co-authored-by: Heiko Besemann <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
…a#28392) (go-gitea#28464) Backport go-gitea#28392 by @nekrondev Windows-based shells will add a CRLF when piping the token into ssh-keygen command resulting in verification error. This resolves go-gitea#21527. Co-authored-by: nekrondev <[email protected]> Co-authored-by: Heiko Besemann <[email protected]> Co-authored-by: wxiaoguang <[email protected]> (cherry picked from commit b47482d)
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:

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

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

Error given when pasting from Windows:

Success message when pasting from Linux:

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
The text was updated successfully, but these errors were encountered: