Come posso eseguire il debug "Connessione X11 rifiutata a causa di un'autenticazione errata"

Ho un problema con l'inoltro X tramite SSH. Ho combattuto per anni, ma nessuno può sembrare d'aiuto.

Ora sto prendendo un tatto diverso. Vorrei sapere come eseguire il debug degli errori?

Quali log dovrei cercare, quali flag extra dovrei impostare (-v etc) e cosa dovrei cercare?

Ulteriore modifica:

Se accedo a Putty nel server e provo xeyes, ottengo:

Proxy PuTTY X11: tentativo di protocollo di autorizzazione errato Errore: impossibile aprire display: localhost: 10.0

Se xauth generate $DISPLAYottengo:

Proxy PuTTY X11: tentativo di protocollo di autorizzazione erratoxauth: (argv): 1: impossibile aprire il display "localhost: 10.0".

La mia soluzione passo dopo passo:

1) accedi con l'opzione -X root di login dell'host remoto

$ ssh -X root@192.168.1.39

2) controlla se esiste un file .Xauthority esistente

[root @ localhost ~] # ls -al
[root @ localhost ~] # vim .Xauthority

3) copia il file .Xauthority nella directory dell'altro utente

[root @ localhost ~] # cp .Xauthority / home / oracle /
cp: sovrascrivi `/home/oracle/.Xauthority '? y

4) impostare le autorizzazioni per questo file

[root @ localhost ~] # chacle oracle: oinstall .Xauthority
[root @ localhost ~] # chmod 0600 .Xauthority

5) login oracle user

[root @ localhost ~] # su - oracle

6) impostazione di visualizzazione in localhost: 10.0

[oracle @ localhost ~] $ echo $ DISPLAY
localhost: 10.0
[oracle @ localhost ~] $ ls -al

7) elenca i cookie xauth esistenti

[oracle @ localhost ~] $ xauth list
localhost.localdomain / unix: 11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b
localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759

8) aggiungendo

[oracle @ localhost ~] $ xauth aggiungi localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75

9) test

[oracle @ localhost ~] $ xclock

Spero che servano! @wcaraza

Assicurarsi che sul server SSH sia xauthinstallato lo strumento e che il ~/.Xauthorityfile sia scrivibile. (Inesistente va bene, purché xauthpossa crearlo.)

Controlla se i dati xauth sono in fase di aggiornamento:

server$ xauth list

Prova ad aggiungere manualmente i dati fittizi xauth (di nuovo, sul server SSH), e vedi se ci xauthsono problemi (ad es. Non essere in grado di creare il file di blocco o modificare il file Xauthority stesso):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

Se necessario, rieseguire sotto strace.

Eseguire il servizio SSH in modalità debug, impostando LogLevel DEBUG2nella configurazione del server ( /etc/ssh/sshd_config) o avviando direttamente sshd in modalità debug:

server$ sshd -rddp 12234

(In questo esempio, 12234è la porta SSH temporanea a cui è necessario connettersi. Qualsiasi porta libera lo farà.)

Funziona, funziona. haha.

FINALMENTE.

Dopo aver scoperto che non era il sistema, aggiungendo un utente di prova (il cui inoltro x ha funzionato "out the box"), ho pensato di iniziare a copiare i file di avvio .bash * per vergognare l'utente "non funzionante".

Nessuno dei file era diverso, quindi ho eliminato la directory .ssh degli utenti. Quando ho registrato, si è lamentato di "Il server ha rifiutato la nostra chiave", ma ho potuto accedere utilizzando la password. Una volta effettuato l'accesso, potrei x inoltrarmi perfettamente.

Ora proverò di nuovo ad impostare la chiave e vedrò se riesco a farlo funzionare anche. Quindi tornerà alla normalità.

Un'altra cosa che può causare questo problema è l'esistenza di un ~/.ssh/rcfile sul server: la macchina a cui ti stai connettendo. Eliminalo (o rinominalo) per risolvere il problema.

rm ~/.Xauth* e quindi riconnettersi.

Questo funziona per me. Per maggiori dettagli