Problem: Keyboard Input Echoed Back to Serial Terminal using PuTTY to Linux System

I enabled the serial console on a Debian Linux system. I used PuTTY to connect to the serial console. However, I encountered a problem, i.e., any keyboard inputs were echoed back to the serial console. The following screen shot perhaps explains the problem, e.g., when I enter user name, the user name is echoed back again, and when I enter the password, by default, the terminal shouldn't show anything, but it echoes it back.

 

A Stack Overflow thread discusses a similar problem, and I linked it below,

•  PuTTY serial communication

The thread led me to experimenting the terminal setting in PuTTY. The default setting of the "Line discipline options" is "Auto" for "Local echo", and "Auto" for "Local line editing" shown in the screen capture below. When using these settings, I encountered the problem I described in the above.

My fiddling with the settings tells me that the solution is to check "Force off"  for "Local echo", and "Force off" for "Local line editing" shown in the screen shot below,

Having made the setting changes, I saw that the problem went away. Well, we can see it from the screen shot below,

Enabling Serial Console on Debian Linux

I wanted to enable the serial console on a Linux system. The system is a Debian Linux release 10 (a.k.a., "buster"). The official documentation has the following description about the serial console

"

If you are booting with a serial console, generally the kernel will autodetect this. If you have a videocard (framebuffer) and a keyboard also attached to the computer which you wish to boot via serial console, you may have to pass the console=device argument to the kernel, where device is your serial device, which is usually something like ttyS0. 

You may need to specify parameters for the serial port, such as speed and parity, for instance console=ttyS0,9600n8; other typical speeds may be 57600 or 115200. Be sure to specify this option after “---”, so that it is copied into the bootloader configuration for the installed system (if supported by the installer for the bootloader). 

In order to ensure the terminal type used by the installer matches your terminal emulator, the parameter TERM=type can be added. Note that the installer only supports the following terminal types: linux, bterm, ansi, vt102 and dumb. The default for serial console in debian-installer is vt102. If you are using an IPMI console, or a virtualization tool which does not provide conversion into such terminals types itself, e.g. QEMU/KVM, you can start it inside a screen session. That will indeed perform translation into the screen terminal type, which is very close to vt102.

"

It also states,

"

Those used to change inittab to enable/disable virtual or serial consoles will notice that that file is gone from clean installs. This is all managed through systemd directly now. For example, you can enable a serial console on COM1 with: 

systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service

However, it is generally preferable to add console=ttyS0 on the kernel commandline, since this also enables kernel output on reboots. This is done by adding the following to /etc/default/grub: 

GRUB_CMDLINE_LINUX="console=ttyS0"

... and running update-grub. This will take effect only on the next reboot, however.

"

It is clearly that the documentation offers two solutions, using the systemd service or using the boot parameter. Perhaps, the former has the shortcoming that the serial console may not start if the systemd does not get a chance to run because we happen to have a boot problem. The preferred method, as suggested is to pass a boot parameter to the kernel. Since I have the grub boot loader installed, this becomes a simple two step approach,

1. Edit /etc/default/grub file. In my case, replace

   
   GRUB_CMDLINE_LINUX_DEFAULT="quiet"
   

   
   by

   
   GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0 console=tty0"
   

   
   
2. Update the grub.cfg file

   
   update-grub -o /boot/grub/grub.cfg
   

I happened to back up the old grub.cfg file. By comparing the old and new grub.cfg file, we can easily see the difference between the two files,

$ diff /boot/grub/grub.cfg /boot/grub/grub.cfg.bu01
diff /boot/grub/grub.cfg /boot/grub/grub.cfg.bu01
119c119
<       linux   /boot/vmlinuz-4.19.0-8-686 root=UUID=123456789 ro  console=ttyS0 console=tty0
---
>       linux   /boot/vmlinuz-4.19.0-8-686 root=UUID=123456789 ro  quiet
137c137
<               linux   /boot/vmlinuz-4.19.0-8-686 root=UUID=123456789 ro  console=ttyS0 console=tty0
---
>               linux   /boot/vmlinuz-4.19.0-8-686 root=UUID=123456789 ro  quiet
$