# SSH key verification fails

**URL:** <https://forum.gitea.com/t/ssh-key-verification-fails/12429>\
**Category:** Install/Maintain/Configure\
**Created:** [September 14, 2026, 3:33am UTC](https://forum.gitea.com/t/ssh-key-verification-fails/12429 "2026-09-14T03:33:39Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Singlestone](https://avatars.discourse-cdn.com/v4/letter/s/c4cdca/32.png) [@Singlestone](https://forum.gitea.com/u/Singlestone)\
**Post date:** [September 14, 2026, 3:33am UTC](https://forum.gitea.com/t/ssh-key-verification-fails/12429/1 "2026-09-14T03:33:39Z")

</div>

I just installed Gitea 1.27.3 on Ubuntu 26.04. I’m trying to add an SSH key, but I can’t verify it. The command to generate the armored SSH signature works fine, but when I paste the text and hit the Verify button, I always get the response “The provided SSH key, signature or token do not match, or the token is out-of-date.”

I created the SSH key (ED25519) today. I made sure that I pasted the correct public key and the correct armored SSH signature. I tried extra newlines at the end, at the beginning, and both, in the armored signature. No dice. Is there any way for me to determine what the problem is? Thanks.

**Edit:** The /var/lib/gitea/log directory is empty. Also, the same question was asked [here](https://forum.gitea.com/t/the-provided-ssh-key-signature-or-token-do-not-match-or-token-is-out-of-date/7866) in 2023, but was never answered.

---

<div class="post-metadata">

**Author:** ![nite\_route](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/nite_route/32/7522_2.png) [@nite\_route](https://forum.gitea.com/u/nite_route)\
**Post date:** [September 22, 2026, 12:21am UTC](https://forum.gitea.com/t/ssh-key-verification-fails/12429/2 "2026-09-22T00:21:48Z")

</div>

that verify step is picky about the token + signature pair timing out or mismatching.

stuff that usually trips it:

- regenerating the signature after the token on the page expired (refresh the verify page, copy the new token, resign with that exact token)

- pasting a signature made against a different key than the one you just added

- extra whitespace or missing begin/end lines in the armored block

refresh the verify page, copy the token shown, run the suggested ssh-keygen command again with that token, paste the full armored block, hit verify once. dont reuse an old signature from earlier tries.

---

<div class="post-metadata">

**Author:** ![Singlestone](https://avatars.discourse-cdn.com/v4/letter/s/c4cdca/32.png) [@Singlestone](https://forum.gitea.com/u/Singlestone)\
**Post date:** [September 26, 2026, 2:08pm UTC](https://forum.gitea.com/t/ssh-key-verification-fails/12429/3 "2026-09-26T14:08:52Z")

</div>

Thanks for the reply! It’s okay to be picky about a key, but in my opinion, it’s not okay to reject the key without a clue as to what might be wrong.

That pickiness, the possible need to refresh a page, maybe needing to run ssh-keygen, those are all examples of hidden knowledge and extra actions that drive me away from using a tool. With that in mind, I used Claude Code to roll my own solution. It’s working just fine. I’ll leave this here in case someone can find a proper solution. I definitely appreciate the time you took to reply, though. Maybe someone else will find it useful.