ฉันจะแก้ไขข้อผิดพลาด“ ไม่สามารถเปิดจอแสดงผล” เมื่อเปิดโปรแกรม X หลังจากที่เปิดใช้งานการส่งต่อ X11 ได้อย่างไร

111

หลังจากเปิดตัวแอพ X11 (XQuartz 2.3.6, xorg-server 1.4.2-apple56) บน Mac ของฉัน (OS X 10.6.8) การเปิดเทอร์มินัลใน X11 และใช้งานxhost +ฉันssh -Yไปที่ Ubuntu 10.04 VM ของฉัน (ทำงานบน VMware ฟิวชั่น) เมื่อฉันทำงานgedit .bashrc(ตัวอย่าง) ฉันจะได้รับ:

(gedit:9510): Gtk-WARNING **: cannot open display:

set | grep DISPLAY ไม่มีอะไรคืน

แต่ถ้าผมssh -Yเข้าไปในอูบุนตู 11.04 เครื่องของฉันgedit .bashrcงาน echo $DISPLAYส่งคืน "localhost: 10.0"

ฉันพยายามexport DISPLAY=localhost:10.0ในขณะที่ sshed เป็น VM ของฉันแล้วเรียกใช้gedit .bashrcแต่ฉันได้รับ:

(gedit:9625): Gtk-WARNING **: cannot open display: localhost:10.0

อะไรคือความแตกต่างในการกำหนดค่าของเครื่อง Ubuntu สองแบบที่แตกต่างกันซึ่งจะอธิบายว่าทำไมเครื่องหนึ่งถึงใช้งานได้

อัปเดต:ตามที่Zoredacheแนะนำในความคิดเห็นด้านล่างฉันวิ่งsudo apt-get install xbase-clientsแต่ฉันยังคงมีปัญหาเดียวกัน

— ดาริลสปิตเซอร์
แหล่งที่มา

2

กล่อง Ubuntu 10.04 มีเครื่องมือที่เหมาะสมสำหรับการติดตั้ง X11 หรือไม่? ติดตั้งไคลเอนต์ xbase หากยังไม่ได้ติดตั้ง

— Zoredache

ฉันติดตั้งแล้ว แต่ก็ยังมีปัญหาเดียวกัน (ดูด้านบน)

— Daryl Spitzer

3

อาจลองผ่านตัวเลือก -vv ไปยัง ssh เมื่อคุณเชื่อมต่อซึ่งจะพิมพ์ข้อความดีบักอย่างละเอียดคุณควรเห็นความคิดเห็นหลายประการเกี่ยวกับการส่งต่อ X11 ขณะเชื่อมต่อ

— Zoredache

1

@jcrawfordor คุณตรวจสอบX11Forwardingบน Ubuntu และคุณได้xbase-clientsติดตั้งและคุณสามารถเริ่ม Xapps บน mac บน terminal ที่คุณกำลังทำการเชื่อมต่อ ssh (ตรวจสอบที่$DISPLAYตั้งอยู่บนสถานีที่คุณใช้ SSH จาก .

— Manwë

1

ในกรณีของฉันมันเป็นเพียงเรื่องของการอัพเกรดรุ่น XQuartz ของ MacOS

— Waruna Ranasinghe

47

ตรวจสอบเซิร์ฟเวอร์ sshd_config (ปกติ/etc/ssh/sshd_config) และตรวจสอบให้แน่ใจว่าตัวเลือก X11Forwarding เปิดใช้งานด้วยบรรทัด

X11Forwarding yes

หากไม่ได้ระบุ X11Forwarding ค่าเริ่มต้นจะไม่มีในเครื่อง Debian ที่ฉันมีให้ตรวจสอบ

— DerfK
แหล่งที่มา

4

ฉันค้นพบหลังจากตั้งค่า Ubuntu VM อีกตัวหนึ่งฉันต้องติดตั้ง xbase-clients ทั้งสองและเปิดใช้งาน X11Forwarding อัปเดตคำตอบของคุณเพื่อรวมทั้งและฉันจะยอมรับมัน

— ดาริลสปิตเซอร์

1

น่าสนใจ อย่างน้อยในการติดตั้งใหม่ 10.04 ที่ฉันทำเมื่อเช้านี้ X11Forwarding ถูกเปิดใช้งานตามค่าเริ่มต้น พวกอูบุนตูต้องมายุ่งกับค่าเริ่มต้นอีกครั้ง

— Zoredache

28

@DerfK ในระบบของฉัน "X11Forwarding ใช่" มีอยู่แล้วฉันยังได้รับข้อผิดพลาดเป็น(gedit: 8381): Gtk-WARNING **: ไม่สามารถเปิดจอแสดงผล:ในกรณีเช่นนี้

— AJ

1

บน Debian คุณอาจต้องติดตั้งแพ็คเกจ xauth จากนั้นเข้าสู่ระบบอีกครั้ง

— comte

$ ssh ชื่อผู้ใช้ @ hostname -Y สิ่งนี้ใช้ได้กับฉัน

— MarcoZen

60

จากxhost +: วิธีการแก้ไขข้อผิดพลาด“ ไม่สามารถเปิดการแสดงผล” ขณะเปิดใช้งาน GUI บนเซิร์ฟเวอร์ระยะไกล :

คำตอบ : คุณสามารถแก้ไขข้อผิดพลาด“ ไม่สามารถเปิดจอแสดงผล” โดยทำตามขั้นตอน xhost ที่กล่าวถึงในบทความนี้

อนุญาตให้ไคลเอนต์เชื่อมต่อจากโฮสต์ใด ๆ โดยใช้ xhost +

ดำเนินการคำสั่งต่อไปนี้เพื่อปิดใช้งานการควบคุมการเข้าถึงซึ่งคุณสามารถอนุญาตให้ไคลเอนต์เชื่อมต่อจากโฮสต์ใด ๆ
$ xhost +
การควบคุมการเข้าถึงถูกปิดใช้งานลูกค้าสามารถเชื่อมต่อจากโฮสต์ใด ๆ

เปิดใช้งานการส่งต่อ X11

ในขณะที่ทำ ssh ใช้ตัวเลือก -X เพื่อเปิดใช้งานการส่งต่อ X11
$ ssh username@hostname -X
เปิดใช้งานการส่งต่อ X11 ที่เชื่อถือได้โดยใช้ตัวเลือก -Y
$ ssh username@hostname -Y
เปิดแอปพลิเคชัน GUI ในโฮสต์นั้น

หลังจากเปิดการเชื่อมต่อ ssh ไปยังรีโมตโฮสต์ตามที่อธิบายไว้ข้างต้นคุณสามารถเปิดแอปพลิเคชั่น GUI ใด ๆ ที่จะเปิดโดยไม่มีปัญหาใด ๆ

หากคุณยังคงได้รับข้อผิดพลาด“ ไม่สามารถเปิดจอแสดงผล” ให้ตั้งค่าตัวแปร DISPLAY ตามที่แสดงด้านล่าง
$ export DISPLAY='IP:0.0'
หมายเหตุ: IP เป็น IP ของเวิร์กสเตชันในพื้นที่ที่คุณต้องการให้แอปพลิเคชัน GUI แสดงขึ้น

— harrymc
แหล่งที่มา

11

+1 สำหรับหมายเหตุว่าIP = เป็น IP ของเวิร์กสเตชันท้องถิ่นที่คุณต้องการรับ GUI

— PCoder

3

สำหรับผู้ที่มีปัญหาที่คล้ายกันใน OS X ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้ง XQuartz มิฉะนั้นจะไม่มีวิธีแก้ไขเหล่านี้ช่วยเหลือ (คำถามของ OP แสดงให้เห็นว่าเขามี XQuartz ดังนั้นนี่จึงเป็นข้อความที่เคียงกับผู้ที่มีปัญหาคล้ายกันมากขึ้น)

— Dolan Antenucci

3

โปรดทราบว่าการใช้งานxhost +ไม่ปลอดภัยอย่างมากและไม่ควรใช้! ดังที่ Stefan Rogin พูดถึงผู้โจมตีสามารถเชื่อมต่อกับโฮสต์จาก XSession ของคุณอ่านสิ่งที่คุณพิมพ์หรือแม้แต่เปลี่ยนหน้าจอที่คุณเห็น

— jirislav

คนสุดท้ายexport Display=IP:0.0ทำเพื่อฉัน

— javadba

18

ฉันมีปัญหานี้เมื่อเข้าสู่ระบบ Ubuntu VM จาก Mac OS X เช่นกัน - ดูเหมือนว่า 'localhost' ในตัวแปรการแสดงผลด้วยเหตุผลบางอย่าง ดังนั้นตั้งค่า IP ด้วยตนเองตามที่ harrymc แนะนำ:

export DISPLAY="127.0.0.1:10.0"

จากนั้นโปรแกรม X11 ควรจะใช้ได้ ดูเหมือนว่าไม่จำเป็นต้องบอก OS ว่า localhost และ 127.0.0.1 นั้นเทียบเท่า แต่ใช้งานได้อย่างน้อย

— SpinUp
แหล่งที่มา

สิ่งนี้ใช้ได้สำหรับฉัน ความคิดใดที่ localhost ไม่ทำงาน

— อเล็กซ์

2

บิงโก! ฉันติดปัญหานี้มาระยะหนึ่งแล้ว ... ฉันเชื่อมต่อโดย SSH และไม่สามารถเปิดโปรแกรม Gtk ได้ (ธรรมดา X11 เช่น "xeyes" ทำงานได้) DISPLAY ถูกต้อง ที่จริงแล้วความละเอียดของ "localhost" ไม่ใช่! หากฉันตั้งค่า DISPLAY ด้วยตนเอง = 127.0.0.1: 10.0 หรือ DISPLAY = :: 1: 10.0 มันจะทำงาน ดูเหมือนว่าการแก้ไข / etc / hosts จะไม่มีผลใด ๆ และ DNS ได้รับการกำหนดค่าอย่างถูกต้อง (Correclty "dig localhost" รายงานทั้ง 127.0.0.1 และ :: 1) ดังนั้นดูเหมือนว่าจะเป็นข้อบกพร่องในการแก้ไข DNS สำหรับการเชื่อมต่อ X11 ใน Gtk (gtk? gdk? glib?

— Pablo Saratxaga

1

ในการติดตั้ง Debian สำหรับ Beagle Bone Black, / etc / host ไม่ได้ถูกตั้งค่าให้อ่านได้ทุกคนยกเว้นรูท นี่เป็นสาเหตุที่รายงานอาการที่นี่ Made / etc / hosts สามารถอ่านได้โดยทุกคนและใช้งานได้ดี

— Daniel

13

ฉันมีปัญหานี้กับเซิร์ฟเวอร์ CentOS KVM ของฉันฉันไม่มีโปรแกรม "xauth"

— Joril
แหล่งที่มา

1

สิ่งนี้ช่วยฉันในการติดตั้งเดเบียนที่น้อยที่สุดของฉันขอบคุณมาก!

— bin หรือ

9

หากคุณมีปัญหานี้หลังจากผ่านไประยะหนึ่งเมื่อทำงานกับ-Xarg หรือเพียงแค่ForwardX11ใน / etc / ssh / ssh_config จากนั้นเรียกใช้$ ssh username@hostname -Yเพื่อเปิดใช้งานการส่งต่อ X11 ที่เชื่อถือได้ไม่ทราบสาเหตุที่แน่นอน แต่ฉันเดาว่า-Xคุณสมบัติบางอย่างจะหมดอายุหลังจากผ่านไประยะหนึ่งอาจเพิ่มความปลอดภัย

นี่คือสิ่งที่ฉันพบออนไลน์:

หากคุณใช้ ssh -X remotemachine เครื่องรีโมตจะถือว่าเป็นไคลเอ็นต์ที่ไม่น่าเชื่อถือ ดังนั้นโลคัลไคลเอ็นต์ของคุณส่งคำสั่งไปยังเครื่องรีโมตและรับเอาต์พุตกราฟิก หากคำสั่งของคุณละเมิดการตั้งค่าความปลอดภัยคุณจะได้รับข้อผิดพลาดแทน

แต่ถ้าคุณใช้ ssh -Y remotemachine เครื่องระยะไกลจะถือว่าเป็นลูกค้าที่เชื่อถือได้ ตัวเลือกสุดท้ายนี้สามารถเปิดปัญหาด้านความปลอดภัย เนื่องจากไคลเอนต์แบบกราฟิก (X11) อื่น ๆ สามารถดักข้อมูลจากเครื่องระยะไกล (ทำภาพหน้าจอทำ keylogging และสิ่งที่น่ารังเกียจอื่น ๆ ) และเป็นไปได้ที่จะเปลี่ยนแปลงข้อมูลเหล่านั้น

หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับสิ่งเหล่านั้นฉันขอแนะนำให้อ่านข้อมูลจำเพาะ Xsecurity หรือ X Security extension นอกจากนี้คุณสามารถตรวจสอบตัวเลือก ForwardX11 และ ForwardX11 ไว้วางใจใน / etc / ssh / ssh_config ของคุณ

แหล่งที่มา:

— Stefan Rogin
แหล่งที่มา

6

เพิ่งทดสอบบน Mac ของฉันระบบอื่น ๆ อาจใช้ได้ :

อนุญาตให้ไคลเอนต์เชื่อมต่อจากโฮสต์ใด ๆ โดยใช้ xhost +

$ xhost +
คุณควรมีสภาพแวดล้อมที่รองรับจอแสดงผล X11

[ระบบ Mac] ติดตั้ง X11 สำหรับ mac https://www.xquartz.org/
คุณควรปล่อยให้ ssh-server ส่งต่อ x11 แสดง

อัปเดต/etc/ssh/sshd_configและตั้งค่าX11Forwarding yesจากนั้นรีสตาร์ทเซิร์ฟเวอร์ ssh ของคุณ
คุณควรปล่อยให้เซสชั่น ssh ไปข้างหน้า x11 แสดงพร้อม-Xพารามิเตอร์

$ ssh -X user @ ip
วิธีเปิดแอพ X11 ใน PyCharm
- เปิดเซสชัน ssh ที่รองรับจอแสดงผล X11 (อย่าลืมเก็บเซสชันนี้ไว้)
- รันecho $DISPLAYในเซสชัน ssh นั้น
- ตั้งค่าDISPLAYตัวแปรสภาพแวดล้อมสำหรับ PyCharm ของคุณ

— สี
แหล่งที่มา

1

เหตุใดจึงแตกต่างกันหรือทำไมจึงเป็นที่ต้องการมากกว่าคำตอบอื่น ๆ กรุณาอธิบายถ้าคุณสามารถด้วยง่ายแก้ไข คุณสามารถทำมันได้!!

— Pimp Juice IT

ขอบคุณ @ McDonald's อัพเดตด้วยรายละเอียดเพิ่มเติม

— สี

4

เมื่อใช้ UXTERM หรือ XTERM เพียงแค่ออก

export $DISPLAY

ตัวแปรจะอยู่ที่นั่น จากนั้นเพียงตั้งค่าและส่งออก

— Oracle2066
แหล่งที่มา

4

ฉันต้องใส่/etc/ssh/sshd_configสิ่งต่อไปนี้:

X11UseLocalhost no

จากนั้นให้ตั้งค่าเป็น "ใช่" แปลกถ้าผู้ใช้เริ่มต้น "ไม่" ใช้ผงสำหรับอุดรูด้วย XMing ภายใต้ Windows ฉันใช้ ssh โดยตรงกับ Fedora บางครั้งมันก็เริ่มให้เรา

error can't open display localhost

การรีบูตเซิร์ฟเวอร์มักจะแก้ไขได้ แต่มันก็โง่ ทำตามข้างต้นแล้วเริ่มบริการsshdบนเซิร์ฟเวอร์และเชื่อมต่อใหม่ presto ทำงานได้ดีอีกครั้ง

— Luigi
แหล่งที่มา

2

ฉันยังมีปัญหานี้กับ Solaris 10 และพบว่าผู้ฟังไม่ได้ตั้งค่า

svccfg –s /application/x11/x11-server listprop options/tcp_listen
svccfg –s /application/x11/x11-server setprop  options/tcp_listen = true

— ดั๊กซอมเมอร์
แหล่งที่มา

1

บน CentOS 6.5 ทันใดนั้นฉันก็สูญเสียการเข้าถึงโปรแกรม X แบบรีโมตหลังจากไปยุ่งกับ / etc / hosts อาการเดียวกันของตัวแปร $ DISPLAY ที่ว่างเปล่า (ไม่มีการตั้งค่าความช่วยเหลือ / ส่งออกด้วยตนเอง)

รายการ 127.0.0.1 ที่ชี้ไปยังชื่อโฮสต์จริงเป็นสิ่งจำเป็น ในความเป็นจริงคำสั่งซื้อดูเหมือนว่าจะมีความเกี่ยวข้องเช่นกัน (ใส่ล่าสุด & จะไม่ทำงาน ... )

[root@poseidon /etc]$ cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1     localhost6.localdomain6 localhost6
127.0.0.1 poseidon.mycampus.edu poseidon
1XX.XXX.XXX.208 poseidon.mycampus.edu poseidon

หลังจากแก้ไขสิ่งนี้แล้ว xeyes, xclock และของเล่นทดสอบ X อื่น ๆ กำลังทำงานอีกครั้งดังนั้นผู้จัดการคุณธรรมของฉันก็ต้องกลับมาออนไลน์อีกครั้ง

— เดวิดรามิเรซ
แหล่งที่มา

1

ฉันเพิ่งพบอาการสะอึกที่ดีในการตั้งค่าที่ป้องกันการส่งต่อ x: ไฟร์วอลล์ของฉันบล็อกการเชื่อมต่อทั้งหมดจาก localhost ดังนั้นจึงป้องกันไม่ให้เข้าถึงอุโมงค์ได้

— Pelle
แหล่งที่มา

1

หากคุณกำลังใช้ Konsole เพียงสลับไปที่โปรแกรมจำลองเทอร์มินัลอื่นเช่น Xfce Terminal แล้วลองอีกครั้งโดยใช้รูท

— Oliver Dechant
แหล่งที่มา

1

เปิดเทอร์มินัล $ ssh ชื่อผู้ใช้ @ hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY = "127.0.0.1:10.0" ทั้งหมดควรใช้งานได้

— Kenny Gichuhi
แหล่งที่มา

ขอบคุณ เหมาะสำหรับกรณีพิเศษของฉันเมื่อDISPLAY='localhost:10.0'ไม่ทำงาน

— xpt

1

การตั้งค่านี้ใช้ได้สำหรับฉัน:

Local (64 bit Cygwin บน Windows 10) DISPLAY=:0

เซิร์ฟเวอร์ (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

พบการตั้งค่าเหล่านี้โดยคลิก "เมนูแอปพลิเคชัน X บน: 0" ในแถบงานและเลือกเครื่องมือระบบ> เทอร์มินัล

— qwr
แหล่งที่มา

0

หลังจากความยุ่งยากมากมายฉันพบว่ารายการสำหรับชื่อโฮสต์ของเซิร์ฟเวอร์ในไฟล์ / etc / host ของเขาไม่ถูกต้อง

— iceburn_pt
แหล่งที่มา