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

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

Questo succede anche per strumenti che usano ssh, come git o mercurial.

Voglio solo apportare una modifica locale al mio sistema per evitare che ciò appaia.

Nota: ho un 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 da remoto.

Nessuna delle soluzioni pubblicate ha funzionato per me. Il mio sistema client (desktop) esegue macOS 10.12.5 (Sierra). Ho aggiunto -valle opzioni per il sshcomando e mi ha detto,

debug1: No xauth program.

il che significa che non ha un percorso corretto per il xauthprogramma. (In questa versione di macOS il percorso xauthè non standard.) La soluzione era aggiungere questa riga a /etc/ssh/ssh_config(potrebbe essere /etc/ssh/configin alcune configurazioni) o in ~/.ssh/config(se non si dispone dei diritti di amministratore):

XAuthLocation /opt/X11/bin/xauth

Ora il messaggio di avviso è sparito.

Trovato la causa, la mia ~/.ssh/configera incompleta, hai bisogno di entrambi:

Host *
    ForwardAgent yes
    ForwardX11 yes

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

Lasciare Ubuntu bash su Windows 10 eseguito ssh -X per ottenere un ambiente GUI su un server remoto

• Primo

Installa tutto quanto segue. Su Windows, installa Xming. Su Ubuntu bash, usa sudo apt installper installare ssh xauth xorg.

sudo apt install ssh xauth xorg

• Secondo

Vai alla cartella contiene ssh_configfile, il mio è /etc/ssh.

• Terzo

Modifica ssh_configcome amministratore (USA sudo). All'interno ssh_config, rimuovere l'hash #nelle linee ForwardAgent, ForwardX11, ForwardX11Trusted, e impostare i corrispondenti argomenti yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• Via

Nel ssh_configfile, rimuovi l'hash anteriore #prima Port 22e Protocol 2, e aggiungi anche una nuova riga alla fine del file per indicare la posizione del file xauth XauthLocation /usr/bin/xauth, ricorda di scrivere il tuo percorso del file xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth

• Quinto

Ora che abbiamo finito di modificare il ssh_configfile, salvalo quando lasciamo l'editor. Ora vai alla cartella ~o $HOME, aggiungi export DISPLAY=localhost:0al tuo .bashrcfile e salvalo.

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

• Ultimo

Abbiamo quasi finito. Riavvia la shell bash, apri il Xmingprogramma e usalo ssh -X yourusername@yourhost. Quindi goditi l'ambiente della GUI.

ssh -X yourusername@yourhost

Il problema si trova anche nel sottosistema Ubuntu su Windows e il collegamento è all'indirizzo

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

Nota: il testo collegato include 2 errori di battitura ( XauthLocaionanziché XauthLocation)

Come notato, sembra che xauthsu OS X Yosemite sia regredito a una versione precedente che non funziona con le $DISPLAYimpostazioni di 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 comportato l'aggiunta di quanto segue 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 file pipe associato alla tua radice X non può essere gestito correttamente, e quindi necessita di correzione. :-)

Compreso

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

nel mio macOS Sierra 10.12.6 ha funzionato per me. Un piccolo cambiamento dalla risposta 7).

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

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

export $(dbus-launch)

Ho aggiunto anche in precedenza:

export XAUTHORITY=~/.Xauthority 

per assicurarsi che il telecomando chiamato con ssh -X ̍ @ lo troverà.

Nel mio caso. Xauthority è un link simbolico all'utente originale /home//.Xauthority che ho 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 

quindi è accessibile da e verso. sarà in grado di attivare le app e visualizzare i risultati X-windowed sulla sua schermata locale attraverso l'account proxy!

SUGGERIMENTO: controlla l'elenco xauth ... se riflette il cookie magico.

Vorrei aggiungere questo come commento, ma non ho abbastanza rappresentante. L'aggiunta di un'altra riga alla soluzione di Sorin ha funzionato per me.

Apri il tuo file di configurazione ssh con vim ~/.ssh/config Quindi aggiungi queste righe:

Host *
    ForwardAgent yes
    ForwardX11 yes
    XAuthLocation /opt/X11/bin/xauth

Puoi ricontrollare la tua xauthposizione con:

which xauth