Come posso impedire l'avviso No xauth data; utilizzando dati di authentication falsi per l'inoltro X11?

Ogni volta che avvia una connessione ssh dal mio Mac a un Linux (Debian) ho questo avviso:

No xauth data; using fake authentication data for X11 forwarding. 

Ciò accade anche per gli strumenti che utilizzano ssh, come git o mercurial.

Voglio solo fare una modifica locale al mio sistema per impedire che questo venga visualizzato.

Nota: Ho il server X11 (XQuartz 2.7.3 (xorg-server 1.12.4)) sul mio Mac OS X (10.8.1) e funziona correttamente, posso avviare correttamente l'orologio localmente o in remoto.

8 Solutions collect form web for “Come posso impedire l'avviso No xauth data; utilizzando dati di authentication falsi per l'inoltro X11?”

Nessuna delle soluzioni pubblicate ha funzionato per me. Il mio sistema client (desktop) è in esecuzione macOS 10.12.5 (Sierra). Ho aggiunto -v alle opzioni per il command ssh e mi ha detto,

 debug1: No xauth program. 

il che significa che non ha un path corretto al programma xauth . (Su questa versione di macOS il path di xauth non è standard). La soluzione whereva essere quella di aggiungere questa row a /etc/ssh/ssh_config :

 XAuthLocation /opt/X11/bin/xauth 

Ora il messaggio di avviso è andato.

Trovato la causa, il mio ~/.ssh/config era incompleto, hai bisogno sia:

 Host * ForwardAgent yes ForwardX11 yes 

Il mio errore era che ho incluso solo l'opzione ForwardX11.

Come è stato osservato, sembra che xauth su OS X Yosemite ha regredito una vecchia versione che non funziona con l'impostazione $DISPLAY XQuartz:

 % xauth -V 1.0.9 % xauth generate $DISPLAY . xauth: (argv):1: bad display name "/private/tmp/com.apple.launchd(...)/org.macosforge.xquartz:0" in "add" command 

C'è un bug in MacOS al momento. Mi sono imbattuto anche in questo. La correzione per me ha comportto l'aggiunta dei seguenti elementi al mio .bash_profile

 dispdir=`dirname $DISPLAY` dispfile=`basename $DISPLAY` dispnew="$dispdir/:0" if [ -e $DISPLAY -a "$dispfile" = "org.x:0" ]; then mv $DISPLAY $dispnew fi export DISPLAY=$dispnew 

In sostanza, il nome del pipe file associato alla tua root X non può essere gestito correttamente e pertanto ha bisogno di correzione. 🙂

Lasciando bash su Windows 10 eseguire ssh -X per get un ambiente GUI su un server remoto

  • Primo

Installare tutto quanto segue. Nella window, installare Xming . Su Ubuntu bash, usa sudo apt install per installare ssh xauth xorg .

 sudo apt install ssh xauth xorg 
  • Secondo

Vai alla cartella contenente file ssh_config , la mia è /etc/ssh .

  • Terzo

Modificare ssh_config come amministratore (USE sudo ). All'interno di ssh_config , rimuovere il hash # nelle righe ForwardAgent , ForwardX11 , ForwardX11Trusted e impostare gli argomenti corrispondenti a yes .

 # /etc/ssh/ssh_config Host * ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes 
  • Via

Nel file ssh_config , rimuovere il hash front # prima della Port 22 e del Protocol 2 e aggiungere una nuova row alla fine del file per indicare la posizione del file xauth, XauthLocaion /usr/bin/xauth , ricordatevi di scrivere il proprio path di xauth file.

 # /etc/ssh/ssh_config # IdentifyFile ... Port 22 Protocol 2 # Cipher 3des # ... # ... ... ... GSSAPIDelegateCredentials no XauthLocaion /usr/bin/xauth 
  • Quinto

Ora che abbiamo finito di modificare il file ssh_config , salvarlo quando lasciamo l'editor. Ora vai alla cartella ~ o $HOME , aggiungi export DISPLAY=localhost:0 al tuo file .bashrc e salva.

 # ~/.bashrc ... ... export DISPLAY=localhost:0 
  • Ultimo

Siamo quasi finiti. Riavviare la shell bash, aprire il programma Xming e utilizzare ssh -X yourusername@yourhost . Quindi godere dell'ambiente GUI.

 ssh -X yourusername@yourhost 

Il problema è anche nel sottosistema di Ubuntu in Windows e il collegamento è a

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

ho appena rimosso ~ / .Xauthority (macchina di destinazione) dalla mia cartella principale e ssh -X 192.168.123.1 ancora e ik funzionato.

Nel mio caso era il problema di .Xauthority contenente il cookie Magic non inoltrato, Fabby su http://askubuntu.com/questions/571116/ raccomanda il 2014-11-14 per aggiungere questa row alla fine del .bashrc o . profilo per consentire l'inoltro di chiavi xauth tra gli utenti quando si chiama su:

 export $(dbus-launch) 

Ho aggiunto anche precedentemente:

 export XAUTHORITY=~/.Xauthority 

per assicurare che il telecommand chiamato con ssh -X ̍ @ lo troverà.

Nel mio caso .Xauthority è un symlink per l'utente originale /home//.Xauthority I su da …

  cd /home/<child_user>;ln -sf /home/<parent_user>/.Xauthority .xAuthority 

con diritti corretti:

  sudo chown <parent_user> /home/<parent_user>/.profile chmod a+rw /home/<parent_user>/.profile 

così è accessibile da e verso. sarà in grado di triggersre le applicazioni e visualizzare il risultato X-window sul proprio schermo locale in tutto il conto proxy!

SUGGERIMENTO: Controlla list xauth … se riflette il cookie magico.

Compreso

XAuthLocation / opt / locale / bin / xauth in ~ / .ssh / config

nella mia macOS Sierra 10.12.6 mi ha lavorato. Un piccolo cambiamento dalla risposta 7).

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.