[sudobash1]

One thing I wish ssh would make easier is terminfo. I have moved from using xterm as my daily terminal emulator to kitty. The only complaint I have is when I ssh around, I need to copy the terminfo to the remote system (kitty does not use TERM="xterm-256color" because it is not 100% compatible).

Kitty does have a ssh wrapper which can copy the terminfo for me, but I rarely remember to use it. And it doesn't work for every scenario. Honestly, I wish that it was more common / feasible to probe terminals for capabilities instead of relying on an env var & terminfo files.

So while I wait for the kitty terminfo to be in the database by default on most systems, I often override TERM to xterm-256color.

[memco]

Because of my experience with Kitty I agree this is a little bit of a pain point which could use some TLC by all parties involved. However, kitty seems to occupy a unique position on this and although it has intriguing ideas does not seem to have many tools needing the same accommodations. Iterm and wezterm both just use xterm-256color perhaps because there’s no better options. I just tested the setEnv ssh_config option others mentioned and that seems a good workaround. It is a bit confusing to have to set that but doing so avoids overriding the kitty.conf setting which is very strongly discouraged. It would be ideal to only set that when using kitty to make an ssh connection but since all my other tools use it anyway it isn’t a major issue.

I think my biggest pain points with SSH are more related to sessions and tools. I can easily navigate to servers but it’s a bit of a pain when I have to use certain users to log in and then others to operate on data on those servers. VSCode has good ssh support if you are able to log in as the same user as the user that has edit permissions on the files you need to modify. Wezterm ssh and iTerm tmux integration have also given me trouble when I want to open a new pane after I’ve run su or sudo. I end up having to use workarounds like changing permissions while I edit and changing back or simply avoiding the feature altogether because I’m already on the server and didn’t remember to connect with the right command or didn’t start tmux before I started work.

[0x0]

Modern ssh clients support adding a "SetEnv" in .ssh/config, might work for overriding TERM as well

[dijit]

I solved this issue by adding

    alias ssh='TERM=xterm-256color ssh'

To my .bashrc/.zshrc

[linsomniac]

Also kitty user here, and one thing I really missed about xterm is the ability to "InhibitTite" to disable the second buffer. Use case: I edit a documentation file, find a set of commands I need to run, and exit the editor to run them, and the commands disappear from my screen. xterm has a few options allowing you, as the user, to disable this functionality and just have a single screen.

Most other terminals do not have this option.

So for kitty, I made a small deb package with the kitty terminfo file, which I need anyway unless I use xterm-256color, but I modified the entry to not have the ti/te entries.

Win/win.

[bravetraveler]

Fellow Kitty user here, similar hurdles.

If you haven't implemented it in your workflow already, you can conditionally set TERM for hosts in your SSH configs with SetEnv.

This is one of the few, if not the only, variable that SSHd will allow clients to set for free.

[joombaga]

What does your last sentence mean? What is the "cost" for setting other vars?

[linsomniac]

There are only a few environment variables allowed to be set by an SSH client by default. You can add more by adding an "AcceptEnv" line to the SSH server "/etc/sshd_config" file.

[bravetraveler]

As others have pointed out - security restriction.

The service must allow most variables to be set by connecting clients.

If TERM were included in this, you might as well install the terminfo! Fortunately that's not the case.

One could do some interesting things if say SHELL or LDPRELOAD were allowed to be forwarded.

[ggm]

It means it's not constrained by security concerns. Some Env are not forwarded. This one is.