Buka jendela pada tampilan X jarak jauh (mengapa "Tidak bisa membuka layar")?


81

Dahulu kala,

DISPLAY=:0.0 totem /path/to/movie.avi

setelah ssh ke desktop saya dari laptop saya akan menyebabkan totem untuk bermain movie.avidi desktop saya.

Sekarang ini memberikan kesalahan:

No protocol specified
Cannot open display:

Saya menginstal ulang Debian memeras ketika berjalan stabil di kedua komputer, dan saya kira saya melanggar konfigurasi.

Saya sudah meneliti ini, dan tidak bisa seumur hidup saya mencari tahu apa yang seharusnya saya lakukan.

(VLC memiliki antarmuka HTTP yang berfungsi, tetapi tidak senyaman ssh.)

Masalah yang sama muncul ketika saya mencoba menjalankan ini dari pekerjaan cron.


1
Apakah mesin jarak jauh Anda menunjukkan file .Xauthority? Pertanyaan jelas lainnya adalah - apakah server dan klien ssh Anda dikonfigurasi untuk memungkinkan penerusan X? Perintah apa yang Anda gunakan untuk ssh?
Faheem Mitha

1
saya mencoba meneruskan X? Saya ingin perintah dieksekusi pada host, bukan klien. Perintah ssh saya hanya ssh me @ host temukan .Xauthority di komputer host tidak cocok dengan file apa pun.
justin cress

Seperti yang disarankan Faheem, ada perubahan bagus bahwa masalah Anda disebabkan karena totemtidak menemukan cookie X Anda, dan Anda perlu mengatur XAUTHORITYke nilai yang tepat, yaitu nilai dalam sesi reguler Anda di desktop Anda. Baca Linux: wmctrl tidak dapat membuka tampilan ketika sesi dimulai melalui layar ssh + untuk beberapa latar belakang; juga lihat jawaban terkait Sebagai root dapatkah saya meluncurkan program grafis di desktop pengguna lain? .
Gilles

1
baik-baik saja, secara fisik duduk di depan komputer dan mengetikkan echo $ XAUTHORITY memberi / var / run / gdm3 / auth-for-jcress-bb32gX / database di sesi ssh, mengetikkan echo $ DISPLAY = (jalur di atas) tidak menyelesaikan masalah
justin cress

1
Aku menyalahkan GDM3, mengapa tidak bisa mereka hanya terus $XAUTHORITYdi ~/.Xauthorityseperti semua orang mengharapkan hal itu terjadi.
Arrowmaster

Jawaban:


78

(Diadaptasi dari Linux: wmctrl tidak dapat membuka tampilan saat sesi dimulai melalui layar ssh + )

DISPLAY dan OTORITAS

Program X memerlukan dua informasi untuk dapat terhubung ke tampilan X.

  • Perlu alamat tampilan, yang biasanya :0ketika Anda login secara lokal atau :10,, :11dll. Ketika Anda login jarak jauh (tetapi jumlahnya dapat berubah tergantung pada berapa banyak koneksi X yang aktif). Alamat tampilan biasanya ditunjukkan dalam DISPLAYvariabel lingkungan.

  • Perlu kata sandi untuk tampilan. Kata sandi tampilan X disebut cookie ajaib . Cookie ajaib tidak ditentukan secara langsung: cookie selalu disimpan dalam file otoritas X, yang merupakan kumpulan catatan dari bentuk “display :42has cookie 123456”. File otoritas X biasanya ditunjukkan dalam XAUTHORITYvariabel lingkungan. Jika $XAUTHORITYtidak diatur, gunakan program ~/.Xauthority.

Anda mencoba untuk bertindak di jendela yang ditampilkan di desktop Anda. Jika Anda satu-satunya orang yang menggunakan mesin desktop Anda, kemungkinan besar nama tampilan tersebut :0. Menemukan lokasi file otoritas X lebih sulit, karena dengan gdm yang diatur di bawah Debian squeeze atau Ubuntu 10.04, file tersebut berada dalam file dengan nama yang dibuat secara acak. (Anda tidak punya masalah sebelumnya karena versi sebelumnya dari gdm menggunakan pengaturan default, yaitu cookie yang disimpan di ~/.Xauthority.)

Mendapatkan nilai-nilai variabel

Berikut adalah beberapa cara untuk mendapatkan nilai DISPLAYdan XAUTHORITY:

  • Anda dapat secara sistematis memulai sesi layar dari desktop Anda, mungkin secara otomatis di skrip login Anda (dari ~/.profile; tetapi lakukan hanya jika masuk di bawah X: tes jika DISPLAYdiatur ke nilai yang dimulai dengan :(yang harus mencakup semua kasus yang kemungkinan Anda miliki) untuk bertemu)). Di ~/.profile:

    case $DISPLAY in
      :*) screen -S local -d -m;;
    esac
    

    Kemudian, di sesi ssh:

    screen -d -r local
    
  • Anda juga bisa menyimpan nilai-nilai DISPLAYdan XAUTHORITYdalam file dan mengingat nilai-nilai tersebut. Di ~/.profile:

    case $DISPLAY in
      :*) export | grep -E '(^| )(DISPLAY|XAUTHORITY)=' >~/.local-display-setup.sh;;
    esac
    

    Dalam sesi ssh:

    . ~/.local-display-setup.sh
    screen
    
  • Anda bisa mendeteksi nilai dari DISPLAYdan XAUTHORITYdari proses yang berjalan. Ini lebih sulit untuk diotomatisasi. Anda harus mengetahui PID dari suatu proses yang terhubung ke tampilan yang ingin Anda kerjakan, kemudian dapatkan variabel lingkungan dari /proc/$pid/environ( eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=')¹).

Menyalin cookie

Pendekatan lain (mengikuti saran dari Arrowmaster ) adalah untuk tidak mencoba mendapatkan nilai $XAUTHORITYdalam sesi ssh, tetapi sebaliknya membuat sesi X menyalin cookie-nya ~/.Xauthority. Karena cookie dihasilkan setiap kali Anda masuk, itu tidak masalah jika Anda menyimpan nilai-nilai basi ~/.Xauthority.

Mungkin ada masalah keamanan jika direktori rumah Anda dapat diakses melalui NFS atau sistem file jaringan lainnya yang memungkinkan administrator jarak jauh untuk melihat isinya. Mereka masih harus terhubung ke mesin Anda, kecuali Anda telah mengaktifkan koneksi X TCP (Debian menonaktifkannya secara default). Jadi bagi kebanyakan orang, ini tidak berlaku (tidak ada NFS) atau bukan masalah (tidak ada koneksi X TCP).

Untuk menyalin cookie ketika Anda masuk ke sesi X desktop Anda, tambahkan baris berikut ke ~/.xprofileatau ~/.profile(atau skrip lain yang dibaca saat Anda masuk):

case $DISPLAY:$XAUTHORITY in
  :*:?*)
    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

¹ Pada prinsipnya ini tidak memiliki kutipan yang tepat, tetapi dalam contoh khusus ini $DISPLAYdan $XAUTHORITYtidak akan mengandung metacharacter shell.


2
Salah satu cara untuk mengotomatisasi ini adalah dengan membuat ~/.xprofileyang seharusnya hanya dijalankan selama X login dan membuatnya membuat / memperbarui ~/.Xauthoritydengan info yang benar. Apakah tautan simbolik sudah cukup?
Arrowmaster

@Arrowmaster: Itu saran yang bagus. Saya belum memikirkannya. Ini tidak akan berfungsi dalam semua kasus, misalnya jika Anda masuk ke lebih dari satu sesi X (pada terminal yang berbeda, dengan vnc, ...), tetapi itu sederhana, dan itu cukup baik untuk penggunaan umum. Tautan simbolis adalah cara terbaik. Hmm, sebenarnya ada cara yang lebih baik dan sederhana: Anda dapat menyalin informasinya ~/.Xauthority.
Gilles

1
Apakah memasukkan sesuatu seperti xauth extract - $DISPLAY | xauth -f "$HOME/.Xauthority" merge -dalam ~/.xprofilemenyelesaikan kasus $ DISPLAY's multi?
Arrowmaster

@Arrowmaster: Masalah apa yang Anda lihat dengan banyak tampilan? Meskipun pada prinsipnya kode Anda mungkin sedikit lebih bersih karena Anda hanya mengekstraksi informasi tentang tampilan yang Anda minati, saya tidak melihat ada yang salah dengan penggabungan sederhana dalam kasus penanya, atau memang di luar keadaan yang sangat tidak biasa.
Gilles

1
Membaca lingkungan dari proses yang ada saat ini yang terhubung ke tampilan tidak terduga sebagai kejahatan yang menyenangkan. Saya menyetujui dengan sepenuh hati. Unix.SE membutuhkan lencana Evil Genius ™ untuk ini.
derobert

19

Saya memecahkan masalah ini dengan menambahkan

xhost +si:localuser:$USER

untuk ~/.xprofile. Saya tidak tahu apakah ini sepenuhnya aman (saya akan sangat tertarik untuk mendengar apa yang dipikirkan orang yang lebih berpengetahuan), tapi saya menduga itu jauh lebih baik daripada mematikan kontrol akses (dengan xhost +) seperti yang umumnya disarankan ketika Anda google untuk masalah ini.


1
localuseralamat yang ditafsirkan server sepenuhnya aman. Debian bahkan melakukan ini secara default sebagai bagian dari proses masuk (dalam /etc/X11/Xsession.d/35x11-common_xhost-local). Lihat halaman manual Xsecurity untuk lebih jelasnya.
Sam Morris

Jika Anda menggunakan LAN, xhost +mungkin cukup dalam banyak kasus ...
Alexis Wilke

Apakah Anda dapat menjelaskan apa arti perintah ini?
alpha_989

@ alpha_989: Ini berarti "Berikan akses [+] ke aplikasi [localuser] yang berjalan secara lokal yang berjalan seperti saya [$ USER]." "Si" hanyalah lem (lihat xhost(1)dan Xsecurity(7)untuk dokumen). Dengan sendirinya, perintah ini tidak mengizinkan segala jenis akses jarak jauh atau penerusan X11 (yang biasanya lebih disukai mekanisme "kue ajaib" xhost).
Kevin

7

Kamu butuh export DISPLAY=:0.0


Tidak. Unix tidak memerlukan ekspor ketika variabel ditulis pada baris yang sama. Variabel itu efektif hingga garis berakhir.
Alexis Wilke

Memang kamu benar.
asoundmove

Jawaban ini jelas salah dan harus dihapus.
Piotr Dobrogost

Tidak tahu hanya mengetik DISPLAY =: 0,0 akan menetapkan nama variabel. Terima kasih @muka. Namun, saya pikir: 0,0 adalah nilai untuk variabel DISPLAY di tampilan server. Jika Anda masuk dari Putty, variabel DISPLAY harus 10 atau lebih tinggi. jadi itu seharusnya DISPLAY =: 10
alpha_989

3

Bekerja untuk saya, debian wheezy -> ubuntu trusty.

Catatan: dalam hal ini server tidak menjalankan manajer tampilan, ini adalah mesin virtual 'tanpa kepala' tanpa kartu grafis atau monitor terpasang.

bob@laptop:~$ grep -iB 1 tcp /etc/gdm3/daemon.conf
[security]
DisallowTCP = false
bob@laptop:~$ ssh -C -R 6000:127.0.0.1:6000 alice@server
X11 forwarding request failed on channel 0
alice@server:~$ export DISPLAY=:0.0
alice@server:~$ xterm

Layar X pada laptop menunjukkan output xterm yang berjalan di server.

Debug menggunakan:

bob@laptop:~/tmp$ nc -v 127.0.0.1 6001
localhost [127.0.0.1] 6001 (x11-1) : Connection refused
bob@laptop:~/tmp$ nc -v 127.0.0.1 6000
localhost [127.0.0.1] 6000 (x11) open
alice@server:~$ nc -v 127.0.0.1 6000
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded!*
alice@server:~$ strace xterm

strace akan menumpahkan banyak detail berdarah tentang apa yang dilakukannya, Anda harus bisa menebak di mana ia macet - menunggu koneksi atau apa pun.

Dalam satu baris ..

ssh -C -R 6000:127.0.0.1:6000 alice@server "DISPLAY=:0.0 xterm"
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.