20

I setup Ubuntu Linux to run an OpenSSH server. My DSL router is port forwarding the SSH connection. When I use 

ssh -X myhost

and then open some GUI program, then close the GUI application and exit, then the SSH logout hangs. <Ctrl>-c seems to work but its annoying to have to press it everytime. The logout will not hang if I don't open a GUI.

Anyone have ideas how to fix this problem?

Sigi
  • 1,784
  • 13
  • 19
admiles
  • 403
  • 1
  • 5
  • 12

4 Answers4

19

This is because the process you start opens a stream (stdout/stderr) and doesn't close it. Have a look here for a more in-depth explanation and possible solutions.

Lars Kotthoff
  • 107,425
  • 16
  • 204
  • 204
  • 2
    Quite probably this is essentially the same mechanism as referenced in your link, however it may not be stdout/stderr, but a forwarded X connection, since OP is using `ssh -X`. If there's still an open connection *of any sort* on that ssh tunnel, ssh will remain open. I have run into that when logging into a system and starting a Gnome/KDE tool/app of some sort that starts up some of the backend daemons/services, which don't necessarily go away when the application itself does... – twalberg Nov 29 '12 at 21:55
  • Thanks for the explanation and the link. Probably didn't want to hear this answer because there is no quick solution but at least I know what's going on :) – admiles Nov 30 '12 at 14:51
  • @admiles In fact, there is an easy way. See my answer below. – Sigi May 01 '14 at 17:09
  • Appending `< /dev/null >& /dev/null &` to my evince command didn't help. At least in my case, it seems to be DBus-related? – Ed Sabol Feb 01 '21 at 22:38
13

I know this is an old question but I had the same problem and after doing some digging I found a useful solution. Now I close SSH connections with ~. "terminate connection (and any multiplexed sessions)" and that works for me. The escape character needs to be typed on a new line and in my case the escape character isn't displayed onscreen (I ended up escaping the escape character, i.e. ~~). FYI you can view the forwarded connections from your SSH session with ~#.

For a full list of escape sequences type ~? in your SSH session.

Supported escape sequences:

  • ~. - terminate connection (and any multiplexed sessions)
  • ~B - send a BREAK to the remote system
  • ~C - open a command line
  • ~R - Request rekey (SSH protocol 2 only)
  • ~^Z - suspend ssh
  • ~# - list forwarded connections
  • ~& - background ssh (when waiting for connections to terminate)
  • ~? - this message
  • ~~ - send the escape character by typing it twice

(Note that escapes are only recognized immediately after newline.)

itsjeyd
  • 5,070
  • 2
  • 30
  • 49
Shaggin Shea
  • 151
  • 1
  • 4
  • This facility is enabled by default in any version of OpenSSH client that I've ever used. – Cameron Kerr Apr 30 '14 at 21:01
  • I just recommented it. It is the default on mine too, in my confusion over the escape character not being displayed I thought it had to do with the config file. The config file is a way to change defaults. Thanks for the response. – Shaggin Shea May 01 '14 at 16:53
  • Can you explain more on how to do this? The stdin is redirected to the remote shell, right? – Imperishable Night Nov 02 '17 at 22:44
  • Note that (maybe depending on your keyboard layout?) you need to type a space after `~`. And it remains invisible since it's an escape character. And the tilde remains invisible until you have typed the other character, unlike in a non-SSH terminal where it appears as soon as you have typed the space char. Took me a while to figure out... – mivk Aug 01 '21 at 17:31
1

You can send SSH to the background automatically after starting your remote GUI application:

ssh -X -f remote.host.name 'name_of_gui_application'

This will still ask for a password, then run the application and put SSH to the background immediately.

It will also redirect STDIN from /dev/null, so your session will not "hang" after you close the application (not that you'd know, since it is running in the background anyway).

Here's what the manual page of SSH has to say about this:

The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm.

Sigi
  • 1,784
  • 13
  • 19
  • 1
    This does not fix the problem, it merely hides it -- leaving a spare process and SSH connection lying around doing nothing useful (and being secretive about it, to boot). – Daniel Wagner Apr 26 '16 at 17:11
  • What does `ssh -f host xterm` even do, with no X forwarding? I'm surprised this is in the SSH manual. And Daniel is right, this only hides the problem. – Imperishable Night Oct 11 '17 at 01:14
  • @ImperishableNight It's possible to enable X forwarding in the config, and then you don't need the -X option on the command line. It's a little overconfident on your part to assume the SSH manual is wrong... – Sigi Apr 05 '18 at 18:30
  • @Sigi Fair, but it is still unnecessarily confusing to me. And there's still the "hide the problem" thing, though the ssh devs may have not expected this problem in the first place. – Imperishable Night Apr 12 '18 at 10:55
0

I know this is in no way directly answering the OP. But if you are looking for an alternate solution try exit. More can be found here!

Deekshith Anand
  • 2,175
  • 1
  • 21
  • 24