5

Note, I am running these systems on VMWare Player.

Referencing this Arrow keys, tab-complete not working, it seems I should check to be sure my remote shell is running bash. My session is bash according to

echo $0
bash

Yet my arrow keys and escape key still print the following respectively

^[[D^[[A^[[B^[[C^[

Why are the key mappings so wonky?

Note: Bash and SSH version on server are a bit old (see comments). Client is up to date.

UPDATE: I logged into the actual machine and the escape keys etc are working. It's just that when I connect with the remote shell they fail to work.

Info5ek
  • 251

1 Answers1

3

From your previous question we know that you're dealing with an older Ubuntu system and bash 3.2 version.

Some of the shells don't come with readline library support (see my related question about this), which is what causes the control characters to show up on screen. Good example of that is Korn shell and Dash. I couldn't find whether or not bash 3.2 comes with readline library support. I'll ask around to make sure.

However, based on the output of locate readline.so you provided in the comments, it seems like your bash indeed is missing that library. Here's output of the same command from my system with bash 4.3.

$ locate readline.so                                                           
/lib/x86_64-linux-gnu/libreadline.so.5
/lib/x86_64-linux-gnu/libreadline.so.5.2
/lib/x86_64-linux-gnu/libreadline.so.6
/lib/x86_64-linux-gnu/libreadline.so.6.3

You could attempt to run set enable-keypad on but I doubt this will have any effect without readline library present.

The obvious solution would be to upgrade bash, but since you need this system for infosec studies, i assume you might want to keep it as is.


I've asked a related question on unix.stackexchange.com. You can check if bash uses readline with nm command , as shown in Thomas's answer

Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
  • I've updated this with additional information. – Info5ek Sep 21 '16 at 06:19
  • @user1800340 Noted. That's quite odd that it doesn't work only via ssh. Can you provide the ssh server and client versions that you're using ? And might be silly question, but is your login shell set to /bin/sh ? – Sergiy Kolodyazhnyy Sep 21 '16 at 06:26
  • Hello again good friend. No, the login shell is set to bin/bash, but the shell subprocess that gets created when I connect is sh, so that's what I get. Previously I tested upgrading to bash which still failed to enable the desired key bindings. Also, I'm not sure it's ssh, it's actually a connection through a vulnerable port opened by VSFTPD which enables me to access the victim machine and gain a shell with root privileges. – Info5ek Sep 21 '16 at 06:40
  • Server/victim machine: OpenSSH_4.7p1 Debian-8ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 ................ Client/Attacker machine: OpenSSH_7.3p1 Debian-1, OpenSSL 1.0.2h 3 May 2016 – Info5ek Sep 21 '16 at 16:24