Ao tentar acessar um cluster em meu laboratório por ssh e funcionar. mas depois não consigo fazer nada:
user@users:~> nautilus
X11 connection rejected because of wrong authentication.
Could not parse arguments: Cannot open display
ou
user@users:~> gedit
X11 connection rejected because of wrong authentication.
(gedit:151222): Gtk-WARNING **: cannot open display: localhost:11.0
Funcionou até hoje... e não sei como verificar se algo mudou. Eu não tenho a senha de root para esta máquina, há algo que eu possa fazer?
Eu li muita coisa sobre esse erro como este, mas nada resolvido ...
EDITAR:
O sistema operacional local é o Ubuntu 16 e o servidor é o OpenSuse. Estou conectando desta forma:
ssh -XY -p22 [email protected]
EDIÇÃO 2:
user@users:~> env
MODULE_VERSION_STACK=3.1.6
LESSKEY=/etc/lesskey.bin
NNTPSERVER=news
INFODIR=/usr/local/info:/usr/share/info:/usr/info
MANPATH=/usr/local/man:/usr/share/man
HOSTNAME=users
XKEYSYMDB=/usr/share/X11/XKeysymDB
HOST=users
TERM=xterm-256color
SHELL=/bin/bash
PROFILEREAD=true
HISTSIZE=1000
SSH_CLIENT=10.44.0.1 49729 22
MORE=-sl
SSH_TTY=/dev/pts/2
JRE_HOME=/usr/lib64/jvm/jre
USER=user
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
LD_LIBRARY_PATH=/usr/local/cuda-5.5/lib:/usr/local/cuda-5.5/lib64:
XNLSPATH=/usr/share/X11/nls
ENV=/etc/bash.bashrc
HOSTTYPE=x86_64
FROM_HEADER=
MSM_PRODUCT=MSM
PAGER=less
CSHEDIT=emacs
XDG_CONFIG_DIRS=/etc/xdg
MINICOM=-c on
MODULE_VERSION=3.1.6
MAIL=/var/mail/user
PATH=/usr/local/cuda-5.5/bin:/home/user/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
CPU=x86_64
JAVA_BINDIR=/usr/lib64/jvm/jre/bin
INPUTRC=/home/user/.inputrc
PWD=/home/user
JAVA_HOME=/usr/lib64/jvm/jre
LANG=en_US.UTF-8
PYTHONSTARTUP=/etc/pythonstart
MODULEPATH=/usr/share/modules:/usr/share/modules/modulefiles
LOADEDMODULES=
QT_SYSTEM_DIR=/usr/share/desktop-data
SHLVL=1
HOME=/home/user
LESS_ADVANCED_PREPROCESSOR=no
OSTYPE=linux
LS_OPTIONS=-N --color=tty -T 0
XCURSOR_THEME=DMZ
MSM_HOME=/usr/local/MegaRAID Storage Manager
WINDOWMANAGER=/usr/bin/gnome
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
LESS=-M -I
MACHTYPE=x86_64-suse-linux
LOGNAME=user
XDG_DATA_DIRS=/usr/share:/etc/opt/kde3/share:/opt/kde3/share
SSH_CONNECTION=172.17.10.15 22
MODULESHOME=/usr/share/modules
LESSOPEN=lessopen.sh %s
INFOPATH=/usr/local/info:/usr/share/info:/usr/info
DISPLAY=localhost:12.0
XAUTHLOCALHOSTNAME=users
LESSCLOSE=lessclose.sh %s %s
G_BROKEN_FILENAMES=1
JAVA_ROOT=/usr/lib64/jvm/jre
COLORTERM=1
_=/usr/bin/env
Xauthority Mini Como fazer
Em sistemas GNU/Linux executando um servidor de exibição X11, o arquivo
~/.Xauthority
armazena cookies de autenticação ou chaves criptográficas usadas para autorizar a conexão com a exibição. Na maioria dos casos, o mecanismo de autenticação é um cookie simétrico conhecido comoMagic Cookie
. O mesmo cookie é usado tanto pelo servidor quanto pelo cliente.Cada cookie de autenticação X11 está sob o controle do usuário autenticado pelo sistema individual. Como o cookie de autenticação é armazenado como um token de segurança de texto simples, as permissões no
~/.Xauthority
arquivo devem serrw
apenas para o proprietário,600
em formato octal. No entanto, as permissões no arquivo de autorização não são impostas.Um usuário pode listar, exportar, criar ou excluir cookies de autenticação usando o
xauth
programa. O comando a seguir criará um cookie de autorização para arquivosDISPLAY 32
.A criação manual e a manipulação de cookies geralmente não são necessárias ao usar o encaminhamento X11 com
ssh
, porquessh
inicia um proxy X11 na máquina remota e gera automaticamente cookies de autorização na exibição local. No entanto, para determinadas configurações, o cookie de autorização pode precisar ser criado manualmente e copiado para a máquina local.Isso pode ser feito em uma
ssh
sessão e depois usarscp
para copiar o cookie.ssh
na máquina remota:Verifique se um cookie de autorização está presente para a exibição atual do X11
Se não houver nenhuma variável de ambiente nomeada
$DISPLAY
, o proxy X11 não foi iniciado corretamente. É importante observar queDISPLAY 0
normalmente os usuários estão conectados localmente e só estão em execução se um xserver tiver sido iniciado localmente viaxinit
. Não há nenhum requisito para um servidor X11 iniciado localmente para que o encaminhamento X11 funcione por meio dessh
.Se houver uma
$DISPLAY
variável de ambiente definida, mas nenhum cookie de autorização correspondente para esse número de exibição, você poderá criar um:E verifique se agora existe um cookie:
Você pode copiar esse cookie e mesclá-lo na máquina local:
Em seguida, verifique se o cookie foi instalado:
Experimente sua conexão ssh de encaminhamento X11.
Notas sobre
~/.Xauthority
~/.Xauthority
é um arquivo binário que contém todas as informações de autorização para cada exibição que o usuário pode acessar. Cada registro é delimitado pelos dois bytes0x0100
. Cada campo é precedido por uma contagem hexidêmica do número de bytes do campo. Todo o texto é codificado em ASCII hexadecimal. A tabela a seguir é a estrutura básica da configuração mais comum de uma autorização MIT MAGIC COOKIE:A linha superior pode ser recuperada do
~/.Xauthority
arquivo por meio doxauth nlist
comando. Obviamente, seu arquivo de autorização terá informações diferentes do meu exemplo.Se as extensões de segurança estiverem em uso com o servidor X11, há várias opções de configuração para cada linha de autorização, incluindo autorização por tempo limitado por cookie.
Conforme explicado aqui , gostaria de salientar que sintomas semelhantes agora ocorrem por um motivo muito diferente, para evitar que as pessoas caiam em longas
xauth
tocas de coelho.Qualquer coisa instalada com o Snap não funcionará. Então
xeyes
exclock
pode funcionar, mas uma nova instalação dochromium-browser
oufirefox
no Ubuntu não funcionará.A solução é simplesmente fazer:
export XAUTHORITY=$HOME/.Xauthority
antes de executar o aplicativo X11 remoto.Eu tive esse problema ao tentar instalar um software que realmente queria usar uma GUI (ou seja, não consegui descobrir uma maneira de instalá-lo sem uma GUI). Meu problema era que eu estava tentando executar o executável
sudo
esudo
tinha a autenticação errada.Dica: use
xhost
o comandoO comando
xhost
é útil porque informa se o seu usuário tem acesso à conexão X11No meu caso, meu usuário teve acesso:
mas usando
sudo
não tive acesso:Depois que descobri isso, ele explicou por que os programas executados com
sudo
o erro de autenticação.Minha solução
Para corrigir isso fiz o seguinte:
Obter valor de
$DISPLAY
Obtenha o valor do cookie mágico que corresponde ao número de
$DISPLAY
, no meu caso, este é o valor de10
:Mude o usuário para root:
Adicione o valor do cookie mágico ao Xauthority:
Verifique se foi adicionado corretamente:
Verifique se está funcionando:
Então, como root, executei meu programa e finalmente consegui executar a GUI que tanto desejava para instalar.