[GH-ISSUE #2698] firejailed ssh tunnel not authenticated

gitea-mirror commented

2026-05-05 08:21:25 -06:00

Owner

Originally created by @rieje on GitHub (May 16, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2698

I use Syncthing and want to access the remote GUI via ssh tunneling. I have the following shell function:

pi-syncthing() {
  ssh -fNT -L 9999:localhost:8384 \
    -o "ControlMaster auto" \
    -o "ControlPath /tmp/syncthing-%u@%n.socket" \
    pi

  # run firefox locally in foreground
  firefox 127.0.0.1:9999 > /dev/null

  # after the firefox session dies, kill the backgrounded ssh session
  ssh -o "ControlMaster auto" \
    -o "ControlPath /tmp/syncthing-%u@%n.socket" \
    -O exit \
    pi
}

It works if I don't firejail it (i.e. /usr/bin/ssh); but doesn't work when jailed (i.e. /usr/local/binssh). It won't authenticate the ssh session (I just see the randomart image until it times out). Canceling it (Ctrl+c) will launch Firefox but the remote web GUI is not connected, obviously.

I did do some trial and error with /etc/firejail/ssh.profile but have no success. Is this just a simple whitelist of some setting or is it not worth the effort to jail (which is unfortunate)?

Originally created by @rieje on GitHub (May 16, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2698 I use Syncthing and want to access the [remote GUI via ssh tunneling](https://docs.syncthing.net/users/firewall.html#remote-web-gui). I have the following shell function: ``` pi-syncthing() { ssh -fNT -L 9999:localhost:8384 \ -o "ControlMaster auto" \ -o "ControlPath /tmp/syncthing-%u@%n.socket" \ pi # run firefox locally in foreground firefox 127.0.0.1:9999 > /dev/null # after the firefox session dies, kill the backgrounded ssh session ssh -o "ControlMaster auto" \ -o "ControlPath /tmp/syncthing-%u@%n.socket" \ -O exit \ pi } ``` It works if I don't firejail it (i.e. `/usr/bin/ssh`); but doesn't work when jailed (i.e. `/usr/local/binssh`). It won't authenticate the ssh session (I just see the randomart image until it times out). Canceling it (Ctrl+c) will launch Firefox but the remote web GUI is not connected, obviously. I did do some trial and error with `/etc/firejail/ssh.profile` but have no success. Is this just a simple whitelist of some setting or is it not worth the effort to jail (which is unfortunate)?

gitea-mirror closed this issue

2026-05-05 08:21:26 -06:00

gitea-mirror commented

2026-05-05 08:21:28 -06:00

Author

Owner

@ghost commented on GitHub (May 16, 2019):

@rieje Have you tried to debug authentication issues using ssh's -v option? Showing debug log(s) here would be more informative to see what's actually happening. You can use something like:

$ firejail --debug /usr/bin/ssh -v -fNT -L 9999:localhost:8384 -o "ControlMaster auto" -o "ControlPath /tmp/syncthing-%u@%n.socket" pi | tee debug.log 2>&1

@ghost commented on GitHub (May 16, 2019): @rieje Have you tried to debug authentication issues using ssh's -v option? Showing debug log(s) here would be more informative to see what's actually happening. You can use something like: `$ firejail --debug /usr/bin/ssh -v -fNT -L 9999:localhost:8384 -o "ControlMaster auto" -o "ControlPath /tmp/syncthing-%u@%n.socket" pi | tee debug.log 2>&1`

gitea-mirror commented

2026-05-05 08:21:29 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 16, 2019):

firejail sh -c "sleep 1m &" didn't go in background. Not sure how firejail handel stdin/out and fg/bg.

@rusty-snake commented on GitHub (May 16, 2019): `firejail sh -c "sleep 1m &"` didn't go in background. Not sure how firejail handel stdin/out and fg/bg.

gitea-mirror commented

2026-05-05 08:21:30 -06:00

Author

Owner

@rieje commented on GitHub (May 17, 2019):

@glitsj16 Here's the output. Actually, it doesn't timeout, so i did ctrl+c. Also, there's stout to terminal not shown on debug.log if that's relevant:

debug1: Reading configuration data /home/rieje/.ssh/config
debug1: /home/rieje/.ssh/config line 20: Applying options for pi
debug1: /home/rieje/.ssh/config line 32: Applying options for *
debug1: /home/rieje/.ssh/config line 38: Deprecated option "useroaming"
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/syncthing-rieje@pi.socket" does not exist
debug1: Connecting to pi.localdomain [xxxxxxxxx] port 22.
debug1: Connection established.

So seems like problem with socket.

@rieje commented on GitHub (May 17, 2019): @glitsj16 Here's the [output](http://sprunge.us/2BIEPx). Actually, it doesn't timeout, so i did `ctrl+c`. Also, there's stout to terminal not shown on debug.log if that's relevant: debug1: Reading configuration data /home/rieje/.ssh/config debug1: /home/rieje/.ssh/config line 20: Applying options for pi debug1: /home/rieje/.ssh/config line 32: Applying options for * debug1: /home/rieje/.ssh/config line 38: Deprecated option "useroaming" debug1: Reading configuration data /etc/ssh/ssh_config debug1: auto-mux: Trying existing master debug1: Control socket "/tmp/syncthing-rieje@pi.socket" does not exist debug1: Connecting to pi.localdomain [xxxxxxxxx] port 22. debug1: Connection established. So seems like problem with socket.

gitea-mirror commented

2026-05-05 08:21:31 -06:00

Author

Owner

@ghost commented on GitHub (May 17, 2019):

debug1: /home/gcheng/.ssh/config line 38: Deprecated option "useroaming"

Deprecated option can be safely removed from /home/gcheng/.ssh/config

debug1: Control socket "/tmp/syncthing-gcheng@epsi.socket" does not exist

Try using a socket path that's guaranteed to be accessible with firejail, e.g. ~/.ssh/syncthing-%u@%n.socket.

@ghost commented on GitHub (May 17, 2019): > debug1: /home/gcheng/.ssh/config line 38: Deprecated option "useroaming" Deprecated option can be safely removed from /home/gcheng/.ssh/config > debug1: Control socket "/tmp/syncthing-gcheng@epsi.socket" does not exist Try using a socket path that's guaranteed to be accessible with firejail, e.g. ~/.ssh/syncthing-%u@%n.socket.

gitea-mirror commented

2026-05-05 08:21:32 -06:00

Author

Owner

@rieje commented on GitHub (May 17, 2019):

Same issue, unfortunately.

@rieje commented on GitHub (May 17, 2019): Same issue, unfortunately.

gitea-mirror commented

2026-05-05 08:21:32 -06:00

Author

Owner

@ghost commented on GitHub (May 17, 2019):

@rieje I use SSH tunneling (for other purposes than syncthing) with firejail succesfully and reliably, so it is possible. Just keep experimenting with it. Personally I always disable sockets by using ControlPath none and use firejail --shutdown=foo to kill the SSH session (with a fallback using pkill). Here's an example of how your shell function could look like:

pi-syncthing() {
  firejail --name=syncthing-ssh-tunnel /usr/bin/ssh -fNT -L 9999:localhost:8384 \
    -o "ControlMaster auto" \
    -o "ControlPath none" \
    pi

  # run firefox locally in foreground
  firefox 127.0.0.1:9999 > /dev/null

  # after the firefox session dies, kill the backgrounded ssh session
  # via firejail
  firejail --shutdown=syncthing-ssh-tunnel || err_fj=1
  # if that fails, try pkill
  [ "$err_fj" ] && pkill -f  "ssh -fNT -L 9999:localhost:8384"
}

@ghost commented on GitHub (May 17, 2019): @rieje I use SSH tunneling (for other purposes than syncthing) with firejail succesfully and reliably, so it is possible. Just keep experimenting with it. Personally I always disable sockets by using `ControlPath none` and use firejail --shutdown=foo to kill the SSH session (with a fallback using pkill). Here's an example of how your shell function could look like: ``` pi-syncthing() { firejail --name=syncthing-ssh-tunnel /usr/bin/ssh -fNT -L 9999:localhost:8384 \ -o "ControlMaster auto" \ -o "ControlPath none" \ pi # run firefox locally in foreground firefox 127.0.0.1:9999 > /dev/null # after the firefox session dies, kill the backgrounded ssh session # via firejail firejail --shutdown=syncthing-ssh-tunnel || err_fj=1 # if that fails, try pkill [ "$err_fj" ] && pkill -f "ssh -fNT -L 9999:localhost:8384" } ```

gitea-mirror commented

2026-05-05 08:21:32 -06:00

Author

Owner

@rieje commented on GitHub (May 19, 2019):

Hmm, just tried and still the same problem/output, bizarre.

@rieje commented on GitHub (May 19, 2019): Hmm, just tried and still the same problem/output, bizarre.

gitea-mirror commented

2026-05-05 08:21:33 -06:00

Author

Owner

@ghost commented on GitHub (May 20, 2019):

@rieje What OS and firejail version are you seeing this on? The current ssh.profile contains noblacklist /tmp/ssh-*, so using a ControlPath like /tmp/ssh-syncthing-%u@%n.socket should work. Leaving aside the shell function for now, can you report output of the below commands:

$ firejail --noprofile /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi
$ firejail /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi

@ghost commented on GitHub (May 20, 2019): @rieje What OS and firejail version are you seeing this on? The current ssh.profile contains `noblacklist /tmp/ssh-*`, so using a ControlPath like /tmp/ssh-syncthing-%u@%n.socket should work. Leaving aside the shell function for now, can you report output of the below commands: - $ firejail --noprofile /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi - $ firejail /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi

gitea-mirror commented

2026-05-05 08:21:33 -06:00

Author

Owner

@rieje commented on GitHub (May 22, 2019):

I am on Arch Linux and firejail is on version 0.9.58.2-1.

First command (with ssh verbose option) output. I see the host key fingerprint and that's it until I kill the process with Ctrl+c.
Second command (with ssh verbose option) output. Same thing--I see host key fingerprint and that's it until I kill the process.
Without firejail, /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi is same thing, but after killing with Ctrl+c, pidof ssh shows process still exists.

@rieje commented on GitHub (May 22, 2019): I am on Arch Linux and firejail is on version 0.9.58.2-1. * First command (with ssh verbose option) [output](http://sprunge.us/hbZ9Zc). I see the host key fingerprint and that's it until I kill the process with `Ctrl+c`. * Second command (with ssh verbose option) [output](http://sprunge.us/iJO0LR). Same thing--I see host key fingerprint and that's it until I kill the process. * Without firejail, `/usr/bin/ssh -fMNT -L 9999:localhost:8384 pi` is same thing, but after killing with `Ctrl+c`, `pidof ssh` shows process still exists.

gitea-mirror commented

2026-05-05 08:21:34 -06:00

Author

Owner

@ghost commented on GitHub (May 25, 2019):

@rieje Looks like the firejail tunnel is working. Have you tried using a systemd user unit yet to control the tunnel? Something like the below can be placed under ~/.config/systemd/user as sshtunnel.service:

[Unit]
Description=SSH tunnel [Syncthing]

[Service]
Type=simple
ExecStart=/usr/bin/firejail /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi
RemainAfterExit=yes

[Install]
WantedBy=default.target

From your shell function I infer you don't want to have the tunnel running all the time, so you don't have to enable the service. Alternatively you could look into sshtunnel, which is in the AUR. Once you have the file set up, you can do the following:

$ systemctl --user start sshtunnel
$ firefox 127.0.0.1:9999
$ systemctl --user stop sshtunnel

After testing the remote Syncthing GUI like that you could integrate those commands into your shell function.

@ghost commented on GitHub (May 25, 2019): @rieje Looks like the firejail tunnel is working. Have you tried using a systemd user unit yet to control the tunnel? Something like the below can be placed under ~/.config/systemd/user as sshtunnel.service: ``` [Unit] Description=SSH tunnel [Syncthing] [Service] Type=simple ExecStart=/usr/bin/firejail /usr/bin/ssh -fMNT -L 9999:localhost:8384 pi RemainAfterExit=yes [Install] WantedBy=default.target ``` From your shell function I infer you don't want to have the tunnel running all the time, so you don't have to enable the service. Alternatively you could look into [sshtunnel](https://github.com/The-Compiler/sshtunnel), which is in the AUR. Once you have the file set up, you can do the following: ``` $ systemctl --user start sshtunnel $ firefox 127.0.0.1:9999 $ systemctl --user stop sshtunnel ``` After testing the remote Syncthing GUI like that you could integrate those commands into your shell function.

gitea-mirror commented

2026-05-05 08:21:34 -06:00

Author

Owner

@rieje commented on GitHub (May 25, 2019):

Just tried it and it works. Any particular reason for RemainAfterExit=yes out of curiosity? Want to keep it as simple as possible.

Works great, much appreciated. Still don't know why the original function isn't running, but this seems simpler anyway. Feel free to close this issue if you want.

@rieje commented on GitHub (May 25, 2019): Just tried it and it works. Any particular reason for `RemainAfterExit=yes` out of curiosity? Want to keep it as simple as possible. Works great, much appreciated. Still don't know why the original function isn't running, but this seems simpler anyway. Feel free to close this issue if you want.

gitea-mirror commented

2026-05-05 08:21:35 -06:00

Author

Owner

@ghost commented on GitHub (May 25, 2019):

@rieje Happy to see you've got it working now. My guess the original shell function hangs because the first ssh command isn't backgrounded. SSH is backgrounded, but not the shell command itself. If you would like to test, just for the fun of it, try putting a & after pi and add a sleep 2 (or something appropriate to wait untill the tunnel is running) before starting firefox.

About the RemainAfterExit=yes. That's totally my own preference, I forgot to mention that. I seem to be conditioned to the green/red colored output of systemd status commands to spot errors at a glance. You can safely take that out. I'll close the issue, but feel free to re-open if something turns up during daily use of the tunnel.

@ghost commented on GitHub (May 25, 2019): @rieje Happy to see you've got it working now. My guess the original shell function hangs because the first ssh command isn't backgrounded. SSH is backgrounded, but not the shell command itself. If you would like to test, just for the fun of it, try putting a `&` after `pi` and add a `sleep 2` (or something appropriate to wait untill the tunnel is running) before starting firefox. About the `RemainAfterExit=yes`. That's totally my own preference, I forgot to mention that. I seem to be conditioned to the green/red colored output of systemd status commands to spot errors at a glance. You can safely take that out. I'll close the issue, but feel free to re-open if something turns up during daily use of the tunnel.

gitea-mirror referenced this issue

2026-05-05 10:12:44 -06:00

[PR #1700] [MERGED] inox edgy flavours fix (doesnt work history and extensions) #4046

Rows
Columns

[GH-ISSUE #2698] firejailed ssh tunnel not authenticated #1700