PuTTY inserts random characters during a session

I had the same problem with PuTTY and found that is was being caused by an application I have called "caffeine" which effectively presses the F13 key every minute to stop the screen saver from being activated (group policies prevent me from changing screen saver timeout on my machine). Disabling the application solved me problem.

If you prefer to have Putty and Caffeine running then follow these steps:

1. Stop Caffeine
2. Check the Caffeine readme.txt for the default key simulated - mine was F15
3. Login to your remote terminal via Putty
4. Start Caffeine (Tip: start Caffeine with short interval e.g 3 seconds).
5. Bring the Putty session in focus.
6. On your bash command prompt press Ctrl+V (This is required to get the special code for the key. e.g try Ctrl+V followed by F12)
7. Wait for Caffeine to simulate the key
8. The key code will be displayed on the command line (e.g F15 is ^[[28~, where ^[ is escape). Stop Caffeine
9. Now you can bind this key to blank so that when Caffeine simulates it, it won't type ~
   • edit ~/.inputrc (create a new file if it doesn't exist)
   • add the line "\e[28~":""
10. Start Caffeine
11. Restart your terminal session
    • There should be no more random ~ when using the Putty terminal with that linux server

I found shreyansp's solution to be the most (but not quite) satisfactory one :)
Here's my attempt on improving that (of course YMMV). Hope this may be of use to those looking for a solution :)

My solution behaves as follows:

• caffeine sends to Windows an appropriate Virtual-Key Code which:
  • prevents Windows from going to sleep or idle
  • does not otherwise generate any side-effects on Windows neither alone nor in combination (no Ctrl, Shift, Alt, Alt-Gr, Win, F1-F5, F10, etc.)
  • either is not sent to Putty or is ignored by Putty

TL;DR: My solution is applied between steps 2 and 3 (see below) with the -key:0E caffeine param:
Exit Caffeine & re-launch it with:
caffeine.exe 5 -key:0E (for easy testing)
caffeine.exe 50 -key:0E (for a mandatory screen saver set at 1 minute)

• Launch read program on the remote host and watch how no keystrokes are received every 5 or 50 seconds.
• Exit read with Ctrl+C

  ---

Shreyansp proposed a solution where a fix would be applied between steps 5 and 10 (see below).
The side-effect of that (on my config) was that, with each keystroke that putty forwarded from caffeine to the remote host:

• it triggered a 'Reset scrollbar on keypress' (setting on Putty/Window page)
  which I would normally want, but only when I (the human) is pressing the key but not regularly by caffeine :)
• readline/bash translated version of it (from '"\e[28~"' to '""' (blank key ?) caused the remote session interaction to hang for several seconds

In order to easily test the above, exit Caffeine & re-launch it with 5 seconds interval and Virtual-Key Code 07:
caffeine.exe 5 -key:07

• Launch read program on the remote host and watch how keystrokes are received every 5 or 50 seconds.
• Exit read with Ctrl+C

  ---

The keystroke 'pipeline', as I understand it:

1. Caffeine sends a Virtual-Key Code to Windows
2. Windows sends that Virtual-Key Code to Putty
3. Putty does some 'translations'/'mappings' based on some session settings in:
   • Terminal/*
   • Window/*
4. Putty sends the 'translated'/'mapped' key code to the remote host
5. On the remote host, the 'terminal' program (e.g: $TERM=xterm, vt100, vt102, vt220, etc.) translates from the 'line protocol' into key codes.
6. the readline library does some translations/mappings based on ~/.inputrc
7. readline sends the Key Code to bash
8. bash does some translations/mappings based on ~/.bashrc (based on the builtin bind command)
9. bash or readline (not sure which one) sends the translated Key Code to nano (my text editor)
10. This pipeline can get even longer by adding the screen program (which includes a $TERM=screen for step 5. and loops back again at step 6. to 10.)

Note: Once it gets to step 4., it becomes very difficult to precisely control the different layers of 'translations'/'mappings'. I would recommend avoiding that if you can.

---

Background:
I used caffeine.exe -key:07 for years before having to deal with a pfsense 2.3.3-RELEASE-p1 (based on FreeBSD 10.3-RELEASE).
Then, caffeine.exe -key:07 was received on the other side as ^[[28~ ... which seems to be mapped to Ctrl+^ (Set Mark) in Nano.
This was quite annoying (imagine someone pressing and keeping Shift Key while you move the text caret around in Notepad).

Previously, I did numerous customizations in Putty Settings, ~/.tcshrc, ~/.inputrc, ~/.bashrc, ~/.nanorc, ~/.screenrc to get what I consider basic functionality (Backspace, Delete, Home, End, PgUp, PgDown, Ctrl+Left, Ctrl+Right, Numpad 0-9, Numpad ./*-+) working consistently between bash/nano/screen.

Once I discovered this caffeine.exe -key:07 'bug', I didn't want to retrace that all over again :)

---

Tested on:
Windows 8.1 64-bit Enterprise (6.3.9600) / Putty 0.66 / pfsense 2.3.3-RELEASE-p1 (based on FreeBSD 10.3-RELEASE) / bash 4.4.12-release / nano 2.7.3 / screen 4.04.00

---

References:

• Caffeine:

  • Virtual-Key Codes sent by caffeine to Windows (I would choose the 1st Undefined code that works for your setup)

• Readline/inputrc/bash/bashrc/(builtin) bind:

  • http://www.softpanorama.org/Scripting/Shellorama/inputrc.shtml
  • http://cnswww.cns.cwru.edu/php/chet/readline/rluserman.html
  • https://docs.freebsd.org/info/readline/readline.pdf
  • Summary:
    • unbinding with 'bind -r keyseq' only forwards the non-translated keys to the application (nano in my case)
    • remapping from 'keyseq' to '""' does only mean that an empty key (whatever that may mean) is sent to the application (causing some lockups)

• Putty:

  • PuTTY wish portable-keyboard (handler)
  • PuTTY wish key-mapping
  • Summary:
    • Putty has no provisions to make it ignore one or more specific keys (it's not even listed as a needed/wanted feature)
    • However, Putty seems to filter out Virtual-Key codes that it doesn't recognizes/supports (which is good for us :)