ssh hangs after inactivity (maybe when connection is lost)

[Teo]

Steps to reproduce:

1. Open a terminal
2. Write:
  ssh <email address hidden>
where myhost.com is some host where you have ssh access and user is the user name
3. Enter the password when prompted
4. Wait for several minutes or hours without doing anything
5. try to type something

Expected: either the connection is still alive, in which case you should be able to type, see what you type, and do things while logged on the remote machine, OR the connection has been closed due to inactivity, in which case ssh should show a message and gracefully quit.

Observed: ssh hangs; No message is shown; the remote machine's "prompt" is still shown and the cursor still blinks, but you are unable to type anything. You can't even quit ssh (typing "exit" has no effect) and return to normal local terminal operation. The only way out is to close the terminal (or open another one and kill the ssh process)

I guess this happens when the connection with the server is lost, probably closed by the server due to inactivity; however the client should detect this and gracefully exit.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: ssh (not installed)
ProcVersionSignature: Ubuntu 2.6.32-31.61-generic 2.6.32.32+drm33.14
Uname: Linux 2.6.32-31-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Tue May 31 18:04:56 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: openssh

[Chuck Short (zulcss)]

I am not able to reproduce on my systems, can you add your /etc/ssh/sshd_config and /etc/ssh/ssh_config?

Thanks
chuck

[Teo (teo1978)]

Here's the ssh_config.

I have no sshd_config

[Teo (teo1978)]

Oh! I guess you mean /etc/ssh/sshd_config on the server.

This is a client issue, however here is the sshd_config from the server just in case it is of any help:

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#Cli...

[Launchpad Janitor (janitor)]

[Expired for openssh (Ubuntu) because there has been no activity for 60 days.]

[teo1978 (teo8976)]

I don't know why this was closed for inactivity. I provided the information I was asked for, so this hould not have remnained in the Incomplete state in the first place.

I can still reproduce this, systematically, and I have observed it on several machines and with several servers (with different linux distributions and from different hosting providers). So I'm going to change this to "confirmed".

There is one thing worth noting, though: this seems to happen when the client is connected via WIFI (to a LAN connected to the Internet, of course), but not when connected via an ethernet cable.
So, I guess this may be triggered by a network connection issue, not by the server closing the connection?
In ANY case, the client should show a meaningful error message and quit, if the connection really is broken: not doing so is a bug for sure; and it doesn't seem there's a good reason for it breaking in the first place, either.

@zulcss please could you try if you can reproduce it when connected via wifi?

[teo1978 (teo8976)]

And by the way, who set the importance to "Low" should seriously reconsider.