No private key found for "/dev/fd/63" when using generated SSH key verification command. #2066

wsulla commented 2025年08月06日 00:40:04 +02:00

Comment

I decided to add a new SSH key to my Codeberg account today, it has been a while, and I have a new computer I would like to use for git. I am using OpenSuSE Tumbleweed, and have git and forgejo installed. And I have restarted with fresh keys, getting the same result.

About a year ago, it went off without a hitch, I was able to create an SSH key using ssh-keygen -t ed25519 -f ~/.ssh/SERVER_id_ed25519 -C "NEW COMPUTER access to codeberg" and pretty sure I needed to point the verification command at the local public key file when I did it before.

I can add the public key to codeberg, and when I try to connect to verify with ssh -T git@codeberg.org after setting up my ssh_config to point to my public key.

When try to verify by providing a signature for my SSH key, I am told to generate a signature using bash -c "echo -n '{{TOKEN}}' | ssh-keygen -Y sign -n gitea -f <(echo '{{PUBLIC KEY}}')"

I get No private key found for "/dev/fd/63" in return, instead of a signature.

It works if I actually point it at the public key file though.

### Comment I decided to add a new SSH key to my Codeberg account today, it has been a while, and I have a new computer I would like to use for git. I am using OpenSuSE Tumbleweed, and have git and forgejo installed. And I have restarted with fresh keys, getting the same result. About a year ago, it went off without a hitch, I was able to create an SSH key using `ssh-keygen -t ed25519 -f ~/.ssh/SERVER_id_ed25519 -C "NEW COMPUTER access to codeberg"` and pretty sure I needed to point the verification command at the local public key file when I did it before. I can add the public key to codeberg, and when I try to connect to verify with `ssh -T git@codeberg.org` after setting up my ssh_config to point to my public key. When try to verify by providing a signature for my SSH key, I am told to generate a signature using `bash -c "echo -n '{{TOKEN}}' | ssh-keygen -Y sign -n gitea -f <(echo '{{PUBLIC KEY}}')"` I get `No private key found for "/dev/fd/63"` in return, instead of a signature. It works if I actually point it at the public key file though.

Gusted commented 2025年08月06日 01:07:45 +02:00

Hi, what shell do you use? And what was the value of {{PUBLIC KEY}}?

Hi, what shell do you use? And what was the value of `{{PUBLIC KEY}}`?

wsulla commented 2025年08月06日 20:45:31 +02:00

Bash, and it was the public key of my SSH key for Codeberg.

Bash, and it was the public key of my SSH key for Codeberg.

Gusted commented 2025年08月06日 21:39:52 +02:00

Feels like a regression of forgejo/forgejo#7516, CC @senekor do you have a clue?

Feels like a regression of https://codeberg.org/forgejo/forgejo/pulls/7516, CC @senekor do you have a clue?

senekor commented 2025年08月06日 22:17:04 +02:00

Yeah, that seems related, but I don't have an idea what could be the problem right now.

Yeah, that seems related, but I don't have an idea what could be the problem right now.

senekor commented 2025年08月06日 22:21:08 +02:00

I actually I can reproduce this 🤔 I guess that's good, but I'm sure I tested that command on regular files when I came up with this approach. Will investigate further.

I actually I can reproduce this 🤔 I guess that's good, but I'm sure I tested that command on regular files when I came up with this approach. Will investigate further.

wsulla commented 2025年08月06日 23:10:23 +02:00

Sorry if I should have raised this on the forgejo repo!

Sorry if I should have raised this on the forgejo repo!

senekor commented 2025年08月06日 23:32:18 +02:00

This is very strange. It doesn't even work for my use case (anymore?) (password manager as ssh agent without a public key file on disk).

This is very strange. It doesn't even work for _my_ use case (anymore?) (password manager as ssh agent without a public key file on disk).

senekor commented 2025年08月07日 00:37:08 +02:00

Weirdly enough, it does work when I execute the command on a server I'm ssh'ed into and I've forwarded my ssh agent. 😅

Weirdly enough, it _does_ work when I execute the command on a server I'm ssh'ed into and I've forwarded my ssh agent. 😅

earl-warren commented 2025年08月07日 06:45:12 +02:00

This means the shell in which the line is copied does not have access to the private key. See forgejo/forgejo#8628 where you can comment if needed.

This means the shell in which the line is copied does not have access to the private key. See https://codeberg.org/forgejo/forgejo/issues/8628 where you can comment if needed.

Gusted commented 2025年08月07日 13:55:52 +02:00

@earl-warren wrote in #2066 (comment):

This means the shell in which the line is copied does not have access to the private key. See forgejo/forgejo#8628 where you can comment if needed.

This contradicts what is being said here

@wsulla wrote in #2066 (comment):

When try to verify by providing a signature for my SSH key, I am told to generate a signature using bash -c "echo -n '{{TOKEN}}' | ssh-keygen -Y sign -n gitea -f <(echo '{{PUBLIC KEY}}')"

I get No private key found for "/dev/fd/63" in return, instead of a signature.

It works if I actually point it at the public key file though.

@earl-warren wrote in https://codeberg.org/Codeberg/Community/issues/2066#issuecomment-6153127: > This means the shell in which the line is copied does not have access to the private key. See forgejo/forgejo#8628 where you can comment if needed. This contradicts what is being said here @wsulla wrote in https://codeberg.org/Codeberg/Community/issues/2066#issue-2004460: > When try to verify by providing a signature for my SSH key, I am told to generate a signature using `bash -c "echo -n '{{TOKEN}}' | ssh-keygen -Y sign -n gitea -f <(echo '{{PUBLIC KEY}}')"` > > I get `No private key found for "/dev/fd/63"` in return, instead of a signature. > > It works if I actually point it at the public key file though.

wsulla commented 2025年08月07日 23:04:39 +02:00

I am not sure why it wouldn't have permission to access the private key. I made the keys with the same user I was running the command with.

I created a test key to poke around with a bit, because I had a theory.

I wondered if it might be something like running it in Konsole was doing something, but if I try to run it using a TTY (switching using control alt + F4), and that also didn't work, still No private key found for "/dev/fd/63".

If I try running with sudo substituted into the commands, I still have the issue.

So, if I run "sudo echo -n '{{TOKEN}}' | sudo ssh-keygen -Y sign -n gitea -f <(echo 'ssh-ed{{SSH PUBLIC KEY}}')", I still get No private key found for "/dev/fd/63"

I am not sure why it wouldn't have permission to access the private key. I made the keys with the same user I was running the command with. I created a test key to poke around with a bit, because I had a theory. I wondered if it might be something like running it in Konsole was doing something, but if I try to run it using a TTY (switching using control alt + F4), and that also didn't work, still `No private key found for "/dev/fd/63"`. If I try running with sudo substituted into the commands, I still have the issue. So, if I run `"sudo echo -n '{{TOKEN}}' | sudo ssh-keygen -Y sign -n gitea -f <(echo 'ssh-ed{{SSH PUBLIC KEY}}')"`, I still get `No private key found for "/dev/fd/63"`

senekor commented 2025年08月08日 00:02:41 +02:00

I've gathered a little more information. ssh-keygen can be run with -vvv for some debug output, but it's not a lot for the sign command. In my case, I got:

debug1: Couldn't get agent socket: agent not present

So it couldn't connect to my ssh agent. I'm using 1Password, and my config looks something like this:

IdentityAgent "~/.1password/agent.sock"

Apparantly, ssh-keygen doesn't respect that? I was able to fix it with:

SSH_AUTH_SOCK=~/.1password/agent.sock bash -c "echo -n ...

I'm not sure what changed about my environment from when I implemented this...

So then I tried figuring out what went wrong in OP's case, with a normal key file. I disabled my ssh agent and generated a key file. The signing command with -vvv also says "agent not present". So I tried running an agent and loading the generated key in it:

eval "$(ssh-agent -s)"
ssh-add
bash -c "echo -n ...

This worked for me! @wsulla can you confirm that works for you as well?

I'm still not sure what the best solution is, but at least we'll know a little more about what's going on...

I've gathered a little more information. `ssh-keygen` can be run with `-vvv` for some debug output, but it's not a lot for the sign command. In my case, I got: > debug1: Couldn't get agent socket: agent not present So it couldn't connect to my ssh agent. I'm using 1Password, and my config looks something like this: ``` IdentityAgent "~/.1password/agent.sock" ``` Apparantly, ssh-keygen doesn't respect that? I was able to fix it with: ```sh SSH_AUTH_SOCK=~/.1password/agent.sock bash -c "echo -n ... ``` I'm not sure what changed about my environment from when I implemented this... So then I tried figuring out what went wrong in OP's case, with a normal key file. I disabled my ssh agent and generated a key file. The signing command with `-vvv` also says "agent not present". So I tried running an agent and loading the generated key in it: ```sh eval "$(ssh-agent -s)" ssh-add bash -c "echo -n ... ``` This worked for me! @wsulla can you confirm that works for you as well? I'm still not sure what the best solution is, but at least we'll know a little more about what's going on...

senekor commented 2025年08月08日 00:25:24 +02:00

Ok, here's a one-liner that should work for normal keys in files:

bash -c 'if test -z "$SSH_AUTH_SOCK"; then eval "$(ssh-agent -s)"; ssh-add; fi; echo -n "{{token}}" | ssh-keygen -Y sign -n gitea -f <(echo "{{public_key}}")'

For people like me, we could add a note below telling them that they need to set their ssh agent via the SSH_AUTH_SOCK environment variable, doing it in ~/.ssh/config won't work.

Ok, here's a one-liner that should work for normal keys in files: ```sh bash -c 'if test -z "$SSH_AUTH_SOCK"; then eval "$(ssh-agent -s)"; ssh-add; fi; echo -n "{{token}}" | ssh-keygen -Y sign -n gitea -f <(echo "{{public_key}}")' ``` For people like me, we could add a note below telling them that they need to set their ssh agent via the `SSH_AUTH_SOCK` environment variable, doing it in `~/.ssh/config` won't work.

wsulla commented 2025年08月08日 00:35:07 +02:00

That works for me!

If I ssh-add ~/.ssh/my_codeberg_public_key and pre-authenticate using the passphrase I have on my keyfile, I get the expected signature. So I guess having a password on my keyfile breaks the command. I get no prompt for the password for my keyfile when I run the pre-generated command.

When I try to do it by manually pointing at the keyfile, I am prompted for my password. Which I guess explains why it works.

Thank you @senekor for looking into it , and I think trying to do this without asking people to point at their keyfile is an awesome idea. Happy to try other things.

That works for me! If I `ssh-add ~/.ssh/my_codeberg_public_key` and pre-authenticate using the passphrase I have on my keyfile, I get the expected signature. So I guess having a password on my keyfile breaks the command. I get no prompt for the password for my keyfile when I run the pre-generated command. When I try to do it by manually pointing at the keyfile, I am prompted for my password. Which I guess explains why it works. Thank you @senekor for looking into it , and I think trying to do this without asking people to point at their keyfile is an awesome idea. Happy to try other things.

wsulla commented 2025年08月08日 01:02:30 +02:00

Sorry, I missed your last comment. I had to specifically add my public key in SSH add.

Sorry, I missed your last comment. I had to specifically add my public key in SSH add.

senekor commented 2025年08月08日 01:05:02 +02:00

In my testing, using a key in a file without a passphrase also didn't work at first, so that wasn't the issue I think. I also tried the oneliner above with a key in a file with a passphrase this time and it also worked (prompting me for the passphrase). I didn't need to tell ssh-add specifically with key to load, it discovered that automatically.

In my testing, using a key in a file without a passphrase also didn't work at first, so that wasn't the issue I think. I also tried the [oneliner above](https://codeberg.org/Codeberg/Community/issues/2066#issuecomment-6166414) with a key in a file **with a passphrase** this time and it also worked (prompting me for the passphrase). I didn't need to tell `ssh-add` specifically with key to load, it discovered that automatically.

wsulla commented 2025年08月08日 01:35:44 +02:00

OK, interesting, I am still seeing the same issue with your one-liner. I am not very experienced with SSH, but looking at the man page, if you run ssh-add without modification, it only adds keys with standard names. I create one key per service, so my private keyfile for this test key is named codeberg2_id_ed25519 and the public key is codeberg2_id_ed25519.pub. So, I think your one liner only works without specifying if your keyfile is named one of ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519_sk.

For your one liner to work for me, I need to make it bash -c 'if test -z "$SSH_AUTH_SOCK"; then eval "$(ssh-agent -s)"; ssh-add {{LOCATION OF PRIVATE KEY}}; fi; echo -n "{{TOKEN}}" | ssh-keygen -Y sign -n gitea -f <(echo "{{SSH PUBLIC KEY}}")'

OK, interesting, I am still seeing the same issue with your one-liner. I am not very experienced with SSH, but looking at the man page, if you run ssh-add without modification, it only adds keys with standard names. I create one key per service, so my private keyfile for this test key is named `codeberg2_id_ed25519` and the public key is `codeberg2_id_ed25519.pub`. So, I think your one liner only works without specifying if your keyfile is named one of `~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519_sk.` For your one liner to work for me, I need to make it `bash -c 'if test -z "$SSH_AUTH_SOCK"; then eval "$(ssh-agent -s)"; ssh-add {{LOCATION OF PRIVATE KEY}}; fi; echo -n "{{TOKEN}}" | ssh-keygen -Y sign -n gitea -f <(echo "{{SSH PUBLIC KEY}}")'`

senekor commented 2025年08月08日 02:00:34 +02:00

I see. We could try to be sneaky and enumerate the key files with custom names in the ~/.ssh directory:

ssh-add $(find ~/.ssh/ -name "*.pub" | sed "s/.pub//")

Surely there are more exotic setups this doesn't cover, but I think we have to draw the line somewhere.

I see. We could try to be sneaky and enumerate the key files with custom names in the `~/.ssh` directory: ```sh ssh-add $(find ~/.ssh/ -name "*.pub" | sed "s/.pub//") ``` Surely there are more exotic setups this doesn't cover, but I think we have to draw the line somewhere.

Gusted commented 2025年08月08日 02:02:01 +02:00

Does the old way of specifying the public key works? We could resurrect the old way and offer it as fallback if the one via <(...) doesn't work.

Does the old way of specifying the public key works? We could resurrect the old way and offer it as fallback if the one via `<(...)` doesn't work.

wsulla commented 2025年08月08日 02:14:53 +02:00

I was assuming that I was just on the wrong side of the line that has to be drawn somewhere, maybe enough to have an FAQ entry, or be offered an alternative, but not enough to be handled by the auto-generated command.

I like the idea of a fallback to the old way in case your very svelte and tidy way of doing it doesn't work.

I was assuming that I was just on the wrong side of the line that has to be drawn somewhere, maybe enough to have an FAQ entry, or be offered an alternative, but not enough to be handled by the auto-generated command. I like the idea of a fallback to the old way in case your very svelte and tidy way of doing it doesn't work.

senekor commented 2025年08月08日 02:18:03 +02:00

Actually I'm curious, why do you have multiple ssh keys on one machine? I can't think of a security benefit to that.

Actually I'm curious, why do you have multiple ssh keys on one machine? I can't think of a security benefit to that.

wsulla commented 2025年08月08日 02:36:51 +02:00

I don't entirely remember, but when I sat down and taught myself how SSH keys work a few years ago, that is what I decided to do. Since I use a config file, it isn't something I think about much outside of adding new places I want to SSH into. I can't remember if I found a strong argument for it being more secure, but I kind of liked the idea of a separation of concerns.

I don't entirely remember, but when I sat down and taught myself how SSH keys work a few years ago, that is what I decided to do. Since I use a config file, it isn't something I think about much outside of adding new places I want to SSH into. I can't remember if I found a strong argument for it being more secure, but I kind of liked the idea of a separation of concerns.

datagonerogue commented 2025年08月08日 18:21:08 +02:00

btw, this worked for me:

echo -n "{{TOKEN}}" > /tmp/token

sudo ssh-keygen -Y sign -f "{{SSH PUBLIC KEY}}" -n gitea /tmp/token

cat /tmp/token.sig

btw, this worked for me: `echo -n "{{TOKEN}}" > /tmp/token` `sudo ssh-keygen -Y sign -f "{{SSH PUBLIC KEY}}" -n gitea /tmp/token` `cat /tmp/token.sig`

senekor commented 2025年08月11日 20:37:13 +02:00

The related PR was merged, I think this issue can be closed now.

The [related PR](https://codeberg.org/forgejo/forgejo/pulls/8821) was merged, I think this issue can be closed now.

wsulla commented 2025年08月12日 00:10:25 +02:00

Agreed, thank you so much for looking into this.

Agreed, thank you so much for looking into this.