Quando utilizzo un server remoto che non esegue alcun tipo di ambiente desktop X11, ricevo il seguente messaggio.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

Come posso eliminare questi messaggi?

Questi messaggi possono essere eliminati attraverso 1 di 3 metodi, usando solo le opzioni SSH. Puoi sempre inviare anche messaggi a, /dev/nullma questi metodi tentano di gestire il messaggio attraverso la configurazione, piuttosto che semplicemente intercettarli e scaricarli.

Metodo n. 1: installa xauth

Il server in cui stai remotando si lamenta che non è possibile creare una voce nel .Xauthorityfile dell'utente , perché xauthnon è installato. Quindi puoi installarlo su ogni server per sbarazzarti di questo fastidioso messaggio.

Su Fedora 19 si installa xauthcosì:

$ sudo yum install xorg-x11-xauth

Se poi provi ad sshentrare nel server vedrai un messaggio che sta creando una voce nel .Xauthorityfile dell'utente .

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Gli accessi successivi non mostreranno più questo messaggio.

Metodo n. 2: disabilitalo tramite ForwardX11

È possibile sshindicare al client di non tentare di abilitare l'inoltro X11 mediante l'inclusione del parametro SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Puoi fare la stessa cosa con l' -xinterruttore:

$ ssh -x root@server

Questo disabiliterà temporaneamente questo messaggio, ma è una buona opzione se non sei in grado o non sei disposto a installare xauthsul server remoto.

Metodo n. 3: disabilitalo tramite sshd_config

Questo è in genere il valore predefinito, ma in caso contrario, è possibile configurare il sshdserver in modo che X11Forwarding sia disattivato, in /etc/ssh/sshd_config.

X11Forwarding no

Dei 3 metodi che uso generalmente # 2, perché spesso vorrò X11Forwardingattivare la maggior parte dei miei server, ma poi non voglio vedere gli X11....avvisi

$ HOME / .ssh / config

La maggior parte delle volte questi messaggi non vengono nemmeno visualizzati. Di solito sono presenti solo quando hai le seguenti voci nel tuo $HOME/.ssh/configfile, in alto.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Quindi è questa configurazione, che alla fine sta guidando la generazione di quei X11..messaggi, quindi, di nuovo, il metodo n. 2 sembrerebbe il più appropriato se si desidera operare con ForwardX11 yeson per impostazione predefinita, ma poi disabilitarlo selettivamente per determinate connessioni dal sshpunto di vista del client .

Sicurezza

È generalmente sconsigliato di continuare a giocare ForwardX11 yessempre. Quindi, se vuoi gestire le tue connessioni SSH nel maniero più sicuro possibile, è meglio fare quanto segue:

1. Non includere ForwardX11 yesnel tuo $HOME/.ssh/configfile
2. Utilizzare ForwardingX11 solo quando è necessario tramite ssh -X user@server
3. Se possibile, disabilitare X11Forwardingcompletamente sul server in modo che non sia consentito

Riferimenti

• SSH: The Secure Shell - The Definitive Guide - 9.3. X Forwarding

Nel mio caso l'aggiunta di questa stringa per /etc/ssh/sshd_configrisolvere il problema:

X11UseLocalhost no

Mi sono imbattuto in questo oggi e ho battuto la testa per un po 'fino a quando mi sono imbattuto in un'impostazione ssh:

Se è RHEL 7 (centOS, OEL, ecc.) E ipv6 è disabilitato, è necessario:

AddressFamily inet

impostato in / etc / ssh / sshd_config.

Un'altra leggera variazione sarebbe se si volesse smettere di vedere questo messaggio (cioè smettere di provare a inoltrare X11) per alcuni server ma mantenere comunque l'impostazione predefinita di ForwardX11 sì per tutte le altre connessioni.

Per questo scenario, è possibile disabilitare l'inoltro X11 per un host (o intervallo) specifico nella propria ~ / .ssh / config. Qualcosa come questo:

host 10.1.1.*
ForwardX11 no 

Ringraziamento: questo è un leggero abbellimento per la risposta esistente (e molto completa) esistente - dal momento che non ho potuto commentare!

Se si esegue il client in modalità dettagliata ( ssh -v user@host) ti dà

debug1: Remote: No xauth program; cannot forward with spoofing.

ma xauthè effettivamente installato sul server, quindi è probabilmente perché sshd cerca xauth eseguibile in una posizione errata ( / usr / X11R6 / bin / xauth di solito). Si può risolvere ciò impostando

XAuthLocation /usr/bin/xauth

in / etc / sshd / sshd_config (o qualunque cosa sia configurato il tuo server).

Configurazione dell'inoltro X11 su base host

Oltre a tutte le eccellenti risposte già qui, puoi configurare ForwardX11su base per host, quindi se solo serverfallisce in questo modo, puoi aggiungere una voce al tuo ~/.ssh/configfile nel seguente modulo:

Host server server.domain.dom
    ForwardX11 no

Puoi persino usare voci come questa come allias per interi set di configurazioni

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Ciò è particolarmente utile se sono stati impostati nomi di server di completamento automatico per SSH e SCP .

Mi sono imbattuto in questa domanda dopo un incontro con un sshd-xauthbug di quasi un decennio. Vengono segnalate due soluzioni, la prima che esclude xauth, la seconda che risolve il problema.

Soluzione 1: bypassare xauth

• local: il computer locale che serve un Xserver.
• remote - la macchina remota che serve l'applicazione che guida i dati che vanno all'Xserver

Remoto /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Il telecomando ~/.Xauthorityè vuoto o non esiste

Sul locale:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

Nel test, local eseguiva Ubuntu 18.05, il telecomando eseguiva Debian Jesse.

Ho anche pubblicato questa soluzione come risposta a un'altra domanda.

Soluzione 2: risolvere il bug sshd / xauth

Questa soluzione è vicino a @systempoet 's soluzione di cui sopra , anche se questo da solo non era sufficiente.

Oltre a modificare /etc/ssh/sshd_configsul telecomando:

AddressFamily inet

/etc/hosts sul telecomando è stato anche modificato:

::1     localhost ip6-localhost ip6-loopback

Se uno dei due è stato commentato, il messaggio di errore

X11 forwarding request failed on channel 0

è apparso dopo la ssh -X ...chiamata. Inoltre, ha /var/log/auth.logmostrato l'errore:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Test per produrre il bug (prima della correzione):

Macchina locale:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0

Un punto importante da notare dopo aver apportato le modifiche alla configurazione è che dovrai eliminare sshd in modo che raccolga le modifiche:

cat /var/run/sshd.pid | xargs kill -1

essere l'utente root.

1. Impostare le seguenti 2 opzioni /etc/ssh/sshd_confignell'host RHEL

   X11Forwarding yes X11UseLocalhost no

2. sudo /etc/init.d/sshd reload

3. sudo yum install xauth
4. ssh torna al tuo host RHEL con l'opzione -X: ssh -X yourname@rhelbox