Prevent SSH client passing TERM environment variable to server?
Solution 1
$TERM
is to tell applications what terminal they're talking to so they know how to talk to it.
Change it to a value supported by the remote host and that matches as closely as possible your terminal (screen
).
Most Linux systems should at least have a screen
terminfo entry. If not, screen
implements a superset of vt100
and vt100
is universal. So:
TERM=screen ssh host
or
TERM=vt100 ssh host
If you do need the 256 color support, you could try xterm-256color
which should be close enough (screen
supports 256 colors the same way xterm
does) and tell applications your terminal application supports 256 colors and tell them how to use them.
Or you can install the terminfo entry on the remote host.
infocmp -x | ssh -t root@remote-host '
cat > "$TERM.info" && tic -x "$TERM.info"'
Solution 2
In my case I simply added an alias to my .zshrc
(.bashrc
if using bash) on my local desktop:
alias ssh='TERM=xterm ssh'
If you already use an alias, adjust it to include the Environment assignment.
Solution 3
Changing $TERM
might work, but I don't suggest this, it's only a workaround instead of a solution.
When I encounter this problem on my systems, I fix it by installing support for the most common terminal types to the remote system:
yum install ncurses-base
forscreen-256color
on CentOSyum install ncurses-term
forscreen-256color-bce
on CentOSapt install ncurses-base
for bothscreen-256color
andscreen-256color-bce
on Debian, Ubuntu and Mint
The ncurses-related packages also provide support for a lot of other terminals, and they are also available on all other large distributions. (But for my use-case and your question this should be enough info)
Solution 4
The best solution is to end up with full terminal support during SSH sessions. To achieve this, upload your terminfo
files to your home directory on the remote server.
Locally: Check your working TERM value:
echo $TERM
In the following examples alacritty
is used. Next, find local the terminfo
files for your terminal:
locate alacritty | grep terminfo
I found results under /usr/share/terminfo
. Finally, upload the files to `~/.terminfo on the remote host.
# On the remote host
mkdir -p ~/.terminfo/a
# Locally
scp /usr/share/terminfo/a/alacritty* remotehost:.terminfo/a/
The terminfo format is a compiled format so simply copying the files may not work. If it doesn't work and infocmp
and tic
are available locally and remotely, you can use this method instead:
infocmp -x | ssh -t root@remote-host 'cat > "$TERM.info" && tic -x "$TERM.info"'
Related videos on Youtube
LiuYan 刘研
// unsigned char *p; // Map<String,Object> map; -- SELECT Name FROM ab -- INNER JOIN cdr ON ab.PhoneNumber=cdr.PhoneNumber /* pre {font-family: 'Ubuntu Mono';} */ <!-- <pre>&copy; right?</pre> --> // function f() {} # echo -e "your message:\n$(fortune)" | \ # gpg -e --clearsign -o - -r [email protected] REM if ""%1"" == """" goto default ; exten => 911,1,Answer() svn commit -m "to be continue"
Updated on September 18, 2022Comments
-
LiuYan 刘研 over 1 year
I'm currently using Fedora 18 gnome-terminal, then started
tmux
multiplexer in it. After I connected to a CentOS 5 server viassh
command, I find:-
ls
result has no color -
tmux
,screen
,hexedit
,htop
all failed to start with error message like:open terminal failed: missing or unsuitable terminal: screen-256color
It seems that
ssh
passes the $TERM environment variable to the server, but I can't find it in/etc/ssh/ssh_config
file of Fedora 18.Although I can manually change the $TERM variable on the server, each time I connect, it happens again. So how to prevent it?
-
-
michas about 11 yearsThe literal question was, how to prevent sending TERM. - Answer: You cannot. - What he should do is setting it to a suitable value, yes.
-
LiuYan 刘研 about 11 yearschange
$TERM
temporarily may be a workaround, but i need to do it each time. by the way, it seems that both CentOS 5 and Fedora 18 AcceptEnv all locale environment variables (LANG
,LC_*
, ...) -
LiuYan 刘研 about 11 yearsgood to know
infocmp
andtic
, once compiled, no need to temporarily change$TERM
again. by the way, i just copied (rsync)/usr/share/terminfo/s/screen-256color
from Fedora 18 to CentOS, it seems works ok (rsync -tv /usr/share/terminfo/s/screen-256color root@the_host:/usr/share/terminfo/s
). -
LiuYan 刘研 about 11 yearsforgot to mentioned, i ran
tmux
in gnome-terminal of Fedora 18,tmux
changed$TERM
value toscreen-256color
fromxterm-256color
. -
LiuYan 刘研 about 11 yearsbtw, can ssh works in this way: get the terminfo which host/server supported (not pushed into), then pickup one the client terminal can support?
-
Dmitri DB about 10 yearsI found it amusing that this infocmp piped through ssh thing left a file called dumb.info in my home dir.
-
Alan Jenkins over 7 years
infocmp | ssh -t root@remote-host 'cat > "$TERM.info" && tic "$TERM.info"'
can be shortened toinfocmp | ssh root@remote-host "tic -"
. This works because when you have a pipe it can be accessed as a file by using - and luckily pipes work across SSH. -
starfry over 7 yearsI copy the terminfo file from
/usr/share/terminfo
to the same place on the remote host. Is there any reason why usinginfocmp
andtic
would be preferable? -
Stéphane Chazelas over 7 years@starfry, I can't give you any guarantee that the binary format of the
tic
(terminfo compiler) generated files will be the same from one system to the next or that their location will be the same.tic
may also make sure the permissions are correct or create intermediary directories where needed. -
miken32 over 5 yearsOr, don't start a subshell and another process:
export TERM=${TERM%%-256color}
-
mazunki about 4 yearsThe original command gave me
Pseudo-terminal will not be allocated because stdin is not a terminal.
error, while the shortened version actually worked for me. Alacritty works on ssh now =) -
Gringo Suave over 3 yearsThis may be the best answer, assuming desire/permission to install packages remotely.
-
Mark Stosberg over 3 yearsIf you are willing to use a solution that involves modifying files on every remote server you ssh into, you could instead install the desired terminal support files in
~/.terminfo
on all the remote hosts. -
Mark Stosberg over 3 yearsThis solution is less desirable as it dumbs down the terminal support on the remote host, while uploading the terminal defintiions to your home directory on the server allows full terminal support in the remote connection.
-
Mark Stosberg over 3 yearsBesides that you might not have permission to install packages remotely, such a package might not be available. For example Ubuntu 16.04 and 18.04 are still active LTS lines, but the terminal info for the
alacritty
terminal is not packaged until 20.04. -
zaTricky over 3 yearsThis is a really cool solution. The only negative is that it involves a bit of effort for a server you might only connect to once. For the other usecases it's robust and less guesswork.
-
Phantomwhale almost 3 yearsEnded up being the winner for me - I'm using kitty terminal, and none of the machines I SSH into have any support for that, so setting the TERM value back to a common base value is probably the best option in almost all cases