"Su" con errore "Connessione X11 rifiutata a causa di un'autenticazione errata"

Come root, mi sto collegando a un host remoto per eseguire un comando. Solo "standarduser" ha il file id appropriato e .ssh / config corretti, quindi cambio prima l'utente:

su standarduser -c 'ssh -x remotehost ./remotecommand'

Il comando funziona bene, ma nonostante abbia usato "-x" (disabilita l'inoltro X11) e ho disabilitato X11Forwards /etc/ssh/ssh_config, ricevo ancora il messaggio di errore:

X11 connection rejected because of wrong authentication.

Non ricevo il messaggio di errore quando eseguo l'accesso come "utente standard".

Questo è abbastanza fastidioso in quanto vorrei integrare il comando in un file di lavoro cron. Comprendo che il messaggio di errore si riferisce all'autenticazione errata del file .XAuth di root, ma non sto nemmeno provando a connettermi tramite X11.

Perché "ssh -x" non disabilita la connessione X11 e genera il messaggio di errore?

AGGIORNAMENTO : il messaggio viene visualizzato solo quando ho effettuato l'accesso all'interno di una schermata, quando si utilizza il comando indicato sopra sul computer locale stesso (senza schermata), non viene visualizzato un messaggio di errore, quindi questo dovrebbe andare bene anche con cron .

Ho anche avviato lo stesso comando con -ve sorprendentemente ricevuto il messaggio di errore PRIMA, anche prima delle informazioni sullo stato da SSH:

root@localhost:~# su standarduser -c 'ssh -x remotehost ./remotecommand'
X11 connection rejected because of wrong authentication.
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013

Questo mi ha portato al problema stesso, NON è quello sshche lancia il messaggio di errore, è su:

root@localhost:~# su standarduser -c 'echo Hi'
X11 connection rejected because of wrong authentication.
Hi

Perché visualizzo solo questo errore screen? Come posso disabilitare questo messaggio di errore?

Sembra che la tua radice manchi di qualche biscotto magico X11 in quello .Xauthorityche hai standarduser. Ecco come risolvere questo problema.

VERSIONE CORTA (grazie a @bmaupin )

standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`

Attenzione: controlla le levette! Non possono essere sostituiti con virgolette! È necessario sudoinstallare per procedere oltre il secondo comando!

VERSIONE LUNGA ORIGINALE

Per sistemare le cose, per prima cosa rileva quale numero di display standarduserutilizza:

standarduser@localhost:~$ echo $DISPLAY
localhost:21.0

In questo caso lo è 21.0. In secondo luogo, visualizza standarduserl'elenco dei cookie:

standarduser@localhost:~$ xauth list
localhost/unix:1  MIT-MAGIC-COOKIE-1  51a3801fd7776704575752f09015c61d
localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f
localhost/unix:22  MIT-MAGIC-COOKIE-1  22ba6595c270f20f6315c53e27958dfe
localhost/unix:20  MIT-MAGIC-COOKIE-1  267f68b51726a8a381cfc10c91783a13

Il cookie per il 21.0display è il secondo nell'elenco e termina con 104f.

L'ultima cosa da fare è aggiungere questo particolare cookie ai root .Xauthority. Accedi come root e procedi come segue:

root@localhost:~$ xauth add localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f

Questo è il modo in cui è possibile mitigare l' X11 connection rejected because of wrong authenticationerrore quando si esegue sucome utente diverso nello script Bash o screen.

Grazie a questo ragazzo per l'ispirazione.

Una soluzione più semplice:

1.- ssh user@host

2.- $ sudo su

3.- # xauth merge /home/user/.Xauthority

È tutto

Naturalmente è $DISPLAYnecessario impostare la variabile.

Le mie esigenze erano leggermente diverse, quindi ho trovato una soluzione leggermente diversa. Avevo bisogno della possibilità di eseguire un'app X11 come un altro utente (che non è root). Eseguendo CentOS, quindi non ho il dolce strumento gksudo che hanno i cani fortunati con Ubuntu che fa la magia di Xauth.

Non volevo davvero creare alcuni script personalizzati solo per accedere, cambiare utente ed eseguire un'app; mi sembra un po 'superfluo.

Primo passo:

Consenti a $ XAUTHORITY di essere portato attraverso sessioni sudo.

Aggiungi questa riga sotto il resto delle istruzioni env_keep in / etc / sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Passo due:

Consenti al tuo utente target la possibilità di leggere la tua .Xauthority (sì, lo so, urla SICUREZZA! Tutto ciò che vuoi). Per coloro che vogliono solo la possibilità di eseguire comandi come root, questo può essere ignorato.

L'utente di destinazione condivide il mio stesso gruppo, quindi accendo le autorizzazioni di lettura del gruppo:

$ chmod g+r user ~/.Xauthority

Terzo passaggio:

CentOS non popola il valore di $ XAUTHORITY per impostazione predefinita. Aggiungi una riga al tuo profilo (il mio è ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

Questo è tutto. Niente più modifiche. Non scrivere .XML per far funzionare PolicyKit. Nessuno script in esecuzione per ogni accesso. Non è necessario fare due volte sudo per copiare xauth. Da qui in poi, puoi semplicemente:

$ sudo -u user xcalc

Funziona alla grande con MobaXTerm.

Dovresti passare completamente all'utente di destinazione, ovvero utilizzare " -" con su( su - standarduser ...). In caso contrario, gli oggetti X di root verranno trascinati nell'ambiente.

Poiché eseguo spesso il root su una condivisione di file di rete schiacciata dal root, nessuna delle soluzioni precedenti ha funzionato per me. (xubuntu 14.04). Ho messo insieme il seguente script, che funziona sul mio sistema. Potrebbe funzionare sul tuo. Inoltre, potrebbe non esserlo, ma è libero di provare ...

Il presupposto è che ho ssh'd usando l'opzione -Y.

#!/bin/bash  
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
    port=${BASH_REMATCH[1]}
else
    echo "Unexpected DISPLAY $DISPLAY"
    exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
sudo -i xauth -i add $cookie
sudo -i $*

Nel mio caso, quando ho riscontrato questo errore, avevo una directory utente crittografata. Dopo aver chiamato ecrypt-mount-private, si è sbarazzato dell'errore e mi ha permesso di continuare l'inoltro X11.

Per determinare se la cartella principale è crittografato, si può provare questo (come da questa risposta ): ls -A /home. Se vedi una .ecryptfscartella, probabilmente la tua home directory è probabilmente crittografata, nel qual caso puoi provare a fare il comando che ho inserito all'inizio della risposta.