SSH X11 tidak berfungsi

Saya memiliki komputer di rumah dan kantor, komputer di rumah memiliki alamat IP statis.

Jika saya ssh dari komputer kerja ke komputer di rumah, koneksi ssh berfungsi tetapi aplikasi X11 tidak ditampilkan.

Di /etc/ssh/sshd_configrumah saya :

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Di tempat kerja saya telah mencoba perintah berikut:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Saya /etc/ssh/ssh_configdi tempat kerja:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Saya ~/.ssh/configdi tempat kerja:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Saya ~/.Xauthoritydi tempat kerja:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Saya ~/.Xauthoritydi rumah:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Tapi itu tidak berhasil

Setelah saya membuat koneksi ssh ke rumah:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Saya menggunakan iptablesdi rumah, tapi saya sudah mengizinkan port 22. Menurut apa yang saya baca itu yang saya butuhkan.

UPD. Dengan-vvv

...
debug2: mulai callback
debug2: x11_get_proto: / usr / bin / daftar xauth: 0 2> / dev / null
debug1: Meminta penerusan X11 dengan spoofing otentikasi.
debug2: saluran 1: permintaan x11-req konfirmasi 1
debug2: client_session2_setup: id 1
debug2: pengaturan fd 3 TCP_NODELAY
debug2: saluran 1: permintaan pty-req konfirmasi 1
...

Ketika mencoba meluncurkan kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 maks 16384
debug1: client_request_x11: request from 127.0.0.1 55486
debug2: pengaturan fd 8 O_NONBLOCK
debug3: fd 8 adalah O_NONBLOCK
debug1: saluran 2: baru [x11]
debug1: konfirmasi x11
debug2: Koneksi X11 menggunakan protokol otentikasi yang berbeda.
Koneksi X11 ditolak karena otentikasi salah.
debug2: X11 ditolak 2 i0 / o0
debug2: saluran 2: baca gagal
debug2: saluran 2: close_read
debug2: saluran 2: masukan terbuka -> tiriskan
debug2: saluran 2: ibuf kosong
debug2: saluran 2: kirim eof
debug2: saluran 2: tiriskan input -> ditutup
debug2: saluran 2: gagal menulis
debug2: saluran 2: close_write
debug2: saluran 2: keluaran terbuka -> tertutup
debug2: X11 ditutup 2 i3 / o3
debug2: saluran 2: kirim tutup
debug2: saluran 2: rcvd close
debug2: saluran 2: sudah mati
debug2: saluran 2: pengumpulan sampah
debug1: saluran 2: gratis: x11, saluran 3
debug3: saluran 2: status: Koneksi berikut terbuka:
  Sesi klien # 1 (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Sama seperti di atas, ulangi sekitar 7 kali

kate: tidak dapat terhubung ke server X localhost: 10.0

UPD2 Berikan distribusi Linux & nomor versi Anda.
Apakah Anda menggunakan lingkungan default GNOME atau KDE untuk X atau sesuatu yang Anda sesuaikan sendiri?

azat: ~ $ kded4 -versi
Qt: 4.7.4
Platform Pengembangan KDE: 4.6.5 (4.6.5)
Daemon KDE: $ Id $

Apakah Anda memohon ssh langsung pada baris perintah dari jendela terminal?
Terminal apa yang Anda gunakan? xterm, terminal gnome, atau?
Bagaimana Anda memulai terminal berjalan di lingkungan X? Dari menu? Hotkey? atau ?

Dari emulator terminal `yakuake`
Secara manual tekan `Ctrl + N` dan tulis perintah

Bisakah Anda menjalankan xeyes dari jendela terminal yang sama di mana ssh -X gagal?

`xeyes` - tidak diinstal
Tetapi `kate` atau aplikasi kde lain sedang berjalan

Apakah Anda menjalankan perintah ssh sebagai pengguna yang sama dengan yang Anda masuki ke sesi X?
From the same user

UPD3

Saya juga mengunduh sshsumber, dan menggunakan debug2()tulis mengapa melaporkan bahwa versi berbeda.
Ini melihat beberapa cookie, dan salah satunya kosong, yang lain adalahMIT-MAGIC-COOKIE-1

Alasan penerusan ssh X tidak berfungsi adalah karena saya memiliki /etc/ssh/sshrcfile konfigurasi.

Akhir sshd(8)halaman manual menyatakan:

Jika ~/.ssh/rcada, jalankan; jika /etc/ssh/sshrcada, jalankan; jika tidak, jalankan xauth

Jadi saya menambahkan perintah berikut ke /etc/ssh/sshrc(juga dari halaman man sshd) di sisi server:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

Dan itu berhasil!

Setiap kali Anda mengalami masalah dengan ssh, hal pertama yang harus Anda lakukan adalah menjalankan klien dengan -vopsi untuk memberikan hasil bagi orang lain untuk diperiksa:

ssh -v user@somewhere

Saya akan menebak bahwa masalahnya ada pada sistem lokal Anda. Bagaimana Anda menjalankan perintah ssh? Apakah Anda menjalankannya secara manual di shell? Atau apakah itu dieksekusi sebagai bagian dari skrip? Dalam kedua kasus ini, Anda ingin memastikan bahwa sistem lokal Anda memiliki DISPLAYlingkungan yang ditetapkan dengan benar. Itu juga perlu diatur dengan benar di sisi jarak jauh, juga, tetapi nilai itu akan berbeda di sisi jarak jauh dari sisi lokal.

Dari apa yang Anda tulis tampaknya sedang diatur dengan benar pada host jarak jauh (dan dengan ekstensi penerusan X11 diatur dengan benar oleh ssh). Pada sistem jarak jauh yang Anda miliki:

$ echo $DISPLAY
localhost:10.0

Apa yang ditampilkan di sisi lokal? Itu seharusnya mudah untuk memeriksa apakah Anda berada di shell baik dengan menggema nilainya, serta memulai aplikasi X dari shell itu ... Anda selalu dapat menggunakan yang mulia xeyesuntuk pengujian semacam itu, tentu saja! :)

Di sisi lain, jika Anda menjalankan perintah ssh dari skrip atau dilampirkan ke hotkey mungkin tidak mewarisi lingkungan yang Anda harapkan, jadi DISPLAYvariabel lingkungan di sisi lokal mungkin tidak disetel sama sekali.

Juga, karena sepertinya Anda telah mengutak-atik .Xauthorityfile Anda, Anda mungkin ingin menghapusnya sepenuhnya, kemudian keluar dari sesi X Anda dan masuk kembali sehingga secara otomatis akan membuatnya kembali. Jarang ada kebutuhan untuk bercinta dengan Anda .Xauthority, jadi mencoba itu mungkin hanya tindakan putus asa yang tidak akan membantu.

Apa yang harus Anda lihat di sisi lokal adalah:

$ echo $DISPLAY
:0.0

Pada sistem konfigurasi yang tepat jika Anda membuka shell yang tidak perlu Anda atur sendiri, itu harus diwarisi dari lingkungan yang memulai shell Anda. Namun saya telah melihat konfigurasi window manager / hotkey yang tidak benar menangani pewarisan variabel lingkungan. Jika Anda menjalankan sistem linux gnome-sessionatau kde-sessionyang Anda gunakan untuk meluncurkan shell atau skrip Anda, maka variabel lingkungan sesi X Anda harus diatur dengan benar seperti yang dijelaskan dalam dokumentasi Ubuntu tentang pewarisan variabel lingkungan :

Ketika proses induk membuat proses anak, misalnya ketika kita menjalankan perintah "gedit" dari terminal dan "bash" (proses induk) menciptakan "gedit" (proses anak), proses anak mewarisi semua variabel lingkungan dan nilai yang dimiliki proses induk.

...

Catatan: di lingkungan desktop grafis Gnome, sesi gnome adalah proses induk dari semua proses yang berjalan di desktop. Fakta ini (bersama dengan prinsip Warisan) adalah kunci kemampuan kami untuk secara kuat mempengaruhi operasi desktop kami dengan variabel lingkungan. Proses yang setara di KDE adalah sesi KDE.

DIPERBARUI

Terima kasih telah memposting keluaran dari ssh -vvv. Dalam hal ini, verbositas ekstra dari -vvvversus adil -vsangat membantu. Output debug memberi tahu saya bahwa penerusan X11 sedang disiapkan dengan benar:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Tapi :0di baris pertama membuat saya percaya masih ada kesalahan konfigurasi di sisi lokal dalam cara Anda menjalankan ssh. Pada banyak sistem, nilai default untuk DISPLAYadalah :0.0, bukan :0. Apakah Anda entah bagaimana menetapkan nilai DISPLAYsecara manual sendiri sebelum menjalankan perintah ssh?

Informasi lebih lanjut tentang sistem lokal Anda dan bagaimana Anda menjalankan perintah ssh akan sangat membantu pada saat ini.

• Berikan nomor versi & distribusi Linux Anda.
• Apakah Anda menggunakan lingkungan default GNOME atau KDE untuk X atau sesuatu yang Anda sesuaikan sendiri?
• Apakah Anda memohon ssh langsung pada baris perintah dari jendela terminal?
• Terminal apa yang Anda gunakan? xterm, terminal gnome, atau?
• Bagaimana Anda memulai terminal berjalan di lingkungan X? Dari menu? Hotkey? atau ?
• Dapatkah Anda menjalankan xeyesdari jendela terminal yang sama di mana ssh -Xgagal?
• Apakah Anda menjalankan perintah ssh sebagai pengguna yang sama dengan yang Anda masuki ke sesi X?

Item terakhir ini penting. Jika Anda menjalankan ssh sebagai pengguna lain (misalnya, jika Anda membuka jendela terminal root alih-alih jendela terminal pengguna), maka Anda akan mengalami masalah ini bahkan jika Anda secara eksplisit mengatur DISPLAY=:0karena Anda tidak memiliki izin untuk terhubung ke server X secara default sebagai pengguna lain (bahkan sebagai root!)

Konfigurasi Anda tampaknya baik-baik saja, tetapi cobalah "ssh -X home" seperti yang disarankan Agemen.

Juga, jika semuanya gagal, coba ini:

Setelah Anda ssh ke mesin rumah Anda dari kantor, pada "rumah" ketik:

xauth list

Kemudian, pada "kerja", ketik

xauth

Yang akan memberi Anda prompt "xauth>". Dari sini, ketik "tambah", lalu salin tempel output dari "daftar xauth", satu baris sekaligus (setiap baris diawali dengan "tambah"). Sebagai contoh:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Beritahu kami.

Saya tidak mengerti dengan jelas apakah Anda ingin menampilkan aplikasi jarak jauh di layar lokal Anda ( work), atau jika Anda ingin menampilkannya di sistem jarak jauh ( home).

Dalam kasus pertama, saya pikir ssh -X hostsudah cukup, tanpa perlu menggunakan xhost.

Dalam kasus kedua, sistem tempat Anda perlu menggunakan xhost adalah home, dan itu tidak cukup, Anda juga perlu mengekspor variabel tampilan.

xhost +work
export DISPLAY=:0.0

Saya tidak sepenuhnya yakin dengan apa yang ingin Anda lakukan ... dan karena saya tidak tahu perbedaan apa yang ada antara sistem Anda dan milik saya, di sisi pertama, dan konfigurasi persis yang diperlukan untuk casing Anda di sisi lain (seperti Saya bukan spesialis ^ _ ^). Semoga ini bisa membantu Anda dalam beberapa hal, karena konfigurasi ini juga berfungsi untuk saya.