Dietpi: SSH | Error when SSH client passes unsupported terminal to DietPi SSH server

[MichaIng]

Creating a bug report/issue:

Reference: https://github.com/Fourdee/DietPi/issues/1901#issuecomment-415534725

• Thanks @wuhei for reporting!

Additional Information (if applicable):

• Software title | any SSH server

Steps to reproduce:

1. Connect from a remote SSH client with an unsupported terminal type (e.g. rxvt-256color) to DietPi SSH server

Expected behaviour:

• No error, all software/function working fine

Actual behaviour:

• Software/Functions that need the terminal definitions, will fail, e.g. tput: unknown terminal "rxvt-256color"

Extra details:

• The issue is similar to the $LANG issue when accessing via SSH: https://github.com/Fourdee/DietPi/blob/master/rootfs/etc/bashrc.d/dietpi-posix-set-locale.sh
• Similar to $LANG, also $TERM is passed from the SSH client to the SSH server. This can even on OpenSSH not be suppressed: https://unix.stackexchange.com/a/67540
• If the passed terminal is not supported on the DietPi system, the above errors show up.

Solutions:

• Installing ncurses-term to support more terminal types, or ...
• ... Resetting $TERM to e.g. xterm or another terminal, that is supported on with ncurses-base.
  
  
  
  • To keep 256 bit terminal, if used on/passed by client: [[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color' €: Better include a quick check if $TERM is unsupported, before assigning a supported term string!
  
  
• For testing the solutions with PuTTY client, add an unsupported terminal to: PuTTY > Connection > Data > Terminal-type string

Other references:

• https://unix.stackexchange.com/questions/67537/prevent-ssh-client-passing-term-environment-variable-to-server
• https://raspberrypi.stackexchange.com/questions/53364/trying-to-ssh-in-using-urxvt-gives-error
• https://unix.stackexchange.com/questions/196488/set-urxvt-to-work-with-256-colors

[MichaIng]

Check for supported terminals: toe -a, e.g. toe -a | grep -q "$TERM"

As manually changing the $TERM variable, thus faking a different terminal that what actually is connected, is not the best long term practice:

• Show warning/G_WHIP_MSG that the connecting terminal is not supported, thus SSH client setting/term needs to be changed or ncurses-term installed.
• Tell user that xterm (respectively xterm-256color, if [[ $TERM =~ 256 ]]) is faked for the current session.

[MichaIng]

PR is up for testing: https://github.com/Fourdee/DietPi/pull/2049

[Fourdee]

Note to self:

• 🈯️ General Testing
• 🈯️ Test Allo GUI

[Fourdee]

@MichaIng

Yep seems fine, although, been unable to test with any "incompatible terminal" as i know of none 🤣 .

[MichaIng]

@Fourdee
I tested with PuTTY and changed the terminal string in Connection > Data.

But another test that makes sense is to use another system with an exotic terminal emulator installed and SSH from within it.
I will try this today.

---

€: Indeed hard to test. Installed a desktop and some random terminal emulator to use for SSH client. On LXDE all terminal emulators seem to set TERM=xterm, no matter which additional emulator I use. Maybe different desktops use different default TERM variables, or Xserver based desktops all use xterm (?), not sure. Still, if manually export TERM=somethingElse and then ssh root@DietPiSSHServer, the solution works great, faking TERM=xterm or =xterm-256color, showing hint with option to install ncurses-term for extended support.
I guess if the terminal is totally incompatible to xterm, has a totally different char, color and/or command set (not sure which parts are defined in the terminal definition files, as they are not plain text), the method can still fail, e.g. whiptail menu being unreadable or format/color being wrong. But since xterm seems to be the most common and most supported terminal definition and the issue is anyway a very rare one, it should be good enough and there is not more we can do.

[Fourdee]

@MichaIng

But since xterm seems to be the most common and most supported terminal definition and the issue is anyway a very rare one, it should be good enough and there is not more we can do.

Yep agree 👍

Great work, I believe this is the best we can do for now and should prevent the initial issue on this ticket. If additional work is required, it could be a question of "is the SSH client, following the standards correctly, if not, another SSH client should be used"?

I'll mark as completed. Please reopen if required.