GPG error "Inappropriate ioctl for device" when forwarding GPG agent from Windows to WSL to Dev Containers

[trallnag]

On my machine I manage my GPG keyring with Gpg4win. The GPG agent is running in Windows. I forward the agent from Windows to WSL, where I do most of my development work. The following command works perfectly fine in Windows and WSL:

echo lol | gpg --clear-sign

If the GPG agent is not running yet, the GPG agent starts and caches the password using a pin entry program located on Windows. This works from both WSL and Windows.

When I open a project in a dev container in Windows, the above command works fine.

When I open a project in a dev container in WSL, the above command fails.

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

Setting GPG_TTY does not make a difference.

Interestingly, the keyring itself is imported correctly. I check this with:

gpg --list-secret-keys

Here are the logs:

remoteContainers-2025-01-25T18-34-43.042Z.log

How do I forward the GPG agent from Windows to WSL?

In Windows I have the ordinary GPG agent running.

I run https://github.com/BusyJay/gpg-bridge in Windows.

I forward the service provided by gpg-bridge from Windows to WSL GPG socket using SSH.

[chrmarti]

The forwarding seems to be set up:

[2025-01-25T18:34:52.711Z] gpg-agent: Socket in container (/home/vscode/.gnupg/S.gpg-agent) forwarded to wsl host (/run/user/1000/gnupg/S.gpg-agent.extra).

It also tries to start the gpg-agent in WSL, maybe that could cause issues with gpg-bridge:

[2025-01-25T18:34:52.735Z] Start: Run in Host: gpg-connect-agent updatestartuptty /bye

[vs-code-engineering]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[tschaffter]

@chrmarti Have you found a solution to this issue? When I run echo test | gpg --clearsign, the first problem I encounter is that gpg-agent is only available in restricted mode, which results in the following message "problem with fast path key listing: Forbidden - ignored":

Inside the dev container:

$ echo $GPG_TTY
/dev/pts/0

$ echo test | gpg --clearsign
...
gpg: problem with fast path key listing: Forbidden - ignored
...
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

The restricted mode seems to come from the fact that the standard gpg-agent inside the dev container is forwarded to the "extra" gpg-agent socket on the host as you mentioned above.

I'm wondering if the issue "Inappropriate ioctl for device" is related to this restricted mode or if this error actually occurs on the host-side via the forwarding since GPG_TTY seems properly set inside the dev container. I have tried exporting GPG_TTY in ~/.bashrc on the host, but that does not seem to prevent the issue.

[chrmarti]

@tschaffter That looks like a different problem, please open a new issue. Maybe compare the GPG versions locally and in the container and try to align them if they differ much.

[trallnag]

From what I know, restricted mode is not really a "problem" but the "normal" mode gpg works in with forwarding active.

For example, in my WSL distribution gpg is also running in restricted mode because I forward the agent from Windows to WSL. VSC handles this just fine when running from WSL and not a dev container from WSL.

Maybe the problem is forwarding a forwarded agent? As there are no issues in dev container when starting it from Windows where the host agent is unrestricted.

[tschaffter]

Thanks for the feedback on the restricted mode @chrmarti, @trallnag.

Maybe the problem is forwarding a forwarded agent?

I thought that this may have been a possibility given the following environment:

Loading

graph LR
    WSL["WSL2<br>✅ gpg-agent"] -->|Remote-SSH| AL["Amazon Linux 2023<br>✅ gpg-agent (forwarded?)"]
    AL -->|Dev Containers| Ubuntu["Ubuntu 24.04<br>✅ gpg-agent (forwarded)"]

However, I can reproduce the issue using a different environment that do not offer the possibility to forward a forwarded gpg-agent.

I can run echo test | gpg --clearsign inside an Ubuntu dev container when gpg-agent is not forwarded (first case in the diagram below).

Whenever gpg-agent is forwarded, I am unable to successfully run echo test | gpg --clearsign, even when preceded by export GPG_TTY=$(tty). In this case, I encounter the same error reported by @chrmarti in this ticket.

In the last case, I added export GPG_TTY=$(tty) to the host's ~/.bashrc. As a result, running echo test | gpg --clearsign (with or without preceding it by export GPG_TTY=$(tty)) inside the dev container now produces a different error:
"gpg: [stdin]: clear-sign failed: No such file or directory."

Do you know why I'm encountering these issues, which prevent me from entering the passphrase required to sign the message ("test")?

Loading

graph LR
    A["macOS<br>❌ gpg-agent"] -->|Remote-SSH| B1["Amazon Linux 2023<br>❌ gpg-agent"]
    B1 -->|Dev Containers| C1["Ubuntu 24.04<br>✅ gpg-agent<br>✅ echo test | gpg --clearsign"]

    A["macOS<br>❌ gpg-agent"] -->|Remote-SSH| B2["Amazon Linux 2023<br>✅ gpg-agent"]
    B2 -->|Dev Containers| C2["Ubuntu 24.04<br>✅ gpg-agent forwarded<br>❌ echo test | gpg --clearsign:<br>Inappropriate ioctl for device"]

    A -->|Remote-SSH| B3["Amazon Linux 2023<br>✅ gpg-agent<br>Export GPG_TTY in ~/.bashrc"]
    B3 -->|Dev Containers| C3["Ubuntu 24.04<br>✅ gpg-agent forwarded<br>❌ echo test | gpg --clearsign:<br>No such file or directory"]

[chrmarti]

@tschaffter Thanks for investigating! A few thoughts / ideas:

Dev Containers first checks if the SSH server has GPG installed and tries to forward to that before it checks if the local machine has GPG installed and uses that.

When you make GPG available on the SSH server (using SSH's agent forwarding I assume), try to set it up so it uses a pinentry program on the local machine and test that from the SSH server. If you want to make it work with GPG_TTY, you would need to find a way to have a terminal to the SSH server on the side and have that set as the value of GPG_TTY which might be tricky.

When you have GPG on the SSH server working with a local pinentry program, retry with Dev Containers and share the logs if that doesn't work here. (F1 > Dev Containers: Show Container Log)

[vs-code-engineering]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!