A long time ago, on networks in your community, we had "computer terminals" on our desks that talked to our computers. They may have looked like monitors with keyboard attached to them, but there was more to them than that. They had input buffers that processed what was typed on them. Function keys like the print screen key button and control key sequences could be processed locally in the terminal before sending anything to the computers. The computer could send the terminal special "Escape codes" like "ESC [ 1 2 h" (http://vt100.net/docs/vt102-ug/chapter5.html#S5.5.2.13) to tell the terminal not to display the keys being pressed so passwords were not displayed on the terminal. Today, the terminals are gone and the functions that they provided are now performed by the "TTY" and "PTY" on your Linux/Unix systems.
Today programs can use the OS's TTY/PTY to perform line editing (backspace, up arrow, down arrow, etc) and session management (Control C to kill a program, Control Z background etc) . Programs, such as Python's readline module, can put the TTY's line discipline in "raw" mode and perform those TTY functions themselves. Programs that use raw mode like this will probably perform just fine when you connect to them over a raw socket or netcat. But other programs such as BASH that expect to communicate with a TTY can have some undesirable results when run through a raw network connection or netcat where no TTY is present.
You have probably experience this before. You hit CONTROL-C in a netcat windows intending to kill a remote process and instead it kills your netcat session. You run a command such "su -" and when the OS sends the echo off escape code I mentioned , your netcat session breaks. Fear not! If you have a remote Linux OS then this simple Python script will launch bash inside of a PTY and make most of these problems go away.
python -c 'import pty; pty.spawn("/bin/bash")'
You can run this command with out any problems inside of an existing bash program that is NOT in a TTY and it will launch as second process that is in a TTY. Unfortunately, this scripts will only work on your Linux targets. Windows doesn't nativley support PTYs so the target must be a Linux computer. For a seamless experience both the attack box and the target should be a Linux box. If both sides of the connection have a TTY (ie running Linux) you can hit CONTROL-C to kill a remote program without losing your connection. To kill your connection you have to type "exit". That returns you back to your 'non-TTY' shell where pressing CONTROL-C will kill the connection.
In a pinch you could use Windows as the attack box. Although it isn't a completely seamless experience, this wonderful little Python command still fixes issues with commands like "sudo" and "su". The command "top" even works pretty well although you have to press "q" and "enter" to exit rather than just pressing "q" to quit. Pressing "enter" to transmit data is required for many things if the attack box is Windows. Some commands such as "vi" still don't work. Unfortunately, pressing CONTROL-C will still kill your Windows netcat client. Even worse, when CONTROL-C kills your netcat client it will leave the remote shell running in an remotely unrecoverable state. Just as we discussed for Linux you must type "exit" to leave your shell and return to the 'non-TTY' shell and then hit CONTROL-C to properly exit the shell.
All hope is not lost if either the Attack or Target system is Windows. There are some simple work around for most basic operations that are covered extensively in SANS SEC560: Network Penetration Testing and Ethical Hacking. If you would like more information about this and other Python modules please check out SEC573: Automating Information Security with Python.