github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1616] Firejail breaks the ssh-agent launch semantics #1083

New issue

Closed

opened 2026-05-05 07:25:54 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 07:25:54 -06:00

Owner

Originally created by @lhernanz on GitHub (Oct 25, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1616

Hi,

the most common way of launching ssh-agent is by using:

eval `ssh-agent`

That works because ssh-agent prints the environment information before getting into background. Unfortunately, when using the firejail profile this is not the case and the process just blocks as it never gets into background. This breaks some of the most common shell launch scripts and some programs like ssh-ident.

If you try to solve this by putting firejail in the background, the problem is that you miss the information that is sent to the terminal before getting into the background. You can try to fix this by using the --output option in firejail, but you still need to use an sleep to get the output in the file. A hack on top of a hack.

Wouldn't be possible for firejail to detect that the controlled process has got into the background so that it could imitate the same behavior? Is there any other way to simulate this?

I think that firejail is a great addition to ssh-agent. It would be a pity not to be able to use it.

Thanks

Regards

Originally created by @lhernanz on GitHub (Oct 25, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1616 Hi, the most common way of launching ssh-agent is by using: ```bash eval `ssh-agent` ``` That works because ssh-agent prints the environment information before getting into background. Unfortunately, when using the firejail profile this is not the case and the process just blocks as it never gets into background. This breaks some of the most common shell launch scripts and some programs like _ssh-ident_. If you try to solve this by putting firejail in the background, the problem is that you miss the information that is sent to the terminal before getting into the background. You can try to fix this by using the `--output` option in firejail, but you still need to use an sleep to get the output in the file. A hack on top of a hack. Wouldn't be possible for firejail to detect that the controlled process has got into the background so that it could imitate the same behavior? Is there any other way to simulate this? I think that firejail is a great addition to ssh-agent. It would be a pity not to be able to use it. Thanks Regards

gitea-mirror

2026-05-05 07:25:54 -06:00

closed this issue
added the
bug

workaround
labels

gitea-mirror commented

2026-05-05 07:25:57 -06:00

Author

Owner

@Adrianzo commented on GitHub (Nov 3, 2017):

I'm having the same trouble. Played around a little bit with the profile but got only pain and no gains 😝

@Adrianzo commented on GitHub (Nov 3, 2017): I'm having the same trouble. Played around a little bit with the profile but got only pain and no gains :stuck_out_tongue_closed_eyes:

gitea-mirror commented

2026-05-05 07:25:59 -06:00

Author

Owner

@Adrianzo commented on GitHub (Dec 14, 2017):

any news on this?

@Adrianzo commented on GitHub (Dec 14, 2017): any news on this?

gitea-mirror commented

2026-05-05 07:26:00 -06:00

Author

Owner

@laomaiweng commented on GitHub (May 9, 2019):

I have a workaround for this issue. Basically if an agent is not already running, I do the following in my ~/.bashrc:

SSH_AUTH_SOCK="$(mktemp -d --tmpdir ssh-XXXXXXXX)/S.ssh-agent"
ssh-agent -s -a "$SSH_AUTH_SOCK" >~/.ssh/agent & disown
export SSH_AUTH_SOCK SSH_AGENT_PID=$!

The idea is that I don't let the agent decide the path to its socket, this way I don't need it to tell me where it is.

As for the PID, $! is actually the PID of the parent Firejail process, which will die when the shell exits. This is not really an issue as the PID is only ever used to signal the agent, which usually doesn't happen. However, to provide the actual ssh-agent PID to other shells, I just spawn a background subshell that waits for the agent to be up and running, gets its PID, and substitutes it in the environment file:

(
    for ((i=0; i<10; i++)); do
        if ssh-add -l &>/dev/null; then
            # Agent is up!
            ssh_agent_pid=$(( $(firejail --tree | grep -F "$SSH_AUTH_SOCK" | cut -d: -f1 | tail -n1) ))
            sed -e 's/^SSH_AGENT_PID=[0-9]\+;/SSH_AGENT_PID='"$ssh_agent_pid"';/' -i ~/.ssh/agent
            exit 0
        fi
        sleep 1
    done
    exit 1
) & disown

This is a bit convoluted, but mostly unnecessary anyways. I have it just for the sake of completeness. :)

The problem remains that the agent isn't available right after the command runs and is put in the background. However, for interactive use, that's not really an issue.

@laomaiweng commented on GitHub (May 9, 2019): I have a workaround for this issue. Basically if an agent is not already running, I do the following in my `~/.bashrc`: ```bash SSH_AUTH_SOCK="$(mktemp -d --tmpdir ssh-XXXXXXXX)/S.ssh-agent" ssh-agent -s -a "$SSH_AUTH_SOCK" >~/.ssh/agent & disown export SSH_AUTH_SOCK SSH_AGENT_PID=$! ``` The idea is that I don't let the agent decide the path to its socket, this way I don't need it to tell me where it is. As for the PID, `$!` is actually the PID of the parent Firejail process, which will die when the shell exits. This is not really an issue as the PID is only ever used to signal the agent, which usually doesn't happen. However, to provide the actual `ssh-agent` PID to other shells, I just spawn a background subshell that waits for the agent to be up and running, gets its PID, and substitutes it in the environment file: ```bash ( for ((i=0; i<10; i++)); do if ssh-add -l &>/dev/null; then # Agent is up! ssh_agent_pid=$(( $(firejail --tree | grep -F "$SSH_AUTH_SOCK" | cut -d: -f1 | tail -n1) )) sed -e 's/^SSH_AGENT_PID=[0-9]\+;/SSH_AGENT_PID='"$ssh_agent_pid"';/' -i ~/.ssh/agent exit 0 fi sleep 1 done exit 1 ) & disown ``` This is a bit convoluted, but mostly unnecessary anyways. I have it just for the sake of completeness. :) The problem remains that the agent isn't available right after the command runs and is put in the background. However, for interactive use, that's not really an issue.

gitea-mirror commented

2026-05-05 07:26:02 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 29, 2019):

I'm going to mark this with "workaround" and close this for now. @lhernanz, please feel free to re-open if you have more questions or if the workaround does not work for you.

@chiraag-nataraj commented on GitHub (May 29, 2019): I'm going to mark this with "workaround" and close this for now. @lhernanz, please feel free to re-open if you have more questions or if the workaround does not work for you.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1083

No description provided.

Rows
Columns