SSH X11 çalışmıyor

Bir ev ve iş bilgisayarım var, ev bilgisayarının statik bir IP adresi var.

İş bilgisayarımdan ev bilgisayarıma ssh yaparsam, ssh bağlantısı çalışır, ancak X11 uygulamaları görüntülenmez.

Benim evimde /etc/ssh/sshd_config:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

İş yerinde aşağıdaki komutları denedim:

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

İşte benim /etc/ssh/ssh_config:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

İşte benim ~/.ssh/config:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

İşte benim ~/.Xauthority:

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

Benim ~/.Xauthorityevim:

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

Ama işe yaramıyor

Eve bir ssh bağlantısı yaptıktan sonra:

$ 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

iptablesEvde kullanıyorum ama 22 numaralı limana izin verdim. Okuduğum şeye göre ihtiyacım olan tek şey bu.

UPD. İle-vvv

...
debug2: geri arama başlangıcı
debug2: x11_get_proto: / usr / bin / xauth listesi: 0 2> / dev / null
debug1: Kimlik doğrulama kimlik sahtekarlığıyla X11 iletimi isteniyor.
debug2: kanal 1: istek x11-req onay 1
debug2: client_session2_setup: kimlik 1
debug2: fd 3 ayarı TCP_NODELAY
debug2: kanal 1: pty-req onay 1 iste
...

Başlatmaya çalıştığınızda kate:

debug1: client_input_channel_open: ctype x11 rchan 2 galibiyet 65536 max 16384
debug1: client_request_x11: 127.0.0.1 55486'dan istek
debug2: fd 8 ayarı O_NONBLOCK
debug3: fd 8, O_NONBLOCK
debug1: kanal 2: yeni [x11]
debug1: x11'i onaylayın
debug2: X11 bağlantısı farklı kimlik doğrulama protokolü kullanıyor.
X11 bağlantısı yanlış kimlik doğrulaması nedeniyle reddedildi.
debug2: X11, 2 i0 / o0'u reddetti
debug2: kanal 2: okuma başarısız
debug2: kanal 2: close_read
debug2: kanal 2: giriş açık -> tahliye
debug2: kanal 2: ibuf boş
debug2: kanal 2: gönder eof
debug2: kanal 2: giriş tahliyesi -> kapalı
debug2: kanal 2: yazma başarısız
debug2: kanal 2: close_write
debug2: kanal 2: çıkış açık -> kapalı
debug2: X11 kapalı 2 i3 / o3
debug2: kanal 2: gönder kapat
debug2: kanal 2: rcvd kapat
debug2: kanal 2: öldü
debug2: kanal 2: çöp toplama
debug1: kanal 2: ücretsiz: x11, kanallar 3
debug3: kanal 2: durum: Aşağıdaki bağlantılar açık:
  1 numaralı müşteri oturumu (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Yukarıdaki ile aynı 7 kez tekrarlayın

kate: X sunucusu localhost'a bağlanamıyor: 10.0

UPD2 Lütfen Linux dağıtım ve sürüm numaranızı belirtin .
X için varsayılan bir GNOME veya KDE ortamı mı yoksa kendinizi özelleştirdiğiniz başka bir şey mi kullanıyorsunuz?

azat: ~ $ kded4-sürüm
Qt: 4.7.4
KDE Geliştirme Platformu: 4.6.5 (4.6.5)
KDE Daemon: $ Kimlik $

Ssh'yi doğrudan terminal penceresinden bir komut satırında mı çağırıyorsunuz?
Hangi terminali kullanıyorsunuz? xterm, gnome terminali veya?
X ortamında terminali nasıl çalıştırdınız? Bir menüden mi? Kısayol? veya?

Terminal öykünücüsü `yakuake'den
Manuel olarak `Ctrl + N` tuşlarına basın ve komutları yazın

Ssh -X'in başarısız olduğu terminal penceresinden xeyes çalıştırabilir misiniz?

"xeyes" - kurulu değil
Ancak "kate" veya başka bir kde uygulaması çalışıyor

Ssh komutunu X oturumunda oturum açtığınız kullanıcıyla mı çağırıyorsunuz?
From the same user

UPD3

Ayrıca sshkaynakları da indiriyorum ve debug2()yazma neden sürümün farklı olduğunu rapor kullanarak
Bazı çerezleri görmek ve bunlardan biri boş, diğeriMIT-MAGIC-COOKIE-1

Ssh X yönlendirme çalışmama nedeni bir /etc/ssh/sshrcyapılandırma dosyası var çünkü .

sshd(8)Kılavuz sayfasının sonu şunları belirtir:

Varsa ~/.ssh/rc, çalıştırır; başka /etc/ssh/sshrcvarsa, çalıştırır; aksi takdirde xauth çalıştırır

Bu yüzden /etc/ssh/sshrcsunucu tarafında aşağıdaki komutları da (sshd man sayfasından) ekliyorum :

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

Ve çalışıyor!

Ssh ile herhangi bir sorun yaşarsanız, yapmanız gereken ilk şey, istemciyi -vbaşkalarının incelemesi için bu çıktıyı sağlama seçeneğiyle çalıştırmaktır :

ssh -v user@somewhere

Sorunun yerel sisteminizde olduğunu tahmin edeceğim. Ssh komutunu nasıl çağırıyorsunuz? Elle bir kabukta mı çalıştırıyorsunuz? Yoksa bir komut dosyasının parçası olarak mı yürütülüyor? Her iki durumda da, yerel sisteminizin DISPLAYortamın doğru ayarlandığından emin olmak istersiniz . Ayrıca, uzak tarafta da doğru şekilde ayarlanması gerekir, ancak bu değer uzak tarafta yerel taraftan farklı olacaktır .

Yazdıklarınızdan uzak ana bilgisayarda doğru ayarlandığı anlaşılıyor (ve X11 iletimi ssh tarafından doğru bir şekilde ayarlanıyor). Uzak sistemde:

$ echo $DISPLAY
localhost:10.0

Yerel tarafta bu ne gösteriyor? Kabukta olup olmadığınızı kontrol etmek kolay olmalı, hem de bu kabuktan bir X uygulaması başlatarak ... xeyeselbette bu tür testler için her zaman saygıdeğer kullanabilirsiniz ! :)

Öte yandan, bir komut dosyasından ssh komutunu çağırıyorsanız veya bir kısayol tuşuna bağlıysanız, beklediğiniz ortamı devralmayabilir, bu nedenle DISPLAYyerel taraftaki ortam değişkeni hiç ayarlanmamış olabilir.

Ayrıca, .Xauthoritydosyanızla uğraşıyor gibi göründüğünden , tamamen silmek, ardından X oturumunuzdan çıkıp otomatik olarak yeniden oluşturması için tekrar oturum açabilirsiniz. Nadiren seninle uğraşmaya ihtiyaç vardır .Xauthority, bu yüzden denemek muhtemelen yardımcı olmayacak umutsuz bir önlemdir.

Yerel tarafta görmeniz gereken şey:

$ echo $DISPLAY
:0.0

Düzgün yapılandırılmış bir sistemde, bir kabuğu açarsanız, elle ayarlamanız gerekmez, kabuğunuzu başlatan ortamdan miras alınmalıdır. Ancak düzgün bir ortam değişkeni miras işlemeyen pencere yöneticisi / kısayol yapılandırmaları gördük. Linux sisteminiz çalışıyorsa gnome-sessionveya kde-sessionkabuklarınızı veya komut dosyalarınızı başlatmak için kullanıyorsanız, X oturum ortamı değişkenleriniz , ortam değişkenlerinin mirasıyla ilgili Ubuntu belgelerinde açıklandığı gibi doğru şekilde ayarlanmalıdır :

Bir üst işlem bir alt işlem oluşturduğunda, örneğin terminalden "gedit" komutunu çalıştırdığımızda ve "bash" (üst işlem) "gedit" (alt işlem) oluşturduğunda, alt işlem tüm ortam değişkenlerini devralır ve Üst sürecin sahip olduğu değerler.

...

Not: Gnome grafik masaüstü ortamında gnome-session, masaüstünde çalışan tüm işlemlerin üst sürecidir. Bu gerçek (Kalıtım prensibi ile birlikte), masaüstümüzün ortam değişkenleri ile çalışmasını güçlü bir şekilde etkileme yeteneğimizin anahtarıdır. KDE'de eşdeğer işlem kde-session'dur.

GÜNCELLENMİŞ

Çıkışını gönderdiğiniz için teşekkür ederiz ssh -vvv. Bu durumda, -vvvsadece karşısındaki ekstra ayrıntı -vyararlıdır. Hata ayıklama çıktısı bana X11 iletmenin doğru ayarlandığını söylüyor:

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

Ancak :0ilk satırda, ssh'yi çağırdığınız şekilde yerel tarafta hala bir yapılandırma hatası olduğuna inanıyorum. Birçok sistemlerde varsayılan değeri DISPLAYolan :0.0değil :0. DISPLAYSsh komutunu başlatmadan önce bir şekilde manuel olarak kendinizin değerini ayarlıyor musunuz ?

Yerel sisteminiz ve ssh komutunu nasıl çağırdığınız hakkında daha fazla bilgi bu noktada yardımcı olacaktır.

• Lütfen Linux dağıtım ve sürüm numaranızı girin.
• X için varsayılan bir GNOME veya KDE ortamı mı yoksa kendinizi özelleştirdiğiniz başka bir şey mi kullanıyorsunuz?
• Ssh'yi doğrudan terminal penceresinden bir komut satırında mı çağırıyorsunuz?
• Hangi terminali kullanıyorsunuz? xterm, gnome terminali veya?
• X ortamında terminali nasıl çalıştırdınız? Bir menüden mi? Kısayol? veya?
• Başarısız xeyesolduğu aynı terminal penceresinden çalışabilir misiniz ssh -X?
• Ssh komutunu X oturumunda oturum açtığınız kullanıcıyla mı çağırıyorsunuz?

Bu son madde önemlidir. (Bunun yerine bir kullanıcı terminal penceresinde bir kök terminal penceresi açtı eğer örneğin) başka bir kullanıcı olarak ssh çalıştırıyorsanız, o zaman açıkça ayarlarken bile bu sorunla karşılaşırsınız DISPLAY=:0Eğer izinleri olmadığı için X sunucusuna varsayılan olarak başka bir kullanıcı olarak bağlanın (root olarak bile!)

Yapılandırmalarınız iyi görünüyor, ancak Agemen'in önerdiği gibi "ssh -X home" komutunu deneyin.

Ayrıca, her şey başarısız olursa şunu deneyin:

İşten ev makinenize ssh yaptıktan sonra, "ev" yazın:

xauth list

Ardından, "work" (iş) üzerine şunu yazın:

xauth

Bu size bir "xauth>" istemi verecektir. Buradan "add" yazın, sonra "xauth list" in çıktısını kopyalayın, her seferinde bir satır (her satır "add" ile başlıyor). Örneğin:

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> 

Bilmemize izin ver.

Uzak uygulamalarınızı yerel ekranınızda ( work) görüntülemek mi, yoksa uzak sistemde görüntülemek mi ( ) anlamıyorum home.

İlk durumda, sanırım ssh -X hostxhost kullanmaya gerek kalmadan yeterli olmalı.

İkinci durumda, xhost'u kullanmanız gereken sistem homeyeterlidir ve yeterli değildir, görüntüleme değişkenini de dışa aktarmanız gerekir.

xhost +work
export DISPLAY=:0.0

Ne yapmak istediğinizden tam olarak emin değilim ... ve sisteminiz ile benimki arasında hangi farkların var olduğunu bilmediğim için, ilk elden ve sizin için gereken tam konfigürasyon Ben uzman değilim ^ _ ^). Umarım bazı şekillerde size yardımcı olur, çünkü bu da konfigürasyonlar benim için çalıştı.