I am using SSH connection to log into my Raspberry Pi. I used tab completion over SSH before and that worked perfectly. But now I am getting the "connection closed" message whenever I try to use tab completion over SSH.
Linux – Tab completion closes SSH connection
linuxsshtab completion
Related Solutions
Well that was embarrassing. I just realized I have to connect using the root user, as the name of the plugin suggests.
$ ssh root@192.168.1.3 root@192.168.1.3's password: Last login: Fri Sep 13 20:30:42 2013 from 192.168.1.16 on pts/0 Linux leviathan 2.6.37.6.RNx86_64.2.4 #1 SMP Thu Jul 26 05:00:36 PDT 2012 x86_64 GNU/Linux leviathan:~#
After you login as the root user, you may edit /etc/passwd
and give your user account(s) a valid shell rather than the default of /bin/false
. Once you do that, you can ensure local user accounts don't have bad permissions on their respective .ssh
directories and then they may also get an interactive login. (You may also use password authentication.)
Change root's password — it defaults to the same default for admin
and you don't want that.
So I made a picture to illustrate our current state and help the explanation.
"A" is the computer at home, "B" is the computer at work, "C" is another computer at work.
"C" does have access to "B".
"A" does not have access to "B" and this is our problem that has to be solved.
The most common reason for this is that "B" and "C" are in the same network, "A" has to get trough the router to be able to access "B" or "C".
"B" and "C" has local IP addresses lets say for example 192.168.13.10
for "B" and 192.168.13.20
for "C". The router also has his own IP addresses one internal (ex. 192.168.13.1
) and one external (ex. 10.10.10.11
) that can be reached over the internet.
"B" and "C" can talk to each other with ease by calling each other over the local IP address, since they are in the same network if "C" wants to talk to "B" over port 22 all he has to do is open communication on 192.168.13.10:22
.
It gets a bit more complicated when "A" wants to reach "B" or "C", since there is only one IP address that can be accessed over the internet, and that is the routers external IP address: 10.10.10.11
.
What happens here is, there has to be a port forwarding on the router meaning that, lets say we want to forward all the information that the router gets on port 12345
to the port 22 of "C". So we must set up the routers port forwarding saying that inbound connection on port 12345
to be forwarded to 192.168.13.20:22
(address of computer "C")
From now on, if I want to access the port 22 of computer "C" from an external computer, I just have to connect to 10.10.10.11:12345
so in order for this to work and to be able to access computer "B" from computer "A", we must have a port forwarding in the router on a free port that refers to the internal address of computer "B"s port 22.
Best Answer
I assume the shell is
bash
.Hypothesis
There is
set -e
in one of your startup scripts. Then Tab may trigger this: Enablingset -e
in the shell causes bash-completion to terminate the shell.This is what
set -e
does:In Bash 4.4.12 in my Debian 9 I can replicate this behavior by invoking
set -e
and then using tab completion like in your screenshot.Testing the hypothesis
Run just
false
. If it exits the shell, it meansset -e
was active. If so, I expectset +e
to be an ad-hoc fix for your problem. Log in again and check ifset +e
makes the problem disappear. It should.Fixing
You don't want to run
set +e
each time you log in. The real fix is to removeset -e
from your startup scripts. Files to check:Some of them may not exist and it's normal. Not every file is used in your particular case, even if they all exist. The list is not exhaustive; these scripts can source other scripts and there is
--rcfile
option of Bash to source any file.My point is: after confirming that
set -e
is the culprit, you need to track it down in your shell startup sequence and delete it. Investigating why/how it got there may lead to interesting conclusions, but such research is probably not necessary if you just want to fix the issue in question.Note
bash -e
runs a shell withset -e
active from the start, soexec bash -e
in a startup script would give similar symptoms.