Quando uso ssh -Xsul mio Mac (con OS X 10.6.7) per connettermi alla mia casella Ubuntu (11.04), ricevo il seguente avviso:

Avviso: impostazione di inoltro X11 non attendibile non riuscita: dati chiave xauth non generati Avviso: nessun dato xauth; utilizzando dati di autenticazione falsi per l'inoltro X11.

C'è qualcosa che posso fare per far sparire questo avviso? In caso contrario, posso tranquillamente ignorarlo?

L'inoltro X11 sembra funzionare bene, anche se vedo questo messaggio:

Xlib: estensione "RANDR" mancante sul display "localhost: 10.0".

È correlato all'avvertimento? (Suppongo di no. In caso contrario, invierò una nuova domanda a riguardo.)

Qualche motivo per cui non vuoi usare il flag -Y invece del flag -X?

Molto semplicemente, la differenza tra -X e -Y è che -Y abilita l'inoltro X11 affidabile.

Se arriverai qui nel 2015: anche se tutto il resto è impostato correttamente, questo può accadere anche su Mac OS X 10.10 Yosemite, quando si utilizza ssh -Xe si esegue una versione XQuartz <= 2.7.7. La causa principale è che i socket del display X11 vengono scritti al di fuori del percorso di ricerca di xauth: numero 2068 nel tracker XQuartz.

Modifica: Da allora è stato rilasciato un XQuartz fisso nella nuova homepage, xquartz.org , e l'installazione dell'ultima versione da lì (attualmente 2.7.9) risolverà il problema.

Se ricevi lo stesso messaggio anche durante l'utilizzo -Y, il xauthprogramma potrebbe non essere presente sul server. Su sistemi simili a Debian, è necessario il xauthpacchetto. Su sistemi simili a RedHat, è necessario il xorg-x11-xauthpacchetto.

"Non attendibile" in questo contesto significa che non ti fidi della connessione. SSH utilizzerà ulteriori misure di sicurezza per cercare di rendere più sicuro l'inoltro X11. "Attendibile" significa che sei del tutto sicuro che nessun accesso all'host remoto avrà accesso ai tuoi dati Xauth e lo userà per monitorare, ad esempio, i tasti premuti.

Questa terminologia in realtà mi ha confuso per anni. Pensavo che le connessioni "affidabili" fossero più sicure. Ma in realtà è un'opzione che dovresti usare in situazioni in cui la connessione È affidabile e vuoi eseguire roba senza ulteriori misure di sicurezza. "Non attendibile" è quello che rende (in qualche modo) più sicuro gestire un host remoto non attendibile.

Una connessione "Untrusted" tenta di limitare ciò che un black hat potrebbe farti impegnando l'estensione di sicurezza X11 e disabilitando altre estensioni che (si spera) non ti servono. Questo è probabilmente il motivo per cui RandR è disabilitato con -X. Devi essere in grado di ruotare il display X dall'host remoto?

È anche importante notare che l'inoltro X11 "non attendibile" si spegne dopo un certo periodo di tempo per impedirti di lasciarlo accidentalmente acceso. I nuovi tentativi di apertura di Windows falliranno dopo. Mi ha morso più volte prima di leggere abbastanza documenti per capire cosa stava succedendo.

Non ho una configurazione in grado di mostrare questo comportamento, quindi questa è una foto al buio:

L'avviso potrebbe essere soppresso se si imposta ForwardX11Trustedsu "no"per gli host che danno questo avviso. Puoi posizionarlo in uno ~/.ssh/configo /etc/ssh/ssh_config, e puoi rendere l'opzione specifica per un particolare host includendo Host <hostname>nella riga sopra. il <hostname>componente corrisponde a ciò che si digita sulla riga di comando (non il nome host risolto) e può includere caratteri jolly.

ATTENZIONE (stanco di leggere risposte incomplete che portano a un difetto di sicurezza)

1 / usare ssh -Y significa qui avere false informazioni xauth che sono cattive!

2 / ssh -X dovrebbe funzionare poiché XQuartz, una volta abilitato, utilizza xauth. L'unico problema è che ssh sta cercando xauth in / usr / X11R6 / bin e su macos con XQuartz è in / opt / X11 / bin

Soluzione sicura:

1 / Abilita la prima opzione nella scheda Sicurezza delle preferenze (Cmd-,) che abilita le connessioni autenticate

2 / aggiungi

XAuthLocation /opt/X11/bin/xauth

in $ HOME / .ssh / config

3 / ssh -X you_serverfunziona in modo sicuro

Se l'installazione xauthnon funziona correttamente, un caso particolarmente fastidioso potrebbe essere un .Xauthorityfile danneggiato . Questo caso particolare ha permesso ad alcuni client X di funzionare, ma non altri con una maggiore tendenza a fallire con i display più recenti. Rimuovere e ricreare il .Xauthorityfile può risolvere questo problema.

Escludere problemi sul lato server

Innanzitutto, è necessario escludere eventuali problemi sul lato server. Sei in grado di eseguire ssh -Xcorrettamente qualsiasi altro host? Funziona ssh -Ymentre ssh -Xno? In entrambi i casi, supponi che ssh + X11 sia impostato correttamente sul tuo server e passa alla sezione successiva.

Se non sei in grado di verificarlo (hai solo un laptop con X11, diciamo), puoi sshdal server a se stesso usando una sessione falsa:

1. export DISPLAY=:44# (Bourne shell) o
   setenv DISPLAY :44# (csh / tcsh)
2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Cookie fasullo solo per questo test
3. ssh -X localhost env |grep DISPLAY

Risultato previsto: dovrebbe essere impostata una variabile DISPLAY sull'estremità remota della sessione ssh-to-self. Se non si ottiene alcun risultato, è probabile che il proprio server sia configurato in modo errato (ad esempio, le librerie X11 e / o il xauthcomando potrebbero mancare; oppure la configurazione sshd potrebbe essere impostata per negare l'accesso X11)

Su Mac: controlla che Xquartz sia aggiornato

Secondo la risposta di Will Angley

Esamina l' ssh -vv -Xoutput

Il messaggio di errore che citi è un sintomo che può avere molte cause. Riprova con , che dovrebbe fornirti ulteriori indizi sul perché l'installazione del tunnel X11 non è riuscita.ssh -X -vv remotehost

Viene visualizzato il seguente messaggio?

debug1: nessun programma xauth.

1. Prendi nota di dove sul tuo sistema client, il xauthcomando risiede:

   quale xauth

2. Aggiungi quanto segue alla fine del tuo ~ / .ssh / config (e aggiungi un commento per ricordare a te stesso di mantenerlo lì in futuro):

   Ospite *
       XAuthLocation / opt / X11 / bin / xauth
   

   Regola questo percorso in base ai risultati del passaggio 1 - Crediti a Jan-Willem Arnold

Come è già stato spiegato sopra, per me ha funzionato:

Modifica ~ / .ssh / config per aggiungere le righe

Host *
    XAuthLocation /opt/X11/bin/xauth

e ora funziona ssh -X hostname (XQuartz 2.7.11, macOS 10.4 Mojave)

Avevo già installato l'ultimo XQuartz 2.7.11, ma credo di aver aggiornato anche il sistema operativo alcune volte da allora. Ho reinstallato XQuartz 2.7.11 e ora funziona perfettamente.

xauth aggiungi `hostname` / unix: 10 MIT-MAGIC-COOKIE-1` openssl rand -hex 16`