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.

  • 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, 2012 at 12:05
  • Additonal Info: I enter the remote machines with Putty / Kitty
    – Mateng
    Oct 26, 2012 at 15:11
  • Can you try to ssh via a different program, or create a new profile for the target system?
    – belacqua
    Oct 26, 2012 at 15:57
  • I faced the problem with cygwin (in win 7) too
    – gopi1410
    Oct 27, 2012 at 14:28
  • What is returned by typing echo "$TERM", when this occurs?
    – david6
    Oct 28, 2012 at 9:48

10 Answers 10


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.

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

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

  • 3
    I tried that, but the problem persists
    – Mateng
    Oct 26, 2012 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) Oct 26, 2012 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, 2012 at 16:10
  • I tried export TERM=VT100, but no avail.
    – Mateng
    Oct 26, 2012 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, 2012 at 16:02

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

$ echo $0

which returned:


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:


[The problem arose due to a distribution update.]


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.


'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


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.


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

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
$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.

  • 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, 2017 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." Mar 7, 2018 at 15:59

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.


If you are added as an other new user then use the following command which add you to the sudo group. This should be done using the main user account who has permission to use sudo.

$ sudo adduser username sudo
$ sudo adduser username admin

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .