SSH connection killed by Tab key

Hello,
I have a very weird problem with my ssh connection. After I log on the server for a while, when I wanted to change directory by pressing Tab key to save some typing, my connection to the server is lost!

First I checked my bash-completion setting, which I could not find any problem with, as I use exactly the same setting with my other severs with exactly the same OS (Debian, Linux server1 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) x86_64 GNU/Linux), where I do not have this problem.

I then checked my shell environment, which is bash for both my default and current shell.

It might be related to my ssh connection configuration on time-out settings, but my ssh connection settings are the same for the other servers. Any help would be greatly appreciated.

Hi,

Hmm, that is odd. OK, first question: does this happen no matter whereabouts in the filesystem you are ? In other words, does tab completion only disconnect you if you try to use it in one particular place (a sub-directory of your home directory, say), or does it happen even if you're somewhere else, like / or /tmp , say ?

Any directory, but I never worked in / though.

Hi,

OK, thanks. It could be that for some reason Bash is segfaulting or otherwise crashing when it tries to do tab completion. To check that, try the following.

  1. Log in as usual
  2. Once you're logged in, type bash to start a sub-shell
  3. Type echo $SHLVL to see your current shell level
  4. Try to do tab completion. You'll probably end up back at a Bash prompt right away
  5. Do echo $SHLVL again. If the number has gone down by one, then that's what's happening - Bash is crashing on tab completion attempts

Anyway, just a thought - this might at least tell us if it's Bash that's dying, or if something else is going on.

1 Like

On the remote box only:

Add this to your ~/.bash_profile , ~/.bash_login , or ~/.profile on the remote box:

# enable bash completion in interactive shells
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi

Thanks!

3. Type echo $SHLVL to see your current shell level
$> 2

 4. Try to do tab completion.  You'll probably end up back at a Bash prompt right away
$> (That did not happen, and nothing seemed wrong!)

5. Do echo $SHLVL again.  If the number has gone down by one, then that's what's happening - Bash is crashing on tab completion attempts
$> 

I did not see anything abnormal following to your instruction.
By the way, I should mentioned that Tab completion problem did NOT happen every time I press the Tab key, but only after certain period of time once I'm logged in, that's why I said it might be related to time-out setting. I did not measure how long that period is either.

---------- Post updated at 03:49 PM ---------- Previous update was at 03:45 PM ----------

Thanks Jim:
I have those lines in my ~/.bashrc. Do I have to put them into any of those files you mentioned?

Are you inactive for a while before trying the TAB?

Perhaps its an SSH timeout you could try ServerAliveInterval 120 in your client ~/.ssh/config to send a NULL packet every 120 seconds to avoid timeout disconnects.

It might be that you're being kicked before you hit tab, but your client doesn't notice the connection's broken until it tries to send something.

Hi,

It might also be useful here to know what client you're actually using at your end if it's something other than command-line OpenSSH (product name and version if possible).

One possibility here might be that if you're using an unusual client that doesn't actually send any output to the remote end until an event occurs that necessitates it to be sent (like an end-of-line return, or needing immediate results from a tab complete, say) that time-outs are in fact the issue.

In this situation your session only looks like its alive because your client is really just doing local echos of your own keystrokes, and your apparent immediate disconnect on tab completion happens because in reality your session has already ended.

It's unlikely (to put it mildly), but hey, it's an outside possibility I suppose, if you're using an oddly-behaved client.

Could be a firewall in between that is quietly dropping the connection after a period of inactivity and who does not inform client or server. A client-side keepalive packet could prevent that, as suggested earlier...