Błąd przekazywania X11 tylko na jednym serwerze

Mam dwa komputery: PC1 i PC2. Oba mają identyczną instalację Debian Wheezy z najnowszymi aktualizacjami. Instalacja na PC2 została pobrana z PC1 przy użyciu tar. Jedynymi różnicami między PC1 i PC2 są wpisy grub, nazwa hosta, zawartość /etc/hostsi adres IP. Konfiguracja SSHD obu komputerów jest identyczna:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

#AddressFamily inet

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts                                                                                                             
RhostsRSAAuthentication no                                                                                                                                                          
# similar for protocol version 2                                                                                                                                                    
HostbasedAuthentication no                                                                                                                                                          
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication                                                                                                       
#IgnoreUserKnownHosts yes                                                                                                                                                           

# To enable empty passwords, change to yes (NOT RECOMMENDED)                                                                                                                        
PermitEmptyPasswords no                                                                                                                                                             

# Change to yes to enable challenge-response passwords (beware issues with                                                                                                          
# some PAM modules and threads)                                                                                                                                                     
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Mogę sshz PC2 na PC1 i dobrze uruchamiać programy GUI. Ale nie mogę uruchamiać programów GUI zdalnie na PC2 z dowolnego komputera (w tym samego PC2). Oto wynik dostałem podczas próby uruchomienia xtermpo ssh -Xvvv localhostna PC2:

user@pc2:~$ xterm
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 42667
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: write failed
debug2: channel 1: close_write
debug2: channel 1: output open -> closed
debug2: X11 closed 1 i3/o3
debug2: channel 1: send close
debug2: channel 1: rcvd close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
  #1 x11 (t7 r3 i3/0 o3/0 fd 7/7 cc -1)

xterm: Xt error: Can't open display: pc2:11.0

Uprawnienia i własność ~ / .Xauthority wyglądają normalnie:

user@pc2:~$ ls -l ~/.Xauthority 
-rw------- 1 user user 301 Aug 27 13:49 /home/user/.Xauthority

Próbowałem rozwiązać ten problem od wielu godzin, google, ale wydaje się, że nigdzie się nie dostaję. Potrzebuję twojej pomocy.

linux ssh Larssend
źródło

Sprawdź, czy masz plik ~/.ssh/rclub /etc/ssh/sshrcna serwerze. Zgodnie z tym pytaniem , jeśli jeden z tych skryptów istnieje, sshduruchomi go podczas uruchamiania sesji, a skrypt jest odpowiedzialny za wywołanie w xauthcelu skonfigurowania uwierzytelnienia X11. Jeśli żaden z tych plików nie istnieje, sshd wywołuje xauthbezpośrednio. Możliwe, że masz jeden z tych plików na zdalnym serwerze i nie działa on poprawnie.

OpenSSH sshd strona podręcznika zawiera przykładową Shellcode który powinien uruchomić skrypt rc skonfigurować XAUTH:

Jeśli przekazywanie X11 jest w użyciu, otrzyma parę „proto cookie” na swoim standardowym wejściu (i WYŚWIETLANIE w swoim otoczeniu). Skrypt musi wywoływać xauth (1), ponieważ sshd nie uruchomi xauth automatycznie, aby dodać pliki cookie X11.

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

Kenster
źródło

Błąd przekazywania X11 tylko na jednym serwerze

Odpowiedzi: