Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: OpenSSH TCP forwarding / ProxyJump stopped working after the Fedora 44 SELinux policy change that removed the permissive setting for sshd_auth_t and sshd_session_t. The affected Fedora host is used as an SSH jump host. This configuration had worked for a long time. A connection such as: ssh -W 192.0.2.10:22 jump-host now fails with: channel 0: open failed: connect failed: open failed stdio forwarding failed The destination is reachable normally from the jump host: $ nc -vz 192.0.2.10 22 Ncat: Connected to 192.0.2.10:22. sshd is configured to permit forwarding: gatewayports no allowtcpforwarding yes disableforwarding no permitopen any permitlisten any The failure generates this SELinux AVC: avc: denied { name_connect } comm="sshd-session" dest=22 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_port_t:s0 tclass=tcp_socket permissive=0 Making only sshd_session_t permissive immediately restores TCP forwarding / ProxyJump. The stock SELinux policy also appears to lack the required permission. With no local policy module installed: # sesearch -A \ -s sshd_session_t \ -t ssh_port_t \ -c tcp_socket \ -p name_connect allow nsswitch_domain reserved_port_type:tcp_socket name_connect; [ nis_enabled ]:True There is no sshd_session_t -> ssh_port_t:tcp_socket name_connect allow rule. Installing a minimal local policy containing: allow sshd_session_t ssh_port_t:tcp_socket name_connect; restores ProxyJump while SELinux and sshd_session_t remain enforcing. Removing that module immediately reproduces the failure, and reinstalling it restores forwarding. This appears to be a policy gap exposed when sshd_session_t changed from permissive to enforcing. Version-Release number of selected component (if applicable): Fedora Linux 44 x86_64 selinux-policy-44.7-1.fc44 selinux-policy-targeted-44.7-1.fc44 openssh-10.2p1-14.fc44 openssh-server-10.2p1-14.fc44 The selinux-policy changelog for both 44.6-1 (2026-08-14) and 44.7-1 (2026-08-22) contains: - Remove permissive setting for sshd_auth_t and sshd_session_t How reproducible: Always. Steps to Reproduce: 1. On a Fedora 44 SSH server with SELinux enforcing, configure OpenSSH to allow TCP forwarding. In this case the effective configuration is: allowtcpforwarding yes disableforwarding no permitopen any Ensure sshd_session_t is enforcing and no local SELinux module grants it name_connect to ssh_port_t. Verify that an SSH destination is directly reachable from the server: nc -vz 192.0.2.10 22 2. From an SSH client, attempt OpenSSH direct-tcpip forwarding through the Fedora server: ssh -W 192.0.2.10:22 jump-host An equivalent ProxyJump configuration reproduces the same failure. 3. Examine the audit log: ausearch -m AVC,USER_AVC -ts recent The forwarding attempt produces: avc: denied { name_connect } comm="sshd-session" dest=22 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_port_t:s0 tclass=tcp_socket permissive=0 As a confirmation, making only this domain permissive: semanage permissive -a sshd_session_t causes the identical SSH forwarding operation to succeed. Alternatively, leave the domain enforcing and install a local policy containing: allow sshd_session_t ssh_port_t:tcp_socket name_connect; The forwarding operation also succeeds. Remove that rule and the failure immediately returns. Actual results: OpenSSH successfully authenticates to the Fedora jump host, but the server cannot create the requested direct-tcpip connection: Authenticated to jump-host using "publickey". channel_connect_stdio_fwd: 192.0.2.10:22 channel 0: open failed: connect failed: open failed stdio forwarding failed SELinux denies: sshd_session_t -> ssh_port_t:tcp_socket name_connect even though the same destination and TCP port are directly reachable from an ordinary process on the Fedora host. Expected results: When OpenSSH is configured with: AllowTcpForwarding yes DisableForwarding no PermitOpen any an authenticated SSH session should be able to create an allowed direct-tcpip connection. In particular, sshd_session_t should be permitted to connect to ssh_port_t as required for SSH ProxyJump / TCP forwarding to an SSH destination. The operation should work with SELinux enforcing without requiring sshd_session_t to be made permissive or requiring a local SELinux policy module. Additional info: The problem was isolated from networking and the destination SSH service: * Direct ping from the Fedora jump host to the destination succeeds. * Direct nc -vz 192.0.2.10 22 succeeds. * Packet capture shows the destination completing the TCP handshake and advertising its OpenSSH server. * The destination sshd is listening on TCP/22. * sshd -T on the Fedora host reports allowtcpforwarding yes, disableforwarding no, and permitopen any. * The authenticated SSH key permits port forwarding. * Making only sshd_session_t permissive restores forwarding. * Returning sshd_session_t to enforcing reproduces the failure. * A local module granting only sshd_session_t ssh_port_t:tcp_socket name_connect restores forwarding while SELinux remains enforcing. * Removing that local module reproduces the failure. * Reinstalling it restores forwarding. The temporary local workaround currently in use is: module sshd-session-forward 1.0; require { type sshd_session_t; type ssh_port_t; class tcp_socket name_connect; } allow sshd_session_t ssh_port_t:tcp_socket name_connect; With this module installed: # sesearch -A \ -s sshd_session_t \ -t ssh_port_t \ -c tcp_socket \ -p name_connect allow nsswitch_domain reserved_port_type:tcp_socket name_connect; [ nis_enabled ]:True allow sshd_session_t ssh_port_t:tcp_socket { name_bind name_connect }; After removing the local module, the sshd_session_t rule disappears and forwarding fails again. This behavior began after the recent Fedora 44 policy update. The selinux-policy 44.6/44.7 changelog specifically includes removal of the permissive setting for sshd_auth_t and sshd_session_t. The hostname and IP addresses in this report have been replaced with generic examples. 192.0.2.0/24 is used as a documentation-only address range; the actual destination is an internal RFC1918 host.
The same regression also breaks an SSH dynamic/SOCKS tunnel used to reach an internal HTTPS management interface through the Fedora jump host. The existing local workaround permitting sshd_session_t to connect to ssh_port_t restores ProxyJump to TCP/22 but does not restore SOCKS forwarding to TCP/443. The latter generates the corresponding sshd_session_t name_connect denial for the HTTPS port type. This indicates the issue affects OpenSSH direct-tcpip forwarding generally, not only ProxyJump to SSH destinations.
Also X11 forwarding is broken by this update (selinux-policy-44.7-1.fc44 and/or selinux-policy-targeted-44.7-1.fc44) ssh -X <host> gives "X11 forwarding request failed on channel 0". This can be reverted by downgrading the two packages.
(In reply to Eiríkur Hjartarson from comment #2) after "ssh -X localhost", the journal contains: ágú 26 06:51:31 <hostname> audit[58017]: AVC avc: denied { create } for pid=58017 comm="sshd-session" name="s.ymxZI2eThm.sshd.tTixg7DZSf" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_home_t:s0 tclass=sock_file permissive=0
(In reply to Eiríkur Hjartarson from comment #2) Ignore my last reply, I forgot to include the '-X' on the command line. Actually, after "ssh -X localhost", the journal contains 994 lines, the first being: ágú 26 07:03:18 fern.skulax.is audit[58662]: AVC avc: denied { create } for pid=58662 comm="sshd-session" name="s.ymxZI2eThm.sshd.UJnnqCwC8W" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_home_t:s0 tclass=sock_file permisstheive=0 the rest having "denied { name_bind }" and the first being: ágú 26 07:03:18 fern.skulax.is audit[58662]: AVC avc: denied { name_bind } for pid=58662 comm="sshd-session" src=6010 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xserver_port_t:s0 tclass=tcp_socket permissive=0 and the rest differing only in src=???? and having tcontext tcontext=system_u:object_r:afs3_callback_port_t:s0 tcontext=system_u:object_r:afs_pt_port_t:s0 tcontext=system_u:object_r:couchdb_port_t:s0 tcontext=system_u:object_r:cyphesis_port_t:s0 tcontext=system_u:object_r:gatekeeper_port_t:s0 tcontext=system_u:object_r:geneve_port_t:s0 tcontext=system_u:object_r:ircd_port_t:s0 tcontext=system_u:object_r:mpd_port_t:s0 tcontext=system_u:object_r:mythtv_port_t:s0 tcontext=system_u:object_r:openflow_port_t:s0 tcontext=system_u:object_r:openvswitch_port_t:s0 tcontext=system_u:object_r:ovsdb_port_t:s0 tcontext=system_u:object_r:redis_port_t:s0 tcontext=system_u:object_r:repository_port_t:s0 tcontext=system_u:object_r:sge_port_t:s0 tcontext=system_u:object_r:swift_port_t:s0 tcontext=system_u:object_r:syslog_tls_port_t:s0 tcontext=system_u:object_r:tor_port_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tcontext=system_u:object_r:varnishd_port_t:s0 tcontext=system_u:object_r:xodbc_connect_port_t:s0 tcontext=system_u:object_r:xserver_port_t:s0
Just adding my .02, but this also breaks remote socket forwarding into user_tmp_t (/run/user, in my specific case) which I use for forwarding my gpg agent. type=AVC msg=audit(1787753063.544:1576): avc: denied { create } for pid=265989 comm="sshd-session" name="S.gpg-agent" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1787753063.544:1577): avc: denied { create } for pid=265989 comm="sshd-session" name="S.gpg-agent.ssh" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 easy enough to create a policy for temporarily, but figured I'd add it to the list.
I can reproduce the same AVC without using OpenSSH agent forwarding with pam_ssh-2.3-22.fc44.x86_64 on a Fedora 44 VPS. My PAM stack uses: auth [success=1 default=ignore] pam_systemd_home.so auth sufficient pam_unix.so try_first_pass nullok auth sufficient pam_ssh.so use_first_pass debug auth required pam_deny.so pam_ssh reuses the password to decrypt private keys and starts a server-side ssh-agent during session setup. Creation/access of its socket under ~/.ssh/agent/ is denied: comm="sshd-session" denied { write } scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:ssh_home_t:s0 tclass=sock_file permissive=0 This causes the SSH session to close immediately after successful public-key authentication with very no information on the client side, I had to use the web console to troubleshoot as I was locked out from the VPS. Permissive mode works, and downgrading the SELinux policy restores login with enforcing mode enabled. Thus, the impact with pam_ssh is complete SSH login failure.
I expect this issue will be resolved with today's build, but keeping this bz open since there is some uncertainty.
selinux-policy-44.8-1.fc44 seems to fix sshd_session_t not being allowed to create sockets. It does look like arbitrary SOCKS5 proxy use with -D is still broken though. eg I get a denial when trying to connect to an https host when attempting to proxy through my ssh connection. type=AVC msg=audit(1787928788.694:2769): avc: denied { name_connect } for pid=375133 comm="sshd-session" dest=443 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
Using selinux-policy-44.8-1.fc44, I see no problems regarding X11 forwarding in the journal (and I can also launch X-applications remotely). Thanks.
selinux-policy-44.8-1.fc44.noarch still denies ssh -L access to Cockpit and Syncthing. audit[150220]: AVC avc: denied { name_connect } for pid=150220 comm="sshd-session" dest=9090 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:websm_port_t:s0 tclass=tcp_socket permissive=0 sshd-session[150220]: error: connect to localhost port 9090 failed: Permission denied audit[150220]: AVC avc: denied { name_connect } for pid=150220 comm="sshd-session" dest=8384 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0 sshd-session[150220]: error: connect to localhost port 8384 failed: Permission denied
Hello, using the 44.8 update, I can again log in with pam_ssh in the stack. Thanks!
Sorry for the double posting, while I can ssh into my server, using -D on my client is still not working: type=AVC msg=audit(): avc: denied { name_connect } for pid=1234 comm="sshd-session" dest=443 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
Same here. Working remotely is a bit tricky today... :-(
If you need a temporary workaround you could do 'semanage permissive -a sshd_session_t' which would make sshd_session_t permissive again
For anyone wanting a more targeted port forwarding policy as a temporary workaround instead of removing all sshd_session_t constraints: Create sshd-port-forward.te: module sshd-port-forward 1.0; require { type sshd_session_t; type reserved_port_t; type hi_reserved_port_t; type ephemeral_port_t; type unreserved_port_t; class tcp_socket name_connect; } allow sshd_session_t reserved_port_t:tcp_socket name_connect; allow sshd_session_t hi_reserved_port_t:tcp_socket name_connect; allow sshd_session_t ephemeral_port_t:tcp_socket name_connect; allow sshd_session_t unreserved_port_t:tcp_socket name_connect; Install: checkmodule -M -m -o sshd-port-forward.mod sshd-port-forward.te semodule_package -o sshd-port-forward.pp -m sshd-port-forward.mod sudo semodule -i sshd-port-forward.pp Uninstall: sudo semodule -r sshd-port-forward
Same regression with local port forwarding (ssh -L) to a VNC server, still present in selinux-policy-targeted-44.8-1.fc44. Setup: x11vnc listening on 127.0.0.1:5900 on the Fedora 44 host, client connects through an SSH local port forward (-L 46791:localhost:5900). sshd -T reports allowtcpforwarding yes, disableforwarding no. Connecting to 127.0.0.1:5900 directly on the host works (server answers with its RFB version string), but the forwarded connection is closed immediately. Sep 11 07:18:04 nl-f audit[12308]: AVC avc: denied { name_connect } for pid=12308 comm="sshd-session" dest=5900 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket permissive=0 Sep 11 07:18:04 nl-f sshd-session[12308]: error: connect to localhost port 5900 failed: Permission denied So vnc_port_t is another target type that needs to be covered, in addition to ssh_port_t, http_port_t, websm_port_t and unreserved_port_t reported above. The targeted workaround from comment 15 does not cover it either. Versions: selinux-policy-targeted-44.8-1.fc44.noarch openssh-server-10.2p1-14.fc44.x86_64 Workaround in use: semanage permissive -a sshd_session_t
There probably needs to be some booleans to control these different rules. One could conceivably want to allow forwarding UNIX sockets but not TCP, or only allow ProxyJump, etc. My work-around so far, though, has been to allow `port_type` instead of enumerating all the types: ```sh cat > bz2523732.cil <<EOF (allow sshd_session_t port_type (tcp_socket (name_connect))) (allow sshd_session_t ssh_home_t (sock_file (create))) EOF semodule -i bz2523732.cil ```
I think (perhaps in a later fedora version) a few booleans that can be used to tune this behavior is a great idea, so long as it's communicated and documented well. Being able to easily lock down sshd more is desirable. But the current state is a regression from long standing behavior, people expect that sshd should be able to create these arbitrary sockets and/or tcp connections because they've been able to do so for a very long time.
FEDORA-2026-1413268892 (selinux-policy-44.9-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1413268892
selinux-policy-44.9-1 seems to resolve the issue for my cases with -D.
FEDORA-2026-1413268892 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1413268892` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1413268892 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-1413268892 (selinux-policy-44.9-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Hmm, should have tested more thoroughly. Looks like it's still causing issues for some of my less common workflows. Using -L to forward port 8000 or 9090 is denied for example. ---- time->Wed Sep 16 09:26:29 2026 type=AVC msg=audit(1789568789.236:1601): avc: denied { name_connect } for pid=453265 comm="sshd-session" dest=8000 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:soundd_port_t:s0 tclass=tcp_socket permissive=0 ---- time->Wed Sep 16 09:27:07 2026 type=AVC msg=audit(1789568827.348:1678): avc: denied { name_connect } for pid=453629 comm="sshd-session" dest=9090 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:websm_port_t:s0 tclass=tcp_socket permissive=0
Thanks. With the -D option, it now works as it did before.
Still reproducible with selinux-policy-targeted-44.9-1.fc44: local port forwarding (ssh -L) to a VNC server is denied, as reported in comment 16. # rpm -q selinux-policy-targeted selinux-policy-targeted-44.9-1.fc44.noarch # sesearch -A -s sshd_session_t -t vnc_port_t -c tcp_socket -p name_connect (no output) # semanage permissive -d sshd_session_t time->Thu Sep 17 07:42:09 2026 type=AVC msg=audit(1789623729.494:905): avc: denied { name_connect } for pid=24750 comm="sshd-session" dest=5900 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket permissive=0 So vnc_port_t (5900) is still not covered, same as soundd_port_t and websm_port_t in comment 23. The 44.9 rules appear to cover only ports without a dedicated type, not the named port types. Back on "semanage permissive -a sshd_session_t" here for now.
For reference, the complete set of allowed target types under selinux-policy-targeted-44.9-1.fc44 on my system: # sesearch -A -s sshd_session_t -c tcp_socket -p name_connect allow sshd_session_t ephemeral_port_t:tcp_socket name_connect; allow sshd_session_t gnome_remote_desktop_port_t:tcp_socket name_connect; allow sshd_session_t http_port_t:tcp_socket name_connect; allow sshd_session_t port_t:tcp_socket name_connect; allow sshd_session_t ssh_port_t:tcp_socket { name_bind name_connect }; allow sshd_session_t unreserved_port_t:tcp_socket name_connect; So forwarding to any unnamed port above 1024 (unreserved_port_t, port_t) now works, while ports that have a dedicated type do not - vnc_port_t (5900) here, soundd_port_t (8000) and websm_port_t (9090) in comment 23. Is that distinction intended? If so, it might be worth documenting; if not, the named types used by common tunnelled services would need to be added as well.