When I add ssh key to an account, I get Can not verify your SSH key: ... asn1: structure error: tags don't match

[lasersPew]

Description

When I add ssh key to an account, I get Can not verify your SSH key: failed to parse DER encoded public key as either PKIX or PEM RSA Key: asn1: structure error: tags don't match (16 vs {class:1 tag:15 length:112 isCompound:true}) {optional:false explicit:false application:false private:false defaultValue: tag: stringType:0 timeType:0 set:false omitEmpty:false} publicKeyInfo @2 asn1: structure error: tags don't match (16 vs {class:1 tag:15 length:112 isCompound:true}) {optional:false explicit:false application:false private:false defaultValue: tag: stringType:0 timeType:0 set:false omitEmpty:false} PublicKey @2

Gitea Version

1.18.1

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

https://gist.github.com/lasersPew/749f3818a1cba92f35de084dabb35840

Screenshots

Git Version

2.36.3

Operating System

alpine 3.16.3

How are you running Gitea?

Using Docker CLI inside Alpine 0.17 in WSL, no Docker Desktop using WSL2 kernel. Set things up using Portainer, Stacks specifically. Here's the config:

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:1.18.1
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=password1
    restart: always
    networks:
      - gitea
    volumes:
      - /config/gitea:/data:rw
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
      - /config/git:/git:rw
    ports:
      - 3001:3000
      - 2222:22
    depends_on:
      - db

  db:
    image: postgres:14.6-alpine
    container_name: gitea-db
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=password1
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - /config/postgres:/var/lib/postgresql/data

Database

PostgreSQL

[jrjake]

What command did you run to generate key? And what is filename of key (like ~/.ssh/[file you are uploading])?

[lasersPew]

I just ran ssh-keygen to both machines I tried it to and both of which had output on files ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub

Here's the key on one on the machines for reference:

<a SSH private key>

[lunny]

How do you copy the content?

[zeripath]

You should only be uploading the PUBLIC key not the PRIVATE key. That is why this is failing,

[zeripath]

Now interestingly I thought we had code that was able to detect this sort of mistake - and report back to the user that they were doing the wrong thing. So I guess we should double check that.

[delvh]

Please do not upload any secret data such as your SSH private key to public spaces. I've removed any trace of it now. If you're lucky, no one copied it before I did that. If you're unlucky, your key is now compromised.

[lasersPew]

Please do not upload any secret data such as your SSH private key to public spaces. I've removed any trace of it now. If you're lucky, no one copied it before I did that. If you're unlucky, your key is now compromised.

Ah no probs. That key is from another docker container and I regenerated it multiple times.

[zeripath]

@delvh I was going to use that compromised private key to try to improve the error detection!!

[LightgardenCC]

I recommend using the git-bash on windows instead of powershell or cmd to run the ssh-keygen command (echo -n 'sample' | ssh-keygen -Y sign -n gitea -f ./id_rsa) to successfully complete the verification.

When I use powershell, the verification keeps failing, maybe powershell generates an unkown error when it executes these commands.

[lasersPew]

When I use powershell, the verification keeps failing, maybe powershell generates an unkown error when it executes these commands.

Can confirm that it happens quite a lot, especially when you're SSHing with a Private VPN on, like HackTheBox(the service I used where I get the error)

[jesse-tong]

I recommend using the git-bash on windows instead of powershell or cmd to run the ssh-keygen command (echo -n 'sample' | ssh-keygen -Y sign -n gitea -f ./id_rsa) to successfully complete the verification.

When I use powershell, the verification keeps failing, maybe powershell generates an unkown error when it executes these commands.

In my machine, git-bash also fails as well, regardless when echo the signature to a file and copy them, or using clip tho.

[simplyniceweb]

I recommend using the git-bash on windows instead of powershell or cmd to run the ssh-keygen command (echo -n 'sample' | ssh-keygen -Y sign -n gitea -f ./id_rsa) to successfully complete the verification.

When I use powershell, the verification keeps failing, maybe powershell generates an unkown error when it executes these commands.

Works on my end. Windows 11 here. Maximized the git bash and run the command and done.

[frankzimper]

Just had this issue with a windows client. The problem is the echo command on Windows. What worked for me was to change the line to

echo 08ba346789...b5cg23| ssh-keygen -Y sign -n gitea -f ./id_rsa

The important parts here are:

• no quotes around the sample
• NO SPACE before the pipe, otherwise it will be part of the calculation

[wxiaoguang]

Actually you do not really need to "verify" that key.

As long as you added it into Gitea, the key could work without "verifying". Just use it.

[hsolon]

You also might want to check the permissions of your public key...chmod 400 ~/.ssh/Key_file.pub seemed to work for me.

[jason19970210]

Gitea Version 1.23.3

I just encountered a similar problem last weekend with the following error message once I try to verify my SSH id_ed25519 key pair.

The provided SSH key, signature or token do not match or token is out-of-date.

By figuring out just like the above discussions, which the echo command within PowerShell is an alias of Write-Output and it sure not taking the -n flag as same behavior with Bash, it will be added a new line char passing to pipeline. This comes the result that the output signature will always not match the one calculated in Bash.

ref #33548