Bug 651449

Summary: ssh prints bogus error messages when trying to access abstract sockets
Product: [Fedora] Fedora Reporter: Wolfgang Denk <wd>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 14CC: jchadima, mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-09 11:09:43 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Wolfgang Denk 2010-11-09 10:49:21 EST
Description of problem:

Starting with Fedora 14 I see the following issue:
I use ssh to log into another system and then start any X11 application there.
I will get a strange "connect : Connection refused" message, even though
everything appears to be working fine.

It seems that openssh has now support for "abstract sockets", but does
not support this correctly.

Version-Release number of selected component (if applicable):

openssh-clients-5.5p1-22.fc14.2.x86_64

How reproducible:


Steps to Reproduce:
1. run 'ssh some_host xeyes' (or any other application like xterm etc.)

Actual results:

I see this:

-> ssh pollux xeyes
connect : Connection refused

(the application gets started fine nevertheless).

Expected results:

No such error message.

Additional info:

Running the command with strace I see this:

strace -e connect -f ssh pollux xeyes
...
3251  --- SIGCHLD (Child exited) @ 0 (0) ---
3250  --- SIGCHLD (Child exited) @ 0 (0) ---
3250  connect(7, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X9"}, 110) = -1 ECONNREFUSED (Connection refused)
3250  connect(7, {sa_family=AF_FILE, path="/tmp/.X11-unix/X9"}, 110) = 0
3250  --- SIGINT (Interrupt) @ 0 (0) ---

Here we can see that ssh first tries to open an "abstract socket",
which does not exist, before it tries to use the existing AF_UNIX socket,
which then completes fine.

In this case no error message should be printed.


Actually I recommend to remove support for abstract sockets completely. This is a highly unportable and intransparent feature.
Actually I consider this a security risk (which is the reason for assigning
this a high prio), as I am not aware of any protections (no file permissions
or similar), and you cannot even check which "abstract sockets" exist or not.

What a crap!
Comment 1 Tomas Mraz 2010-11-09 11:09:43 EST
As the connect to the abstract socket happens on the ssh client and all your X clients on the ssh client already try to connect to the abstract socket there is no additional security risk involved.

*** This bug has been marked as a duplicate of bug 648896 ***