RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1436097 - ssh -X shows shows error: X11 forwarding request failed on channel 0
Summary: ssh -X shows shows error: X11 forwarding request failed on channel 0
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-27 07:26 UTC by Yogita
Modified: 2020-07-16 09:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-21 21:35:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Yogita 2017-03-27 07:26:15 UTC 
Description of problem:
openssh-server with default configuration (AddressFamily any) and IPv6 disabled (net.ipv6.conf.eth0.disable_ipv6 = 1, not default) do not forward X11 requests when requested using "ssh -X server" command.

Version-Release number of selected component (if applicable):
rpm -q openssh
openssh-6.6.1p1-31.el7.x86_64

Steps to Reproduce:

Perform following steps on Server machine -

# vim /etc/sysctl.conf 
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.ens3.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.virbr0.disable_ipv6 = 1
net.ipv6.conf.virbr0-nic.disable_ipv6 = 1

reload the configuration using sysctl -p or by rebooting the server

# cat /etc/ssh/sshd_config | grep AddressFamily
AddressFamily any

# systemctl restart sshd

Actual results:
From client execute -
ssh -X server
X11 forwarding request failed on channel 0
Last login: Mon Mar 27 12:45:13 2017 from xyz

Expected results:
ssh -X server
Last login: Mon Mar 27 12:45:13 2017 from xyz

Additional info:
Moreover, related fixed bugs exists in bugrack. Maybe a regression?? (pls, read in order): 
https://bugzilla.redhat.com/show_bug.cgi?id=732955
https://bugzilla.redhat.com/show_bug.cgi?id=1173052

All rhel 7.3 with default sshd config and net.ipv6.conf.eth0.disable_ipv6 = 1 are impacted.
workaround is set sshd_config option "AddressFamily any" as stated in: 
https://access.redhat.com/solutions/110103
Comment 2 Jakub Jelen 2017-03-27 11:08:17 UTC 
To my understanding, it looks like a problem that `getaddrinfo()` is returning AF_INET6 addresses even though it is disabled "systemwide" (at least on Fedora as I tested). The related logs in my environment look like

    [...]
    debug2: bind port 6491: Cannot assign requested address
    debug3: sock_set_v6only: set socket 10 IPV6_V6ONLY
    [...]
    error: Failed to allocate internet-domain X11 display socket.

You can resolve the problem by explicitly selecting ipv4 (not `any` as mentioned in the description):

    AddressFamily  inet

Since we have this configuration option there (it is unfortunate that it does not confirm to some system-wide settings) it is not probable it will get fixed somehow. This is explained and documented in the KBS about disabling IPv6 [1] even with this limitation explained in this bug.

Adding psimerda if he can give some light into that or if there is anything we can do to improve the state.

[1] https://access.redhat.com/solutions/8709
Comment 3 Pavel Šimerda (pavlix) 2017-03-29 09:46:57 UTC 
(In reply to Jakub Jelen from comment #2)
> To my understanding, it looks like a problem that `getaddrinfo()` is
> returning AF_INET6 addresses even though it is disabled "systemwide" (at
> least on Fedora as I tested).

In my opinion you should not expect getaddrinfo to remove those addresses for you and the code should be capable of handling the case. When you try to connect to an unreachable IPv6 address, you get an error immediately and you can continue trying with the next address without delay.

In your case the problem seems to be related to binding, though. And that's another story. Can you please describe the specific usage of getaddrinfo, the upcoming network-related syscalls and the expected/actual results of those?
Comment 4 Jakub Jelen 2017-03-29 11:40:43 UTC 
Well, this was how the OpenSSH behaved before version 5.0. Current behavior was introduced by a fix for CVE-2008-1483 [1] (related commit [2]).

The related code can be found here:

https://github.com/openssh/openssh-portable/blob/master/channels.c#L4299

So from my point of view it is still either a problem in the getaddinfo() or a thing that really needs to be configured (as described in the KBS). Nothing that could be fixed in OpenSSH source code. What you mean about "another story"?


[1] http://www.openssh.com/txt/release-5.0
[2] https://github.com/openssh/openssh-portable/commit/5f5cd746
Comment 5 Jakub Jelen 2017-03-29 13:29:42 UTC 
For the record, there are upstream bugs discussion this problem for years:

https://bugzilla.mindrot.org/show_bug.cgi?id=2143
https://bugzilla.mindrot.org/show_bug.cgi?id=1356

I raised the issue on the upstream mailing list again to see if we can have it fixed in some way.
Note You need to log in before you can comment on or make changes to this bug.