“su” com erro “conexão X11 rejeitada por causa de autenticação incorreta”

Question

Como root, estou conectando a um host remoto para executar um comando. Apenas "standarduser" tem o id-file apropriado e corrige .ssh / config, então estou trocando o usuário primeiro:

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

O comando funciona bem, mas apesar do fato de eu ter usado "-x" (desabilitar o X11-Forwarding) e ter o X11Forwards desabilitado em /etc/ssh/ssh_config , ainda recebo a mensagem de erro:

X11 connection rejected because of wrong authentication.

Não estou recebendo a mensagem de erro quando estou logado como "standarduser".

Isso é muito chato, porque gostaria de integrar o comando em um arquivo de trabalho cron. Eu entendo que a mensagem de erro se refere à autenticação errada do arquivo .XAuth do root, mas eu nem estou tentando conectar via X11.

Por que "ssh -x" não está desativando a conexão do X11 e emitindo a mensagem de erro?

UPDATE : A mensagem só mostra quando estou logado dentro de uma tela, ao usar o comando indicado acima na própria máquina local (sem tela), eu não recebo uma mensagem de erro, então isso deve ficar bem com o cron também. / p>

Eu também iniciei o mesmo comando com -v e surpreendentemente recebi a mensagem de erro FIRST, mesmo antes das informações de status do 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

Isso me levou ao problema em si, NÃO é o ssh que está enviando a mensagem de erro, é su :

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

Por que só recebo esse erro em screen ? Como posso desativar esta mensagem de erro?

    

Answer 1

Parece que sua raiz não possui algum cookie mágico do X11 em seu .Xauthority , que tem seu standarduser . Aqui está como corrigir isso.

VERSÃO RESUMIDA (graças a @bmaupin por isso)

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

Atenção: verifique os backticks! Eles não podem ser substituídos por citações! Você precisa do sudo instalado para continuar o segundo comando!

VERSÃO LONGO ORIGINAL

Para corrigir as coisas, primeiro detecte qual número de exibição standarduser usa:

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

Nesse caso, é 21.0 . Em segundo lugar, mostre a lista de cookies de standarduser :

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

O cookie para a exibição 21.0 é o segundo da lista e termina com 104f .

A última coisa a fazer é adicionar esse cookie específico à raiz .Xauthority . Faça o login como root e faça o seguinte:

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

Essa é uma maneira simples e simples de lidar com o erro X11 connection rejected because of wrong authentication enquanto você executa su como usuários diferentes no script bash ou screen . E, a propósito, graças a esse cara por seu brilhante post.

    

Answer 2

Uma solução mais fácil:

1.- ssh user@host

2.- $ sudo su

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

Isso é tudo

É claro que a variável $DISPLAY deve ser definida.

    

Answer 3

Minhas necessidades eram um pouco diferentes, então eu criei uma solução um pouco diferente. Eu precisava da capacidade de executar um aplicativo X11 como outro usuário (que não é root). Rodando o CentOS, então eu não tenho a doce ferramenta gksudo que os sortudos do Ubuntu têm que fazer a mágica Xauth.

Eu realmente não queria criar alguns scripts personalizados apenas para fazer login, trocar de usuário e executar um aplicativo; isso parece um pouco supérfluo para mim.

Primeiro passo:

Permitir que o $ XAUTHORITY seja transmitido através de sessões de sudo.

Adicione esta linha ao resto das instruções env_keep em / etc / sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Etapa dois:

Permita ao seu usuário alvo a capacidade de ler a sua autoridade .Xauthority (sim, eu sei, gritar SEGURANÇA! tudo que você quiser). Para aqueles que querem apenas a capacidade de executar comandos como root, isso pode ser ignorado.

O usuário de destino compartilha o mesmo grupo que eu, por isso, basta ativar as permissões de leitura de grupo:

$ chmod g+r user ~/.Xauthority

Terceiro passo:

O CentOS não preenche o valor de $ XAUTHORITY por padrão. Adicione uma linha ao seu perfil (o meu é ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

É isso. Não há mais ajustes. Não escrevendo .XML para fazer o PolicyKit funcionar. Não há scripts em execução para cada login. Não ter que sudo duas vezes para copiar o xauth. De agora em diante, você pode simplesmente:

$ sudo -u user xcalc

Funciona muito bem com o MobaXTerm.

    

Answer 4

Você deve alternar totalmente para o usuário de destino, por exemplo, use " - " com su ( su - standarduser ... ). Se não, o material X do root será arrastado no ambiente.

    

Answer 5

Como eu frequentemente participo de um compartilhamento de arquivos de rede root-squashed, nenhuma das soluções acima funcionou para mim. (xubuntu 14.04). Eu coloquei o seguinte script, que funciona no meu sistema. Pode funcionar no seu. Então, novamente, pode não ser, mas é livre para tentar ...

A suposição é que eu usei a opção -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 $*

    

Answer 6

No meu caso, quando encontrei esse erro, eu tinha um diretório de usuários criptografados. Depois de chamar ecrypt-mount-private , ele se livrou do erro e permitiu que eu continuasse o encaminhamento do X11.

Para determinar se sua pasta pessoal está criptografada, você pode tentar isso (conforme esta resposta ): ls -A /home . Se você vir uma pasta .ecryptfs , provavelmente o seu diretório pessoal está criptografado. Nesse caso, você pode tentar executar o comando que eu coloquei no início da resposta.