ป้องกันไคลเอ็นต์ SSH ที่ส่งผ่านตัวแปรสภาพแวดล้อม TERM ไปยังเซิร์ฟเวอร์หรือไม่


21

ฉันกำลังใช้งานFedora 18 gnome-terminalจากนั้นก็เริ่มtmuxmultiplexer เข้าไป หลังจากฉันเชื่อมต่อกับเซิร์ฟเวอร์CentOS 5 ผ่านsshคำสั่งฉันพบ:

  • ls ผลลัพธ์ไม่มีสี
  • tmux, screen, hexedit, htopทั้งหมดล้มเหลวในการเริ่มต้นด้วยข้อผิดพลาดเช่น:
    เทอร์มินัลเปิดล้มเหลว: ขาดหายไปหรือเทอร์มินัลไม่เหมาะสม: หน้าจอ 256C

ดูเหมือนว่าsshจะส่งผ่านตัวแปรสภาพแวดล้อม $ TERM ไปยังเซิร์ฟเวอร์ แต่ฉันไม่พบใน/etc/ssh/ssh_configไฟล์ Fedora 18

แม้ว่าฉันสามารถเปลี่ยนตัวแปร $ TERM ด้วยตนเองบนเซิร์ฟเวอร์ทุกครั้งที่ฉันเชื่อมต่อ แต่จะเกิดขึ้นอีกครั้ง ดังนั้นวิธีการป้องกันมันได้หรือไม่

คำตอบ:


18

$TERM คือการบอกแอปพลิเคชันว่าเทอร์มินัลใดที่พวกเขากำลังพูดคุยอยู่

เปลี่ยนเป็นค่าที่สนับสนุนโดยโฮสต์ระยะไกลและตรงกับที่ใกล้เคียงที่สุดเท่าที่จะเป็นไปได้เทอร์มินัลของคุณ ( screen)

ระบบ Linux ส่วนใหญ่ควรมีscreenรายการ terminfo อย่างน้อย ถ้าไม่ได้screenดำเนินการตาม superset vt100และvt100เป็นสากล ดังนั้น:

TERM=screen ssh host

หรือ

TERM=vt100 ssh host

หากคุณต้องการการสนับสนุน 256 สีคุณสามารถลองใช้xterm-256colorซึ่งควรจะอยู่ใกล้พอ ( screenรองรับ 256 สีในลักษณะเดียวกันxterm) และบอกแอปพลิเคชันว่าแอปพลิเคชันเทอร์มินัลของคุณรองรับ 256 สีและบอกวิธีใช้

หรือคุณสามารถติดตั้งรายการ terminfo บนรีโมตโฮสต์

infocmp -x | ssh -t root@remote-host '
  cat > "$TERM.info" && tic -x "$TERM.info"'

2
เป็นการดีที่จะรู้infocmpและticรวบรวมเมื่อไม่จำเป็นต้องเปลี่ยนชั่วคราว$TERMอีกครั้ง โดยวิธีการที่ฉันเพิ่งคัดลอก (rsync) /usr/share/terminfo/s/screen-256colorจาก Fedora 18 ไปยัง CentOS ดูเหมือนว่าใช้ได้ ( rsync -tv /usr/share/terminfo/s/screen-256color root@the_host:/usr/share/terminfo/s)
LiuYan 刘研

ลืมที่จะกล่าวถึง i วิ่งtmuxในคำพังเพยขั้วของ Fedora 18 tmuxการเปลี่ยนแปลง$TERMมูลค่าให้กับจากscreen-256color xterm-256color
LiuYan 刘研

btw สามารถ ssh ทำงานได้ด้วยวิธีนี้: รับ terminfo ซึ่งโฮสต์ / เซิร์ฟเวอร์ที่รองรับ (ไม่พุช) จากนั้นเลือกหนึ่งเทอร์มินัลไคลเอ็นต์ที่สามารถรองรับได้
LiuYan 刘研

2
infocmp | ssh -t root@remote-host 'cat > "$TERM.info" && tic "$TERM.info"'infocmp | ssh root@remote-host "tic -"สามารถลงไป สิ่งนี้ทำงานได้เพราะเมื่อคุณมีไพพ์คุณสามารถเข้าถึงได้ในรูปแบบไฟล์โดยใช้ - และโชคดีที่ไพพ์ทำงานข้าม SSH
Alan Jenkins

1
@starfry ฉันไม่สามารถรับประกันได้เลยว่ารูปแบบไบนารีของticไฟล์ที่สร้างขึ้น (terminfo คอมไพเลอร์) จะเหมือนกันจากระบบหนึ่งไปยังอีกระบบหนึ่งหรือตำแหน่งของพวกเขาจะเหมือนกัน ticอาจตรวจสอบให้แน่ใจว่าการอนุญาตนั้นถูกต้องหรือสร้างไดเรกทอรีตัวกลางที่จำเป็น
Stéphane Chazelas

10

ในกรณีของฉันฉันเพิ่งเพิ่มนามแฝงของฉัน.zshrc( .bashrcถ้าใช้ทุบตี) บนเดสก์ทอปท้องถิ่นของฉัน:

alias ssh='TERM=xterm ssh'

หากคุณใช้นามแฝงอยู่แล้วให้ปรับเพื่อรวมการกำหนด Environment


1

ฉันใส่สิ่งนี้.bashrcลงในโฮสต์ระยะไกล:

# 256-color mode not supported on this host
if echo $TERM | grep -q -- '-256color'; then
    echo -e '\n\n256-color mode not supported on this host.  Reverting TERM...\n'
    export TERM=`echo -n $TERM | sed 's/-256color//'`
fi

ด้วยวิธีนี้ทั้งสองxterm-256colorและscreen-265colorได้รับการจัดการอย่างเหมาะสม นอกจากนี้ฉันมีมันออกบันทึกเพื่อที่ว่าหากเซิร์ฟเวอร์ได้รับการอัพเกรดในภายหลังและรองรับ 256 สีฉันจะไม่จบการต่อสู้หัวของฉันกับผนังสงสัยว่าทำไมตัวแปร TERM ของฉันได้รับการเปลี่ยนแปลงเมื่อ SSHing


หรืออย่าเริ่ม subshell และกระบวนการอื่น:export TERM=${TERM%%-256color}
miken32

1

การเปลี่ยนแปลง$TERMอาจใช้งานได้ แต่ฉันไม่แนะนำสิ่งนี้เป็นเพียงวิธีแก้ปัญหาแทนที่จะเป็นวิธีแก้ปัญหา

เมื่อฉันพบปัญหานี้ในระบบของฉันฉันแก้ไขได้โดยการติดตั้งการสนับสนุนสำหรับประเภทเทอร์มินัลที่พบบ่อยที่สุดในระบบระยะไกล

  • yum install ncurses-baseสำหรับscreen-256colorCentOS
  • yum install ncurses-termสำหรับscreen-256color-bceCentOS
  • apt install ncurses-baseสำหรับทั้งสองscreen-256colorและscreen-256color-bceใน Debian, Ubuntu และมิ้นท์

แพ็คเกจที่เกี่ยวข้องกับ ncurses ยังให้การสนับสนุนเทอร์มินัลอื่น ๆ อีกมากมายและพวกมันยังมีอยู่ในการกระจายขนาดใหญ่อื่น ๆ ทั้งหมด (แต่สำหรับกรณีการใช้งานของฉันและคำถามของคุณนี่ควรเป็นข้อมูลที่เพียงพอ)


0

ดูคน ssh_config:

 SendEnv
         Specifies what variables from the local environ(7) should be sent
         to the server.  Note that environment passing is only supported
         for protocol 2.  The server must also support it, and the server
         must be configured to accept these environment variables.  Refer
         to AcceptEnv in sshd_config(5) for how to configure the server.
         Variables are specified by name, which may contain wildcard char‐
         acters.  Multiple environment variables may be separated by
         whitespace or spread across multiple SendEnv directives. The
         default is not to send any environment variables.

และผู้ชาย sshd_config:

 AcceptEnv
         Specifies what environment variables sent by the client will be
         copied into the session's environ(7).  See SendEnv in
         ssh_config(5) for how to configure the client.  Note that envi-
         ronment passing is only supported for protocol 2.  Variables are
         specified by name, which may contain the wildcard characters `*'
         and `?'.  Multiple environment variables may be separated by
         whitespace or spread across multiple AcceptEnv directives.  Be
         warned that some environment variables could be used to bypass
         restricted user environments.  For this reason, care should be
         taken in the use of this directive.  The default is not to accept
         any environment variables.

ตามค่าเริ่มต้นไม่ควรส่งตัวแปรใด ๆ แต่ TERM ดูเหมือนจะพิเศษ มันจะส่งต่อไป

ดังนั้นคุณสามารถเปลี่ยน TERM เมื่อเรียก ssh (เช่นTERM=xterm ssh ...) เปลี่ยนหลังจากเข้าสู่ระบบ (เหมือนใน.bash_profile) หรือกำหนดชนิดของ TERM ที่ไม่รู้จักบนฝั่งเซิร์ฟเวอร์ (สมมติว่าคุณมีการเข้าถึงรูท) ดูคำตอบอื่น ๆ สำหรับรายละเอียด


1
การตั้งค่า$TERMไม่ได้จะไม่ดีไปกว่าการตั้งค่าเป็นค่าที่ไม่รองรับ
Stéphane Chazelas

คำถามที่แท้จริงคือวิธีป้องกันการส่ง TERM - คำตอบ: คุณไม่สามารถ - สิ่งที่เขาควรทำคือตั้งค่าให้เหมาะสมใช่
michas

การเปลี่ยนแปลง$TERMชั่วคราวอาจเป็นวิธีแก้ปัญหา แต่ฉันต้องทำทุกครั้ง โดยวิธีการที่ดูเหมือนว่าทั้ง CentOS 5 และ Fedora 18 ยอมรับEnvตัวแปรสภาพแวดล้อมของสถานที่เกิดเหตุทั้งหมด ( LANG, LC_*, ... )
LiuYan刘研
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.