43

When I ssh into another Ubuntu machine with my account (with sudo permissions), my backspace key generates some awkward symbols on pressing. Also Tab, Del and Arrow keys don't work.

On the other hand, I also have another account on the same machine & when I ssh through this account, its terminal works perfectly fine. I couldn't figure out why is this happening.

|improve this question
  • I have the same problem - my host is Win7-64 and my remote guest systems are both Ubuntu Server 10.04. On one server, the keys work, on another, not. – Mateng Oct 26 '12 at 12:05
  • Additonal Info: I enter the remote machines with Putty / Kitty – Mateng Oct 26 '12 at 15:11
  • Can you try to ssh via a different program, or create a new profile for the target system? – belacqua Oct 26 '12 at 15:57
  • I faced the problem with cygwin (in win 7) too – gopi1410 Oct 27 '12 at 14:28
  • What is returned by typing echo "$TERM", when this occurs? – david6 Oct 28 '12 at 9:48

10 Answers 10

31
+50

EDIT: Reference: Mateng's answer

Mateng is close in that I think you're probably running Bourne Shell. But you shouldn't be editing your /etc/passwd file directly. Try using the chsh command instead:

chsh -s /bin/bash

The -s flag will make the new shell (Bash in this case) your login shell, going forward.

|improve this answer
  • Seems legit. If gopi1410 agrees, the 50 reps are yours. – Mateng Oct 30 '12 at 15:11
  • @Mateng: agreed, & a link to your answer added to make it complete – gopi1410 Oct 31 '12 at 12:46
  • 1
    Run as root: sudo chsh -s /bin/bash – KrisWebDev Sep 5 '15 at 8:48
  • 1
    @Worked for me more than 3 years later. Thank you so much! You're awesome! – goncalotomas Feb 11 '16 at 22:46
17

The following changes solved the problem for me. First, I checked which shell was running:

$ echo $0

which returned: 

/bin/sh

As I read in this post in Ubuntuforums, changing the shell to /bin/bash brings the solution. So I edited my user settings in /etc/passwd to:

johndoe:x:1001:104:John Doe:/home/johndoe:/bin/bash

I logged out, then logged in again. Strangely, I had to switch the shell manually (maybe some cache was active) by entering this:

/bin/bash

Voila!
[The problem arose due to a distribution update.]

|improve this answer
13

when you first ssh in, try these two commands

stty sane
export TERM=linux

I have to do this on some machines that I go into to fix exactly this problem

|improve this answer
  • 1
    I tried that, but the problem persists – Mateng Oct 26 '12 at 13:44
  • 1
    did you try term as VT100 instead of linux? what about stty erase <backspace> (<backspace> being where you actually hit the key) – Drake Clarris Oct 26 '12 at 15:57
  • With (Arrow Up):$ stty erase '^[[A' stty: invalid integer argument '\033[A'. With [Backspace]: $ stty erase '^?' it works. With [Tab]: $ stty erase ' ' no error, but then [Backspace] is back to odd behaviour. – Mateng Oct 26 '12 at 16:10
  • I tried export TERM=VT100, but no avail. – Mateng Oct 26 '12 at 16:15
  • 1
    stty tab0 does not help. I guess, some kind of general reconfiguration of xterm is necessary. Or the keymap is simply wrong? – Mateng Oct 29 '12 at 16:02
5

One of the easiest ways to fix this problem is to type /bin/bash at the command line interface prompt:

$ /bin/bash

The afore mentioned command will execute the Bourne Again Shell on top of the existing shell as a subprocess. This presents the disadvantage of utilising more resources, but nothing has to be edited and no special permissions are required. For example, in recent Kubuntu versions it will start a /bin/bash session atop the default /bin/dash command line shell interface.

To persist the changes, however, one possibility is to edit the /etc/passwd file and add/edit/replace the default shell to /bin/bash after the last ':' character in the line corresponding to the user. In order to edit this file, though, administrator privileges would be required.

|improve this answer
1

'Gbnome Terminal' does not exactly emulate 'xterm' ..

from: Wikipedia >> GNOME Terminal

GNOME Terminal emulates the xterm terminal emulator and provides some of the same features.

A treatise on the issue and solution(s) can be found here:

Linux Backspace/Delete mini-HOWTO

Every Linux user has been sooner or later trapped in a situation in which having working Backspace and Delete keys on the console and on X seemed impossible. This paper explains why this happens and suggests solutions. The notions given here are essentially distribution-independent: due to the widely different content of system configuration files in each distribution, I will try to give the reader enough knowledge to think up his/her own fixes, if necessary.

I assume that the Backspace key should go back one character and then erase the character under the cursor. On the other hand, the Delete key should delete the character under the cursor, without moving it. If you think that the function of the two keys should be exchanged, in spite of the fact that most keyboards feature an arrow pointing to the left (←) on the Backspace key, then this paper will not give you immediate solutions, but certainly you may find the explanations given here useful.

Simplest solution given (which may work here) is to use: bash$ export TERM=gnome

|improve this answer
1

As a root user edit /etc/passwd file for your user and change from /bin/sh to /bin/bash

hdfs:x:1020:1001::/home/hdfs:/bin/sh to hdfs:x:1020:1001::/home/hdfs:/bin/bash

This worked for me.

|improve this answer
1

I tried all the above plus notes from (this link) with no success. You may want to check vim is installed.

I usually use vi not vim. So I installed vim. 

$ sudo apt-get install vim

After that, the keyboard strokes started working properly when I executed vi. Looking at the output of the following, it looks like vi was made an alias to vim after the install:

$ ls -al /etc/alternatives | grep vi 
lrwxrwxrwx   1 root root    18 Jan 13 09:38 vi -> /usr/bin/vim.basic
|improve this answer
0

This is a compatibility issue with the keyboard, i.e., how it is interpreted in the host system. You might have to use j or h to move in the vi editor in the command mode. Arrows will not work.

Check the profile preferences->compatibility in the host system for that specific user.

|improve this answer
0

Okay, I know this isn't a "solution" per say, and it may not help many of you, but hopefully it helps at least 1 of you. It did fix my problem.

My six month old banged on my keyboard, and my arrow keys stopped working on my putty session into a Debian box. They did work everywhere else (all other programs outside of putty). After Googleing and even landing here (I was going to close this tab, it didn't solve it for me). I tried something. I opened a new ssh session to the same box, and my arrow keys worked. I joined my screen session and they did not work. So something just happened tied to the current screen session disabling the arrow keys. Unfortunately, I was (am) in the middle of a big project, have 28 windows open in my screen session, and didn't want to close the session, loosing my place on all 28 windows.

So..

While on the bash shell, I tried all combinations I could think of, of CTRL + up, down, left right, ALT + up, down, left, right, SHIFT + up, down, left right, CTRL+ALT+ up, down, left right, CTRL+SHIFT+ up, down, left right, etc. Still with no luck, I also tried the windows menu and windows app keys with up, down, left right.

Now my arrows work again! Something about one of the combinations of what is above and the arrow keys fixed it.

|improve this answer
0

None of the answers above fixed my identical problem, i.e. cannot use backspace or similar keys after sshing to a remote from an Ubuntu (here ubuntu-17.10 with ncurses-6.0).

It ends up being a problem with terminfo. Basically, my gnome-terminal says it's an xterm-256color terminal (via the TERM variable, which is exported by ssh to the remote) but the remote didn't have a terminfo configuration for xterm-256color.

Doing the following fixed the issue:

$host: echo $TERM
xterm-256color
$host: infocmp >terminfo.src
$host: tic terminfo.src
$host: scp .terminfo/x/xterm-256color $remote:/usr/share/terminfo/x/xterm-256color

infocmp, without any option, produces a source listing for the terminal in the environment variable $TERM. So it is equivalent to infocmp -I $TERM.

Then the resulting source is compiled via tic.

Finally, install the corresponding terminfo configuration to the remote location. So, the next time I connect to $remote via $host, it will know about my terminal.

|improve this answer
  • What does your block of code do? create a term config somehow? Would be nice to have some explanation, running mystery code isn't the best idea, even their man pages aren't super clear on the default effect of infocmp, or how this is useful – Xen2050 Dec 21 '17 at 1:02
  • @Xen2050: I've added an explanation for each command. infocmp without any option is equivalent to infocmp -I $TERM. This is described in the man page but in two parts: "If no options are specified and zero or one termnames are specified, the -I option will be assumed. [...] The -I, -L, and -C options will produce a source listing for each terminal named. -I use the terminfo names If no termnames are given, the environment variable TERM will be used for the terminal name." – user1448926 Mar 7 '18 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.