2014-09-03 10:44:44 +0000 2014-09-03 10:44:44 +0000
30
30

xauth non crea il file .Xauthority

Quando ssh in un sistema Linux Mint 17 senza testa, non crea l'aggiornamento / crea un file .Xauthority.

Inoltre, quando eseguo xauth ottengo la risposta: 

marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>exit
marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>

Non crea il file.

EDIT:

Quando connetto il monitor, poi accedo localmente, il file viene creato ma quando provo ad aggiungere una voce (perché il mio SSH non lo fa per me): 

marty@N40L ~ $ xauth list
N40L/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep 3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1: unable to open display "localhost:10.0".
``` ```
tcp 0 0 localhost:6010 *:* LISTEN

Tra l'altro, facendo un netstat --listen mostra la porta in ascolto:

&001 &001

AGH, maggiori informazioni. Mi sono disconnesso dalla sessione X sul server, e ora il file .Xauthority è scomparso. Sembra che il file sia SOLO lì quando è stato effettuato il log in locale. Qualcuno può dirmi perché, o come posso risolvere il problema?

NEW DEVELOPMENT:

Ho creato un utente vergine sul sistema chiamato “test”. Ho quindi effettuato il login e, senza altri comandi, ho eseguito xeyes. Il che ha funzionato! Quindi è SOLO l'utente “marty” che non può xforward. Come faccio a copiare le impostazioni da test a marty?
Fonte

Risposte (6)

35
35
35
2015-07-16 04:15:44 +0000

Tanto per dire, ho avuto un problema simile. Ma nel mio caso seguo questi passi :

Seguo questi passi per creare un file $HOME/.Xauthority.

Accedi come utente e conferma di essere nella directory home dell'utente. 

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list

Dopo di che non ci sono più problemi con il file .Xauthority da allora.

Grazie e crediti a srinivasan .
Fonte
4
4
4
2018-02-20 15:30:16 +0000

Giusto per completare l'eccellente ton risposta .

Una volta ho avuto esattamente lo stesso problema perché il mio annuario di casa era diventato pieno al 100%. Alla connessione, ssh ha creato un ~/.Xauthority vuoto e non è stato in grado di scrivere una singola voce (così che xauth list ha sempre prodotto un'uscita vuota).

Quindi suggerisco di controllare sempre lo spazio libero (ad esempio: df -h) e di verificare che xauth generate e xauth add abbiano effettivamente avuto un qualche effetto (xauth list).
Fonte
1
1
1
2015-05-20 14:06:07 +0000

Spostare la directory .ssh ha fatto sì che X forwarding funzionasse per me.

Attraverso il processo di eliminazione, ho trovato un file in ~/.ssh che si chiamava “rc”, e conteneva: 

echo "Wecome to $(hostname), $(whoami)"

Non l'ho mai creato, e non ho idea da dove sia venuto. Rimuovendolo ho risolto il problema, e i miei file authorized_keys, known_hosts e i file chiave possono rimanere tutti intatti.
Fonte
1
1
1
2014-09-04 08:33:25 +0000

Dopo aver scoperto che non era il sistema, aggiungendo un utente di prova (che x forwarding ha funzionato “out the box”), ho pensato di iniziare a copiare i file di avvio .bash* per verginizare l'utente “rotto”.

Nessuno dei file era diverso, così ho poi cancellato la directory users .ssh. Quando ho ssh’d in, si è lamentato del fatto che il “Server ha rifiutato la nostra chiave”, ma ho potuto accedere usando la password. Una volta effettuato il login, potevo x inoltrare perfettamente.

Ora proverò a configurare di nuovo la chiave e vedrò se riesco a far funzionare anche quella. Poi tornerà alla normalità.
Fonte
1
1
1
2019-09-17 06:35:46 +0000

Sotto i privilegi di root aprire /etc/ssh/sshd_config e decommentare le seguenti righe se sono commentate:

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

Poi logout e login di nuovo con flag -X in ssh. Non è necessario impostare o disinserire la variabile d'ambiente DISPLAY.
Fonte
0
0
0
2019-01-11 14:16:32 +0000

Mi sono imbattuto in questo stesso problema su due server che tecnicamente erano nodi gemelli. Dolore alla coda, perché non riuscivo a capire cosa fosse diverso. Si è scoperto che la directory /home era piena, quindi i file .Xauthority non riuscivano a popolare correttamente. Una volta localizzati i file che occupavano troppo spazio e li ho eliminati, sono stati creati nuovi file .Xauthority.
Fonte