[GH-ISSUE #6730] ssh: -f functionality broken #3350

New issue

Open

opened 2026-05-05 09:56:07 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 09:56:07 -06:00

Owner

Originally created by @hlein on GitHub (May 1, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6730

Description

firejail ssh -N -f -L ... will exit after successful authentication, rather than background and wait.

Running without -f works as expected, although of course that means not backgrounding.

Describe the bug

Steps to Reproduce

# Start w/no listener
t1 $ netstat -antp 2>/dev/null | egrep 1111
# Regular no-firejail works - backgrounds w/persistent listener process
t1 $ /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost
t1 $ netstat -antp 2>/dev/null | egrep 1111
tcp        0      0 127.0.0.1:1111          0.0.0.0:*               LISTEN      1913/ssh                      
tcp6       0      0 ::1:1111                :::*                    LISTEN      1913/ssh                      
t1 $ kill 1913
# Running firejail w/-f exits successfully but w/no listener
t1 $ firejail /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost
t1 $ echo $?
0
t1 $ netstat -antp 2>/dev/null | egrep 1111
# Running firejail w/o -f works, but ofc doesn't background
t1 $ firejail /usr/bin/ssh -N -L 1111:127.0.0.1:1112 localhost

t2 $ netstat -antp 2>/dev/null | egrep 1111
tcp        0      0 127.0.0.1:1111          0.0.0.0:*               LISTEN      2154/ssh                      
tcp6       0      0 ::1:1111                :::*                    LISTEN      2154/ssh

Throwing in some -v's and/or verbose server logs doesn't really tell us anything new:

t1 $ firejail /usr/bin/ssh -N -f -vvv -L 1111:127.0.0.1:1112 localhost
debug1: OpenSSH_10.0p2, OpenSSL 3.2.4 11 Feb 2025
...
Authenticated to 127.0.0.1 ([127.0.0.1]:52) using "publickey".
debug1: Local connections to LOCALHOST:1111 forwarded to remote address 127.0.0.1:1112
debug3: channel_setup_fwd_listener_tcpip: type 2 wildcard 0 addr NULL
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Local forwarding listening on ::1 port 1111.
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new port-listener [port listener] (inactive timeout: 0)
debug1: Local forwarding listening on 127.0.0.1 port 1111.
debug2: fd 5 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new port-listener [port listener] (inactive timeout: 0)
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: forking to background
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: client_repledge: enter
debug3: send packet: type 1
debug1: channel 0: free: port listener, nchannels 2
debug3: channel 0: status: The following connections are open:

debug1: channel 1: free: port listener, nchannels 1
debug3: channel 1: status: The following connections are open:

Transferred: sent 3452, received 2880 bytes, in 0.0 seconds
Bytes per second: sent 6833628.7, received 5701289.3
debug1: Exit status 0
t1 $

Expected behavior

firejail ssh -N -f -L ... should connect, establish a listener, and background itself.

Actual behavior

The ssh connection exits after successful authentication, rather than backgrounding itself.

Behavior without a profile

What changed calling LC_ALL=C firejail --noprofile /path/to/program in a
terminal?

The ssh connection establishes a listener, but does not exit - behaves the same as when no -f was specified.

Additional context

No changes I experimented with in ssh.profile changed the behavior except for commenting out deterministic-shutdown: once I did that, it behaves like the no--f or --noprofile cases: the listener is set up, but the ssh does not background itself.

Environment

Name/version/arch of the Linux kernel (uname -srm): Linux 6.6.83-gentoo x86_64
Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Gentoo Linux
Name/version of the relevant program(s)/package(s) (e.g. "firefox 134.0-1,
mesa 1:24.3.3-2"): openssh-10.0_p1
Version of Firejail (firejail --version): 0.9.74
If you use a development version of firejail, also the commit from which it
was compiled (git rev-parse HEAD):

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
- I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
[n/a] I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program

$ LC_ALL=C firejail /usr/bin/ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address]
           [-c cipher_spec] [-D [bind_address:]port] [-E log_file]
           [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file]
           [-J destination] [-L address] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-P tag] [-p port] [-R address]
           [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
           destination [command [argument ...]]
       ssh [-Q query_option]

Output of LC_ALL=C firejail --debug /path/to/program

output goes here

Originally created by @hlein on GitHub (May 1, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6730 ### Description `firejail ssh -N -f -L ...` will exit after successful authentication, rather than background and wait. Running without `-f` works as expected, although of course that means not backgrounding. _Describe the bug_ ### Steps to Reproduce ``` # Start w/no listener t1 $ netstat -antp 2>/dev/null | egrep 1111 # Regular no-firejail works - backgrounds w/persistent listener process t1 $ /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost t1 $ netstat -antp 2>/dev/null | egrep 1111 tcp 0 0 127.0.0.1:1111 0.0.0.0:* LISTEN 1913/ssh tcp6 0 0 ::1:1111 :::* LISTEN 1913/ssh t1 $ kill 1913 # Running firejail w/-f exits successfully but w/no listener t1 $ firejail /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost t1 $ echo $? 0 t1 $ netstat -antp 2>/dev/null | egrep 1111 # Running firejail w/o -f works, but ofc doesn't background t1 $ firejail /usr/bin/ssh -N -L 1111:127.0.0.1:1112 localhost t2 $ netstat -antp 2>/dev/null | egrep 1111 tcp 0 0 127.0.0.1:1111 0.0.0.0:* LISTEN 2154/ssh tcp6 0 0 ::1:1111 :::* LISTEN 2154/ssh ``` Throwing in some `-v`'s and/or verbose server logs doesn't really tell us anything new: ``` t1 $ firejail /usr/bin/ssh -N -f -vvv -L 1111:127.0.0.1:1112 localhost debug1: OpenSSH_10.0p2, OpenSSL 3.2.4 11 Feb 2025 ... Authenticated to 127.0.0.1 ([127.0.0.1]:52) using "publickey". debug1: Local connections to LOCALHOST:1111 forwarded to remote address 127.0.0.1:1112 debug3: channel_setup_fwd_listener_tcpip: type 2 wildcard 0 addr NULL debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Local forwarding listening on ::1 port 1111. debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new port-listener [port listener] (inactive timeout: 0) debug1: Local forwarding listening on 127.0.0.1 port 1111. debug2: fd 5 setting O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 1: new port-listener [port listener] (inactive timeout: 0) debug2: fd 3 setting TCP_NODELAY debug3: set_sock_tos: set socket 3 IP_TOS 0x48 debug1: Requesting no-more-sessions@openssh.com debug3: send packet: type 80 debug1: forking to background debug1: Entering interactive session. debug1: pledge: filesystem debug3: client_repledge: enter debug3: send packet: type 1 debug1: channel 0: free: port listener, nchannels 2 debug3: channel 0: status: The following connections are open: debug1: channel 1: free: port listener, nchannels 1 debug3: channel 1: status: The following connections are open: Transferred: sent 3452, received 2880 bytes, in 0.0 seconds Bytes per second: sent 6833628.7, received 5701289.3 debug1: Exit status 0 t1 $ ``` ### Expected behavior `firejail ssh -N -f -L ...` should connect, establish a listener, and background itself. ### Actual behavior The ssh connection exits after successful authentication, rather than backgrounding itself. ### Behavior without a profile _What changed calling `LC_ALL=C firejail --noprofile /path/to/program` in a terminal?_ The ssh connection establishes a listener, but does not exit - behaves the same as when no `-f` was specified. ### Additional context No changes I experimented with in `ssh.profile` changed the behavior except for commenting out `deterministic-shutdown`: once I did that, it behaves like the no-`-f` or `--noprofile` cases: the listener is set up, but the `ssh` does not background itself. ### Environment - Name/version/arch of the Linux kernel (`uname -srm`): Linux 6.6.83-gentoo x86_64 - Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Gentoo Linux - Name/version of the relevant program(s)/package(s) (e.g. "firefox 134.0-1, mesa 1:24.3.3-2"): openssh-10.0_p1 - Version of Firejail (`firejail --version`): 0.9.74 - If you use a development version of firejail, also the commit from which it was compiled (`git rev-parse HEAD`): ### Checklist  - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [x] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [n/a] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages) ### Log <details> <summary>Output of <code>LC_ALL=C firejail /path/to/program</code></summary> <p> ``` $ LC_ALL=C firejail /usr/bin/ssh usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]] ssh [-Q query_option] ``` </p> </details> <details> <summary>Output of <code>LC_ALL=C firejail --debug /path/to/program</code></summary> <p>  ``` output goes here ``` </p> </details>

gitea-mirror commented

2026-05-05 09:56:08 -06:00

Author

Owner

@hlein commented on GitHub (May 16, 2025):

So looking around I see some other issues that are similar / may have the same root cause, although I wouldn't necessarily say this is a dupe of them:

Firejail breaks daemonizing processes (currently open)

ControlSocket failed behaviour with ssh (closed but with a workaround of "don't use firejail", not a real fix)

ssh-agent: eval hangs without --deterministic-shutdown (currently open with a workaround of "don't background")

Also, I realized that -f is not the only way to cause this; the ssh_config setting ForkAfterAuthentication triggers the same behavior in ssh.

@hlein commented on GitHub (May 16, 2025): So looking around I see some other issues that are similar / may have the same root cause, although I wouldn't necessarily say this is a dupe of them: [Firejail breaks daemonizing processes](https://github.com/netblue30/firejail/issues/3491#top) (currently open) [ControlSocket failed behaviour with ssh](https://github.com/netblue30/firejail/issues/1518#top) (closed but with a workaround of "don't use firejail", not a real fix) [ssh-agent: eval hangs without --deterministic-shutdown](https://github.com/netblue30/firejail/issues/5751#top) (currently open with a workaround of "don't background") Also, I realized that `-f` is not the only way to cause this; the `ssh_config` setting `ForkAfterAuthentication` triggers the same behavior in `ssh`.