Description of problem: When I try to connect to a remote desktop via ssh tunnelinging, the most of cases gives the next error: Error creating the SSH tunnel Error reading from Unix: Input/output error I have to try several times before obtaining a successful connection Version-Release number of selected component (if applicable): 2.30.2 How reproducible: trying to connect to a remote desktop via ssh tunneling Steps to Reproduce: 1.Define a connection to a remote descktop via local ssh tunneling. 2.try to connect. 3.get the error Actual results: Error creating the SSH tunnel Error reading from Unix: Input/output error Expected results: A succesful connection Additional info:
if you use another computer to ssh tunnel instead of localhost works fine
I am seeing the same problem here. > if you use another computer to ssh tunnel instead of localhost works fine Nice idea. Unfortunately, the use case for VNC over ssh is exactly to just open the VNC ports for localhost, and disallow access from any "real" network. I have looked at this problem with strace here. vinagre forks ssh like this: 8291 execve("/usr/bin/ssh", ["ssh", "-f", "-L", "5599:172.25.253.64:5900", "-oForwardX11=no", "-oForwardAgent=no", "-oProtocol=2", "-p", "22", "-l", "martin", "172.25.253.64", "echo", "ViNagRE_CHEck;", "sleep", "15", ...], [/* 79 vars */]) = 0 The ssh process connects successfully and sets up IPv4 and IPv6 listening sockets 8291 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5 8291 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 8291 bind(5, {sa_family=AF_INET, sin_port=htons(5599), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 8291 listen(5, 128) = 0 ... 8291 socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 6 8291 setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 8291 setsockopt(6, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 8291 bind(6, {sa_family=AF_INET6, sin6_port=htons(5599), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id= 0}, 28) = 0 ... But then... 8291 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7358748) = 8293 8291 exit_group(0) = ? 8293 --- SIGHUP (Hangup) @ 0 (0) --- ssh forks a child process and exits, and the child sees SIGHUP right away. SIGHUP is delivered when "Hangup detected on controlling terminal". More precisely: 1. vinagre_vnc_tunnel_create() adds the "-f" parameter ("fork into background") to the ssh command line to be exec()d. 2. spawn_ssh() calls pty_open() with flag PTY_REAP_CHILD. 3. _pty_open_unix98() forks and calls setsid() before executing ssh because of the PTY_REAP_CHILD flag. This makes the newly forked process the process group leader, and detaches it from a controlling terminal. 4. ssh is executed with "-f" flag. Thus it forks after establishing the connection, and exits immediately. 5. The child is sent SIGHUP. To solve this problem, either the a) "-f" flag must be ommitted from the ssh command line in step 1.), or b) PTY_REAP_CHILD must be cleared in step 2.), or c) _pty_open_unix98() must include code to ignore SIGHUP. I verified that both approaches a() and b) actually fix the problem. However I am not certain if this is right, after all. According to POSIX standards (see http://code.activestate.com/recipes/278731-creating-a-daemon-the-python-way/download/1/, for example), SIGHUP shouldn't be sent here (the exiting process has no controlling terminal, and there are no stopped jobs in the session). I tested the same under F14 and did not see the problem.
Correction: What vinagre actually does in pty_open is like this: 1. obtain a pty, 2. fork(), 3. child fork()s again abd terminates, 4. grandchild calls setsid(), detaching from terminal, 5. opens the pty fd and issues TIOCSCTTY on it. This attaches the grandchild to a new controlling terminal, 6. exec ssh, 7. fork again (because of "-f") and terminate parent This causes the great-grandchild to receive SIGHUP as now there is a controlling terminal, and the session leader has terminated. This is clearly broken. It is probably a matter of timing whether the SIGHUP arrives after ssh blocked it or before. In the former case, the connection succeeds, in the latter case, we get "Error reading from Unix: Input/output error ".
Created attachment 487676 [details] test program The attached test mimics the behavior of vinagre when it spawns ssh. The only difference is that it uses a signal handler to catch SIGHUP (to show the effect). On my system, I see SIGHUP arrive all the time.
The potential fix is pretty easy. If a pty is used, the ssh "-f" parameter should be ommitted. However there are several different code paths in vinagre (for systems with and without PTYs and different versions of ssh), so it's not easy for me to come up with a patch. Alternatively, SIGHUP should be set to SIG_IGN before exec'ing ssh. I am not sure about potential side effects either, though.
Same thing here with vinagre-3.0.0-2.fc15.x86_64.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
In F14 the problem still exists.
In F15 the problem still exists.
Sorry for the noise - 3.0.1-3.fc15 is the version I'm using.
I seem to remember this was fixed in F14... after upgrade am having to manually set up the SSH tunnel.
Created attachment 528355 [details] Patch to fix a bug where read() on the ssh PTY master fails with EIO due to ssh closing the inherited PTY slave before opening /dev/tty I have investigated this on the upstream bug report at https://bugzilla.gnome.org/show_bug.cgi?id=644432 and the SIGHUP problem is not the only issue. There is a separate, 100%-reproducible "Input/output error" issue that happens before even getting the password prompt. This is caused by ssh enumerating and closing its file descriptors, which causes the PTY slave to be closed and thus an EIO to be delivered to the PTY master in read(). I have submitted a patch for that issue on the upstream report. I'm attaching it here too for convenience. With this patch, SSH tunneling works most of the time. The SIGHUP problem only occasionally occurs for me.
Not working in F16 with vinagre-3.2.1-1.fc16.x86_64
Confirming as not working on F16 with 3.2.1-2.fc16
Not working either on F17 with vinagre-3.4.2-1.fc17.x86_64
Still here with vinagre-3.6.2-1.fc18.x86_64
Fedora 19 vinagre-3.8.2-1.fc19.x86_64 remote desktop via VNC and local SSH tunneling works fine.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Tested in F20 and it works. It would help if there were better documentation, but that's a different issue.