When you use for ages a SSH client that magically just works and it is pretty simple to setup as PuTTY.

You take for granted that you open an SSH session and all just works.

However, when when I moved to macOS and start using iTerm2 as my main terminal emulator, some of my SSH sessions start behaving funny.

And some of the SSH sessions that were playing up were the ones for my Homelab ESXis, which made me chase the problem since it was pretty annoying not being able to use one of the tools that is quite useful for any troubleshoot - esxtop.

Problem

Everytime I opened an SSH session to one of my Homelab ESXis servers and run esxtop the result was something similar to running it in batch mode with output to the stdout (screen).

Troubleshooting

When checking the output for clues I noticed the first bit of the output.

It seems that potentially the problem is related to the TERM variable that normally helps defining some of the terminal parameters.

In this case, seems that our ESXi shell do not know xterm256-color terminal. And we easily can verify that looking at /usr/share/terminfo/x/ that it makes sense, since no xterm256-color is listed.

The $TERM shell variable is inherited from our terminal emulator.

• Terminal Emulator

  

• ESXi SSH

  

Solution

There are three options to solve our problem:

• Change the $TERM in our macOS terminal emulator
• Prefix our command esxtop overriding the $TERM value
• Override the inherited $TERM value whenever we login to ESXi via SSH

I personally do not like the first two, since none of them would be permanent solution or did not have any collateral damage.

So the option of overriding the inherited $TERM in every login to the ESXi was the preferred.

One of the options to override the $TERM value with something that we know that always work, for example xterm, would be adding the var assignment to /etc/profile.local.

vi /etc/profile.local

The file profile.local is processed every time you login via SSH as part of the shell setup, hence to take effect we will need to reload it, easiest way is to do a logoff/logon.

Result

Once we get this done and we logoff/logon, we can check if $TERM was overridden by our changes.

And lets check if esxtop behaves as expected.